Children's data under the DPDP Act: verifiable parental consent explained
Why the DPDP Act treats everyone under 18 as a child, how verifiable parental consent works under Rule 10, the tracking ban, and the Fourth Schedule exemptions.
The DPDP Act treats anyone under the age of 18 as a child — a notably higher threshold than the 13 to 16 years used in most other jurisdictions. For ed-tech platforms, gaming companies, social apps, e-commerce sites and any service that young people might use, Section 9 of the Act and Rule 10 of the 2025 Rules introduce some of the most demanding obligations in the entire framework.
Non-compliance with the additional obligations relating to children can attract a penalty of up to ₹200 crore. Here is what they require and how to design for them.
Who counts as a child — and who gives consent
A "child" is an individual who has not completed eighteen years of age. When the Data Principal is a child, the definition of Data Principal expands to include their parent or lawful guardian. The same applies to a person with a disability who has a lawful guardian acting on their behalf.
This means that for a child user, consent must come from the parent, notices must be addressed to the parent, and rights requests may be made by the parent.
The three core obligations under Section 9
- Verifiable parental consent. Before processing a child's personal data, you must obtain the verifiable consent of the parent or lawful guardian.
- No detrimental processing. You must not process personal data in a way likely to cause any detrimental effect on the well-being of a child.
- No tracking, behavioural monitoring or targeted advertising. You must not undertake tracking or behavioural monitoring of children, or targeted advertising directed at children.
The third obligation is the one that most changes product design. Personalised feeds driven by behavioural signals, ad-tech pixels and interest-based ad targeting all need to be switched off for child users unless an exemption applies.
What "verifiable" consent means under Rule 10
The Rules require a Data Fiduciary to adopt appropriate technical and organisational measures to ensure verifiable consent, and to observe due diligence to check that the individual identifying as the parent is an adult who is identifiable. Two routes are described:
- using reliable details of identity and age already available with the Data Fiduciary — for example, where the parent is already a verified registered user of your service; or
- using details of identity and age, or a virtual token mapped to them, that are voluntarily provided by the parent or issued by an entity entrusted by law or the government with maintaining such details — such as a Digital Locker service provider.
The illustrations in the Rules walk through common situations: a child tries to register and indicates they are a minor; the parent is already a known user; or the parent is new and must verify through a trusted provider. Your onboarding flow should handle each path.
Design principleVerify the parent, not the child. The goal is to confirm an identifiable adult is consenting — collecting extensive identity documents from children themselves creates new risk and is not what the Rules ask for.
Age assurance: how do you know a user is a child?
The Act does not prescribe a particular age-verification technology, but you cannot rely on willful blindness. A sensible, proportionate approach usually layers:
- Neutral age gates at sign-up that do not nudge users toward an adult age;
- Contextual signals — a school-focused product should assume child users;
- Escalation to stronger verification when risk indicators appear;
- A clear path to convert an account to a parent-managed one when a user turns out to be a minor.
Document why your chosen approach is proportionate to your audience and risk. That record is your evidence of due diligence.
Exemptions in the Fourth Schedule
The Rules recognise that some services cannot function without processing children's data in ways that would otherwise be restricted. The Fourth Schedule exempts specified classes of Data Fiduciaries and purposes from the verifiable-consent requirement and from the tracking prohibition, subject to conditions — typically that processing is restricted to what is necessary for the child's interests or safety.
| Type of exemption | Illustrative examples |
|---|---|
| Classes of fiduciary | Clinical establishments and healthcare professionals; educational institutions; crèches and child day-care centres; transport providers engaged by schools |
| Purposes | Exercising legal powers or functions; providing a subsidy or benefit; creating a user account restricted to email communication; real-time location tracking for a child's safety; ensuring content harmful to children is not accessible |
Read the Fourth Schedule closely before relying on an exemption: each one is limited to the extent necessary for the stated purpose, and an exemption for one activity does not cover your whole product.
Product changes most services will need
- A separate "child mode" configuration that disables behavioural personalisation, third-party trackers and ad targeting.
- A parent-consent flow with verification, plus a parent dashboard for managing consent and rights.
- Default privacy settings for child accounts: private profiles, no public discovery, limited messaging.
- Content and feature reviews against a "detrimental effect on well-being" test — streaks, infinite scroll and loot-box mechanics deserve scrutiny.
- Vendor review: confirm SDKs and analytics tools can be turned off or configured for child users.
Persons with disabilities
For a person with a disability who has a lawful guardian, the Rules require the Data Fiduciary to verify that the guardian is appointed by a court, a designated authority or a local-level committee under the applicable law (such as the Rights of Persons with Disabilities Act, 2016 or the National Trust Act, 1999). Build a verification step for guardianship documents into the same flow you use for parental consent.
A children's-data readiness checklist
- Decide whether children are likely to use your service and document the reasoning.
- Implement age assurance proportionate to that likelihood.
- Build a verifiable parental-consent flow using the routes in Rule 10.
- Switch off tracking, behavioural monitoring and targeted ads for child users.
- Map any Fourth Schedule exemptions you rely on, and their limits.
- Train support teams to handle requests from parents and guardians.
In the final article of the series, we bring everything together: the Data Protection Board, the penalty schedule, Significant Data Fiduciary obligations and a practical compliance roadmap.
