Children's Data Under the DPDP Act: Parental Consent and Age Verification

If anyone under eighteen can use your service, the DPDP Act asks more of you than it asks of anyone else — and one of those duties cannot be satisfied by getting consent, however carefully you collect it. This guide works through what Section 9 actually requires, whether you are obliged to check your users' ages, and how to build the parental-consent step for a school, an EdTech platform or a consumer app.

Who the Law Calls a Child

A child is anyone who has not completed eighteen years (Section 2(f)). Not thirteen, not sixteen — eighteen, with none of the per-country variation the GDPR permits. For a school this means practically every student on the roll. For a coaching centre, most of them. For a consumer app or a game, a share you probably have never measured.

The Central Government can lower that bar under Section 9(5), but read the provision closely before relying on it: it is a bespoke notification for a specific Data Fiduciary that has satisfied the government its processing is "verifiably safe" — not a general power to set a lower age for an industry. No such notification has been issued. The operative age is eighteen for everyone.

Three Duties, and Only One Is About Consent

Section 9 is short, and the most expensive mistake businesses make with it is reading all of it as a consent problem. It is three separate duties.

Why Section 9(3) is the one to read twice

Section 9(3) says a Data Fiduciary "shall not undertake tracking or behavioural monitoring of children or targeted advertising directed at children." Note what is absent: any mention of consent. Section 9(1) is drafted as a consent obligation and says so. Section 9(3) is drafted as a flat bar on the company. Parental consent does not unlock behavioural advertising to a child, no matter how well you collect it.

If that reading seems strict, the Rules settle it. Rule 12 disapplies sub-sections (1) and (3) of Section 9 as separate carve-outs for the classes and purposes in the Fourth Schedule. If consent under 9(1) could cure a 9(3) problem, there would be no reason for the Rules to exempt 9(3) independently. The drafting only makes sense if 9(3) stands on its own.

For anyone running an ad-funded app or game, this is the commercially significant sentence on the page: your exposure sits in the ad and analytics stack, not the consent flow. Behavioural ad SDKs, engagement profiling, lookalike targeting and retargeting aimed at under-18s are barred however good your parental-consent screen is. Non-personalised contextual advertising is widely argued to sit outside 9(3), but the text does not say so and there is no Board guidance yet.

Section 9(2) is the vaguest of the three. "Well-being" is undefined in the Act, unelaborated in the Rules, and has no Board guidance behind it. Treat it as an open standard you should be able to show you considered — a recorded decision, not a settled test.

Does the Law Require You to Verify Age? No — and That Is Not the Relief It Sounds Like

This is the question every product team asks first, and the market's compliance advice runs ahead of the statute on it.

Neither the Act nor the Rules impose a freestanding age-verification or "age assurance" obligation. The phrase does not appear. Section 9(1) bites before processing the data "of a child"; Section 9(3) bites on tracking "of children". The duties are triggered by the user being a child — not by a duty to check first. Rule 10's verification machinery, read carefully, is aimed at confirming that the self-identified parent is an adult. There is no child-age-verification rule anywhere in the framework. You will see it asserted that DPDP "requires age gates". It does not, on the text.

The relief is narrower than it appears, and the reason matters. Section 9 carries no knowledge qualifier. There is no "actual knowledge" standard of the kind the American COPPA regime uses, and no safe harbour anywhere for a self-declared age. An unchecked "I am over 18" tick-box is not mentioned in the Act, not blessed by the Rules, and is not a defence on the face of either. If a child in fact used your service, Sections 9(1) and 9(3) were engaged in fact — whatever the user told you at signup.

So the honest position is this: age assurance is risk mitigation, not a statutory requirement. The law does not order you to build an age gate; it holds you to duties you cannot discharge unless you have some idea who is a child. Most teams serving a mixed-age audience conclude that some age signal is the only practical way to meet a duty with no knowledge defence. That is a business decision made in the shadow of the law — not compliance with a rule. Be sceptical of anyone who tells you otherwise while selling you the gate.

What "Verifiable" Parental Consent Actually Requires

Rule 10 sets the mechanics, and it is less prescriptive than most vendors will tell you. You must adopt appropriate technical and organisational measures to ensure the parent's consent is obtained, and do due diligence that the person claiming to be the parent is an adult who is identifiable — traceable if Indian law later requires it. Rule 10 offers three routes to that check:

1. Reliable identity and age details you already hold. If the parent is already a registered user of yours and you hold verified details for them, you can rely on your own records.
2. Details the individual voluntarily provides. Government-issued identity details supplied by the parent at the point of consent.
3. A virtual token mapped to such details, issued by an authorised entity. The parent's age is confirmed and only a token is shared, rather than the underlying document.

Three corrections to claims you will hear. No specific technology is mandated — the obligation is framed by outcome. DigiLocker is not required: a Digital Locker service provider appears inside the definition of "authorised entity" as something that is included, not prescribed. And the token route is not yet operational, because the Digital Locker service provider it depends on is itself subject to a government notification that has not issued. Plan the first two routes; treat the third as something to adopt when it arrives.

Note also what Rule 10 does not ask. It does not require you to verify the family relationship — the due diligence is that the person is an identifiable adult. And it does not ask you to verify the child at all.

Are You Exempt? The Fourth Schedule Test

Rule 12 disapplies Sections 9(1) and 9(3) for certain classes of Data Fiduciary (Fourth Schedule, Part A) and for certain purposes (Part B). The carve-outs are real, and they are narrower than the sectors they name.

Part B exempts purposes rather than institutions: duties under Indian law performed in the child's interests; subsidies, benefits and licences; creating a user account limited to email communication; real-time location tracking for a child's safety; filtering harmful content or advertising away from children; and confirming that a user is not a child.

If you want to work through your own position rather than read a table, our children's data check asks four questions and returns the obligations that attach to you, with the section behind each.

Implementation: Three Situations

How you build this depends almost entirely on one thing — whether you already know the parent.

1. You already hold the parent's verified details

This is the school and the clinic. The parent is already a party to the relationship, and you hold identity and age details for them from admission or registration. You are on Rule 10's first route: rely on your own records, and make sure the consent record ties the parent to the specific child and the specific purpose. Build order:

• Identify which of your records are for under-18s, from date of birth, not from a guess
• For each, identify the parent record and confirm the details you hold are reliable enough to stand as the due-diligence basis
• Collect consent per purpose, not once for everything
• Log what was consented to, by whom, when, and on what basis you concluded they were an adult

2. The parent is a stranger

This is the consumer app and the game. You have no prior relationship with the parent, so route one is closed and you are pushed to details the parent supplies at the point of consent. In practice that means a consent step that leaves the child's device — a link to the parent's phone or email — and a record of the details they provided.

Two design points matter more than the technology. First, the consent must be per purpose: a parent agreeing to an account is not agreeing to marketing. Second, withdrawal must be as easy as giving it was (Section 6(4)), and the parent must be able to exercise it — which means they need a way back in that does not depend on the child's device.

3. You have a mixed-age audience and no idea who is a child

This is the hardest case and the most common one. Nothing requires you to build an age gate; nothing protects you if a child uses the service and you did not. The practical sequence:

1. Find out whether you have the problem. Look at what you already hold — dates of birth, school affiliations, the age skew of your support tickets. Many teams assume they have no under-18 users and have never checked.
2. Decide on an age signal and write down why. Self-declaration is weak and is not a defence, but it is not nothing; a stronger signal costs conversion. This is a risk decision, and the record of having made it deliberately is worth as much as the choice.
3. Deal with 9(3) first, because it is the one consent cannot fix. If you cannot reliably separate children from adults, behavioural advertising and tracking directed at that population is exposure you cannot consent your way out of.
4. Then build the 9(1) path for the users you do identify as children.

The Ad and Analytics Stack Is Where the Exposure Sits

Most teams start this work in the signup flow. If you monetise through advertising, start in the SDK list instead. Ask, for each third party in your app or site: does it profile users, build audiences, or personalise advertising? If yes, it cannot lawfully do that to a user you know or should know is a child — and "we got parental consent" is not an answer to Section 9(3).

The same applies to product analytics that builds behavioural profiles, and to any lookalike or retargeting audience exported to an ad platform. Your vendors are Data Processors under Section 8, and Section 8(1) keeps you responsible for processing done on your behalf whatever the contract says.

Sector Playbooks

Schools and coaching centres

Whether you are a CBSE, ICSE, state-board or international school, almost every student record is children's data. The Fourth Schedule gives educational institutions room for tracking tied to educational activities and in-institution safety. It does not cover marketing to parents, an advertising SDK, or sharing data with an EdTech vendor for that vendor's own purposes. Work through the admission form as it actually exists in an Indian school: the ERP or school-management system your office runs on, the GPS-tracked bus app, the annual-day and sports-day photo galleries, the fee-payment gateway, and Aadhaar or birth-certificate copies taken at admission. Those are separate purposes, and one blanket consent form at admission does not cover them.

Schools already operating need parental consent for existing students by 13 May 2027, when the substantive rules commence. For an institution with hundreds of students that is a project, not a task, and it is far easier to run at the start of an academic year, alongside admissions in April, than in the middle of one.

Student data also cannot be kept forever. Set a retention period (commonly 3–7 years for academic records), write it down, and delete on it (Section 8(7)).

EdTech platforms

India's online-learning sector, from the large national test-prep and K-12 platforms to the many smaller coaching apps selling into the same market, usually processes on behalf of schools and directly for learners, and the two carry different obligations. Where you deal directly with a learner under 18, Section 9 applies to you in your own right. The engagement analytics that are standard here are exactly what Section 9(3) addresses: time on task, attention signals, streaks, and personalised recommendation built on behavioural profiles. A school's Fourth Schedule room does not automatically extend to a vendor selling into it. The exemption belongs to the institution and its conditioned activity, not to everyone in its supply chain.

Consumer apps and games

You are the case the Fourth Schedule does not cover. This is where India's exposure is largest and least measured: mobile games and social apps with heavy teenage usage, real-money and fantasy-sports platforms that already carry their own age restrictions, and regional-language content apps whose sign-up flow never asks for a date of birth. Assume Section 9 applies in full, deal with the ad stack first, and build the parental-consent path for the users you identify as children. If you are a foreign developer holding no Indian assets and believe enforcement cannot reach you, note Section 37. After penalties in two or more instances, the Central Government may direct the blocking of public access to the service in India.

What It Costs If You Get It Wrong

Breach of the Section 9 obligations sits in the Schedule to the Act at up to ₹200 crore — the second-highest tier, behind only the ₹250 crore security-safeguards entry. These are ceilings ("may extend to"), and the Board sets the actual figure using the factors in Section 33(2), which include the nature and gravity of the breach, whether you mitigated it, and what you did about it once you knew.

The obligations commence on 13 May 2027 (as of September 2026). That is not far away for a school that has to go back to every existing family, or for a product team that has to unpick an advertising integration.

A 90-Day Sequence

If you are starting from nothing, this order wastes the least effort:

1. Days 1–15 — find the children. Establish whether under-18s are in your data at all, from records rather than assumption. Use the free DPDP checker if you are not yet sure the Act applies to you.
2. Days 15–30 — audit the ad and analytics stack. List every SDK and integration that profiles, targets or tracks. This is the Section 9(3) work, and it is first because consent cannot fix it later.
3. Days 30–45 — decide your age signal and record the reasoning. Including the decision to rely on self-declaration, if that is where you land.
4. Days 45–70 — build the parental-consent path. Per purpose, with a withdrawal route the parent can actually use, and a consent record that captures the basis for your adult check.
5. Days 70–90 — write the retention and deletion rule for children's data, and check your privacy notice describes all of this in language a parent can read.

The full DPDP compliance checklist covers the obligations that apply to every business alongside these. If you operate outside India and serve Indian users, our guide for foreign companies covers how Section 9 interacts with the rest of the cross-border picture, and the readiness guide for global companies sets out the sequence for a mature privacy programme.

How EasyDP Helps

EasyDP's parental consent flow is in early access — being built now, not yet shipped. It is designed to flag records for users under 18 from their date of birth, send the consent request to the parent rather than the child, collect consent per purpose, and keep the record of what was consented to, by whom and when, in a form you can produce if the Board asks. It will be available in every major Indian language, because the parent reading the request is often not reading in English.

Until it ships, the children's data check and the consent notice generator are free and need no signup.