Children's Data Under the DPDP Act: Verifiable Parental Consent Explained
India's DPDP Act treats everyone under 18 as a child — far stricter than GDPR or COPPA. This guide covers verifiable parental consent under the DPDP Rules, the bans on tracking and targeted advertising to children, exemptions, and age-gating patterns that avoid over-collection.
Section 9 Basics: Who Counts as a Child Under the DPDP Act
India's DPDP Act draws its line for children's data at eighteen years of age. Anyone below eighteen is a child, and processing their personal data triggers Section 9's obligations. This is the strictest age threshold among major privacy regimes: the GDPR allows member states to set the age of digital consent anywhere between thirteen and sixteen, and COPPA in the United States applies only to children under thirteen.
The consequence of the higher threshold is that Section 9 is not a niche obligation for children's apps. Any consumer product with a meaningful Indian user base — social platforms, gaming, e-commerce, ed-tech, streaming — will have users between thirteen and seventeen who would be adults under most other regimes but are children under the DPDP Act. Compliance programmes built on GDPR assumptions systematically underestimate the population in scope.
Section 9 imposes three core obligations on Data Fiduciaries processing children's data. They must obtain verifiable consent from a parent or lawful guardian before processing. They must not undertake processing likely to cause any detrimental effect on the well-being of a child. And they must not undertake tracking or behavioural monitoring of children, or targeted advertising directed at children. Each obligation stands independently — parental consent does not unlock tracking or targeted advertising.
The penalty schedule underlines how seriously the legislature takes this area: violations of obligations relating to children carry penalties of up to ₹200 crore, one of the highest bands in the Act. Combined with the reputational dimension of children's privacy failures, Section 9 deserves dedicated attention in any DPDP compliance programme rather than a footnote in the consent workstream.
Verifiable Parental Consent: What the DPDP Rules Actually Require
The Act requires verifiable consent from the parent or lawful guardian, and the DPDP Rules give that word practical shape. Before processing a child's data, the Data Fiduciary must adopt appropriate technical and organisational measures to ensure two things: that the person giving consent is an adult, and that the person is identifiable if required in connection with compliance with law.
The Rules contemplate verification using reliable details of identity and age already available to the Data Fiduciary, or details voluntarily provided by the parent, or a virtual token mapped to identity and age details issued by an entity entrusted by law with such verification. In the Indian context this points naturally at DigiLocker and similar government-backed digital identity infrastructure, which can confirm that a person is an adult without the fiduciary needing to collect and store an identity document itself.
The token-based model is the direction compliance teams should design toward. Collecting scans of Aadhaar cards or passports to verify parenthood creates a worse privacy problem than the one being solved — a store of high-sensitivity identity documents held by every app a child uses. A verification flow that receives only a yes-this-is-an-adult assertion, plus a reference identifier that can be produced if a regulator asks, satisfies the requirement while minimising the data collected.
What the Rules do not require is proof of the parental relationship itself in most cases — the emphasis is on verifying that the consenting person is an identifiable adult. Organisations should nevertheless document their design choices, including how they handle edge cases such as guardians, and record the verification method alongside each consent so the audit trail shows not just that consent was obtained but how it was verified.
The Hard Prohibitions: No Tracking, No Behavioural Monitoring, No Targeted Ads
Section 9's prohibitions are absolute in a way that surprises teams accustomed to consent-based regimes. A Data Fiduciary shall not undertake tracking or behavioural monitoring of children or targeted advertising directed at children. There is no consent override — a parent cannot authorise behavioural advertising to their child — and no legitimate-interest style balancing test.
For products with users under eighteen, this forces an architectural question: can your systems distinguish child users and switch off entire categories of processing for them? Analytics SDKs, advertising identifiers, recommendation personalisation, engagement profiling, and retargeting pixels all sit in the prohibited zone when the user is a child. The compliant configurations are either to disable these systems for identified child accounts or to run contextual rather than behavioural models for that population.
The boundary questions are genuinely difficult and enforcement guidance is still developing. Is a recommendation engine that personalises a video feed behavioural monitoring? A conservative reading says yes where it builds a behavioural profile of the child over time. Is safety monitoring — detecting grooming or self-harm signals — prohibited tracking? The Rules carve out certain processing in the interests of the child, and the exemption framework discussed below provides some relief, but each such use should be individually assessed and documented rather than waved through.
The detrimental-effect prohibition is broader still: no processing likely to cause any detrimental effect on the well-being of a child. This functions as a general duty of care and will likely be interpreted through enforcement over time. Dark patterns aimed at children, engagement mechanics designed to exploit compulsive behaviour, and features that expose children's data to strangers are the obvious early candidates for scrutiny.
Exemptions Under the Rules: Narrow Relief for Specific Sectors
The DPDP Rules temper Section 9 with exemptions for defined classes of Data Fiduciaries and defined purposes, recognising that a blanket parental-consent requirement would break legitimate services for children. The notified classes include healthcare establishments, educational institutions, and providers of childcare, among others — and for them the exemption applies only to specified processing, such as health services, educational activities, or safety monitoring, not to their processing generally.
The structure matters: the exemption attaches to the intersection of a class and a purpose. A school may process a student's data for educational activities and safety without parental consent under the exemption, but the same school running a marketing campaign or an ed-tech platform monetising engagement data cannot shelter under it. Any organisation planning to rely on an exemption should map each processing activity to the specific exempted purpose and treat everything outside that mapping as requiring full Section 9 compliance.
The Rules also exempt certain processing necessary in the interests of the child — for example, verifying age itself, or protecting a child from harm. This resolves the bootstrap paradox that strict reading would create: you must process some data about a user to determine whether they are a child at all.
Ed-tech companies deserve a specific caution. Many assume they inherit the educational-institution exemption, but the exemption classes are drawn around institutions and establishments, and a commercial platform selling to consumers is not obviously within them. Until enforcement practice or further guidance clarifies the boundary, ed-tech businesses should build verifiable parental consent capability rather than betting the compliance programme on an exemption they may not hold.
Age-Gating in Practice: Design Patterns and the Minimisation Tension
None of Section 9 works unless you know which of your users are children, and this is where implementation gets uncomfortable. Age assurance sits on a spectrum from self-declaration, through age estimation, to verified identity — and each step up the spectrum improves accuracy while collecting more data about every user, including adults.
Self-declared date-of-birth gates are the established baseline and remain the starting point for most services. Their weakness is well documented: children misstate their age routinely. But the alternative — verifying the identity of every user to catch the minority who lie — collides with the Act's own data minimisation principles and creates mass identity-data collection that regulators elsewhere have criticised. The DPDP Rules do not mandate a specific age assurance method for the general population, and a proportionate, risk-based approach is the defensible position as of mid-2026.
A pragmatic pattern is tiered assurance based on risk. Services whose features are benign can rely on declared age with fraud signals — for example, flagging accounts whose behaviour contradicts their declared age. Services with higher-risk features, such as social interaction with strangers or content unsuitable for children, should apply stronger assurance at the point of accessing those features rather than at the front door. This keeps the heavy verification where the risk is, in line with minimisation.
Whatever mechanism you choose, keep the evidence and discard the inputs. Store the outcome of the age check and the method used, not the underlying documents or biometric estimates. And design the flow for the moment a user crosses eighteen: consent obtained from a parent does not automatically convert into the user's own consent, so plan a re-consent journey at the age of majority rather than silently continuing on the parental basis.
Persons with Disabilities and Consent by Lawful Guardians
Section 9 covers a second population that is easy to overlook: persons with disabilities who have a lawful guardian. Where a Data Principal is a person with a disability for whom a guardian has been appointed, the Data Fiduciary must obtain verifiable consent from that lawful guardian before processing, in the same manner as for children.
The DPDP Rules clarify the verification expectation: the fiduciary must verify that the guardian has been appointed by a court, a designated authority under disability legislation, or another competent body. This is a narrower and more document-driven verification than the parental case, because guardianship is a formal legal status rather than a family relationship — the guardian will typically hold an appointment order that can be verified.
Importantly, the obligation applies only where a lawful guardian has actually been appointed. Most persons with disabilities make their own decisions and give their own consent; the provision addresses the specific case of guardianship, not disability generally. Product teams should avoid designs that force disabled users through guardian flows they do not need, which would itself raise dignity and accessibility concerns.
Operationally, this means your consent infrastructure needs a guardian pathway that is discoverable without being imposed: a way for a guardian to identify themselves, submit or reference the appointment, and manage consent on the Data Principal's behalf, with the guardianship evidence recorded in the consent trail. The volume will be small compared to the children's flow, but the population is one where processing errors carry real human consequences, and the same ₹200 crore penalty band applies.
Compliance Checklist: Getting Section 9 Ready
Section 9 readiness cuts across product, engineering, and legal, and it is best run as a discrete workstream with its own checklist rather than folded into general consent work.
Start with exposure analysis: determine honestly whether your service has users under eighteen, using declared ages, behavioural signals, and market research rather than terms-of-service wishful thinking. A terms clause prohibiting under-18 use does not make the users disappear, and regulators in other jurisdictions have been unimpressed by that defence. If your service is genuinely adult-only — say, a B2B platform — document that analysis and the controls that support it.
If children are in scope, sequence the work as follows. First, implement age determination proportionate to your risk profile. Second, build the verifiable parental consent flow, preferring token-based adult verification over document collection, and record the verification method with each consent. Third, inventory every tracking, profiling, and advertising system in your stack and implement the child-mode switch that disables prohibited processing for child accounts. Fourth, map any exemption reliance to the specific class-and-purpose combinations in the Rules. Fifth, add the guardian pathway for persons with disabilities. Sixth, design the age-of-majority transition.
Finally, evidence everything. For each child account you should be able to produce: how the user was identified as a child, who consented, how that person was verified as an adult, what processing was disabled, and when. Section 9 carries a ₹200 crore penalty band and an unusual degree of public and political attention. Of all the DPDP Act's obligations, this is the one where being able to demonstrate compliance quickly matters almost as much as being compliant.
Related articles
When You Can't Delete: DPDP Erasure Requests vs RBI and SEBI's 5-Year Retention Mandates
Significant Data Fiduciary Under India's DPDP Act: Are You One, and What It Means
DPDP Act Breach Notification: Reporting to the Data Protection Board and Data Principals
Automate your privacy compliance
See how TruePrivacy can handle DSRs, consent, and breach response — all in one platform.
Free 14-day trial · No credit card required · Setup in minutes