Verifiable Parental Consent: Handling Children's Data in India

Who this is for: product managers, engineers and DPOs building services that children use or are likely to use, including edtech, gaming, social, entertainment and consumer apps.

The DPDP Act's strictest obligations concern children. A child is anyone under 18 (Section 2(f)), a far higher threshold than many global laws. For consent-based processing, the Act requires consent not from the child but from a parent or lawful guardian, and it requires that consent to be verifiable. Some uses of children's data are banned outright, whatever a parent agrees to.

This guide explains what the law requires, how to verify parents in practice, and where the exemptions apply. For sector detail, see our guides for edtech and schools and healthcare.

What Section 9 requires

1. Verifiable consent from a parent or lawful guardian before processing a child's personal data (Section 9(1)).
2. No processing likely to cause a detrimental effect on the child's well-being (Section 9(2)).
3. No tracking, behavioural monitoring or targeted advertising directed at children (Section 9(3)).

Section 9(1) also applies to a person with a disability who has a lawful guardian, with consent coming from that guardian. Breaching Section 9 carries a penalty of up to ₹200 crore.

How to verify a parent: Rule 10

Rule 10 requires you to adopt appropriate technical and organisational measures to ensure that verifiable consent is obtained from the parent, and to observe due diligence to check that the person identifying as the parent is an identifiable adult.

It recognises two routes:

• Reliable details already available to you. If the parent is already a verified adult user of your service, you can rely on their existing identity and age details.
• Details or a virtual token provided by the parent. The parent can provide identity and age details voluntarily, or a virtual token mapped to them, issued by an entity entrusted by law or the government, such as through DigiLocker.

A practical flow looks like this:

1. Identify that a user may be a child, at sign-up or when signals suggest it.
2. Pause any processing that needs consent.
3. Route the request to a parent, through a separate channel such as the parent's own phone or email.
4. Verify the parent as an identifiable adult, using existing records or a token.
5. Record the parent's consent per purpose, with the verification method, in your consent audit trail.
6. Enable withdrawal by the parent at any time.

Self-declaration alone ("I am over 18", or "my parent has agreed") does not meet this standard.

Persons with disabilities: Rule 11

Where an adult with a disability has a lawful guardian, consent comes from the guardian. Rule 11 requires due diligence to verify that the guardian has been appointed by a court, a designated authority or a local level committee under the applicable law.

The ban that consent cannot unlock

Section 9(3) prohibits tracking, behavioural monitoring and targeted advertising directed at children. Unlike other processing, a parent's consent does not make these lawful. For consumer platforms, that means:

• no behavioural or retargeted advertising to child users
• no advertising SDKs or pixels firing for child users
• no profiling of children to drive engagement or upsells

Marketing to parents, as adults with their own valid consent, remains possible.

Exemptions: Rule 12 and the Fourth Schedule

The Fourth Schedule lists exemptions from Sections 9(1) and 9(3), always limited to specific purposes.

Part A, by class of fiduciary:

Part B, by purpose, for any fiduciary, includes processing to create a user account limited to email communication, to track a child's real-time location for their safety, to keep information likely to cause harm from reaching a child, and to confirm that a user is not a child.

The exemptions are narrow. A hospital treating a child is exempt for treatment, not for marketing. A school is exempt for educational monitoring, not for selling data to advertisers.

Designing for children

• Default child accounts to the most protective settings.
• Keep data collection to what the service needs.
• Avoid design that pressures children, such as streaks, countdowns and manipulative nudges, which may harm well-being under Section 9(2).
• Write notices for parents in plain language, and explain the service to children in age-appropriate terms.

Common mistakes

• Using 13 or 16 as the age threshold. Under the DPDP Act it is 18.
• Self-declared consent. A tick-box is not verification.
• Parental consent for ads. Targeted advertising to children is banned regardless.
• Reading exemptions broadly. They cover named purposes only.
• No withdrawal route for parents. Parents must be able to withdraw as easily as they consented.

How ConsentifyAI helps

ConsentifyAI supports verifiable parental consent flows end to end: age signals at sign-up, routing to the parent, verification using existing records or a token, and per-purpose consent recorded with the verification method in a tamper-evident audit trail. Child accounts can be flagged so that advertising tags and non-exempt processing stay switched off.