A vendor clause is a fine umbrella, but not if the storm is already inside the SDK.

Vendor controls for children's personal data

Vendor controls for children's personal data need more than a standard data processing addendum. Indian products that serve or may be accessed by children often rely on analytics tools, advertising SDKs, cloud services, customer support platforms, push notification providers, age-assurance tools, identity vendors, moderation services, payment processors and product-experimentation platforms. Each vendor can change how a child account is profiled, shared, retained or exposed.

Under the DPDP Act, the Data Fiduciary remains responsible for how personal data is processed for its product or service. That makes vendor governance a product control, not a procurement formality. The operating question is simple: if the child account enters the product, which external systems receive the data, why do they receive it, and what prevents reuse for tracking, advertising or unrelated profiling?

What to review

Start with a child-data vendor inventory. List every vendor that receives personal data from child users or users who may be children. Include obvious processors such as cloud hosting and support tools, but also quiet integrations such as analytics SDKs, attribution tags, session replay, crash reporting, content moderation queues, email tools and push notification platforms.

Review the data categories and purposes. For each vendor, record whether it receives identifiers, age signals, parent contact details, device IDs, location data, chat content, learning activity, gameplay events, profile data, payment signals, complaint records or behavioural events. The purpose should be specific enough for engineering and operations teams to test it.

Check onward sharing and default settings. Some vendors use subcontractors, cross-product enrichment, model training, audience matching, benchmarking or diagnostics by default. A vendor control review should identify which settings are disabled for child accounts and which contractual restrictions apply to the service.

Review access and retention. Vendor dashboards can expose child-user records to support, marketing, product and analytics teams. Access should be role-based and logged. Retention should match the product's child-data policy rather than the vendor's default retention period.

Implementation steps

Build a child-data vendor matrix. The matrix should include the vendor name, tool owner, product feature, data fields, processing purpose, account-state trigger, transfer destination, subprocessors, retention period, security controls and child-specific restrictions.

Classify vendors by risk. High-risk vendors include advertising networks, analytics platforms, session replay tools, social login, chat moderation, identity verification, recommendation engines and tools that receive behavioural event streams. Lower-risk infrastructure tools still need review, but they may not need the same level of product-specific suppression testing.

Add child-specific contractual controls. Vendor terms should restrict processing to agreed purposes, prohibit unauthorised onward sharing, require suitable security safeguards, support deletion or correction workflows, and require timely assistance for incidents and rights requests. Where the vendor supports child-account settings, those should be documented separately from the contract.

Test the integration, not just the paperwork. Use a test child account to confirm which events, identifiers and attributes reach the vendor. Check network calls, tag manager rules, SDK dashboards, warehouse tables and support exports. If the vendor receives more data than expected, fix the implementation before launch.

Create an owner review cycle. Assign product, engineering, privacy and procurement owners for periodic review. Vendor controls should be revisited when a feature changes, a vendor updates terms, a new SDK is added, a data category changes, or a child-account workflow is redesigned.

Common mistakes

• Treating all vendors as ordinary processors while ignoring advertising, analytics and behavioural event tools that create child-specific risk.
• Relying on contract clauses without testing whether the live SDK or tag configuration actually follows them.
• Forgetting support exports, dashboard access, logs and retention settings when mapping children's personal data.

How DataNuance can help

DataNuance helps teams build vendor controls for children's personal data across contracts, product integrations, SDK settings, support tools and data pipelines. We identify which vendors receive child data, what must be suppressed or limited, and what evidence the organisation should retain for DPDP readiness.

For a vendor-control review for children's personal data, contact DataNuance.

FAQs

Do all vendors need child-specific review?

Any vendor receiving child-user personal data should be reviewed. The depth of review can vary by risk, but the organisation should know what data is sent, why it is sent, and how the vendor is restricted.

Is a standard data processing agreement enough?

Usually not by itself. Contracts matter, but child-data controls also need SDK settings, tag suppression, access controls, retention decisions and testing evidence.

What vendors are highest risk for child data?

Advertising networks, analytics platforms, session replay tools, attribution SDKs, social features, recommendation engines, chat moderation services and tools receiving behavioural event streams usually need closer review.

What evidence should be retained?

Keep the vendor matrix, contract review notes, subprocessors, SDK settings, test results, data-flow diagrams, access logs, retention settings and approvals for any child-specific exceptions.

Sources

Digital Personal Data Protection Act, 2023, Ministry of Electronics and Information Technology official copy.

Digital Personal Data Protection Rules, 2025, Ministry of Electronics and Information Technology official copy.