Children's data under the DPDP Act and Rules

Eighteen, not thirteen

Section 2(f) defines a child as an individual who has not completed the age of eighteen years. That single number is the most consequential design fact in the entire children's regime, and it is the one most often imported incorrectly from elsewhere.

Products built to American norms assume thirteen, because that is where COPPA sits. Products built to European norms assume a member-state age between thirteen and sixteen under the GDPR. India sets it at eighteen with no sliding scale, which means a very large share of secondary-school and undergraduate users of an Indian consumer product are legally children.

For an edtech platform, a gaming service or a social product with teenage users, this is not a narrow edge case to handle later. It may describe the majority of the user base, and it changes what the product is permitted to do with them.

Verifiable parental consent, before processing

Section 9(1) requires the Data Fiduciary, before processing any personal data of a child, to obtain verifiable consent of the parent. The obligation is a precondition, not a step that can be completed after onboarding.

Verifiable is the operative word, and it sets a higher bar than the consent standard in section 6. Ordinary consent must be free, specific, informed, unconditional and unambiguous. Verifiable consent must additionally be attributable to a real adult who is genuinely this child's parent or lawful guardian - which is an identity problem, not a checkbox problem.

A tick-box asserting I am over 18 or I am this child's parent verifies nothing. It records a claim. Where the Rules prescribe the manner, follow it exactly; where a product must design its own flow, the question to answer is what evidence would survive a Board asking how you knew that adult was that child's parent.

Persons with disability with a lawful guardian

Section 9(1) covers a second group in the same breath: a person with disability who has a lawful guardian. Verifiable consent of the lawful guardian is required on the same terms.

This group is routinely dropped from implementations because it does not map onto an age check, and age is what engineering teams know how to build. Guardianship is a legal status established under other law, not something inferable from a date of birth, so the same flow will not detect it.

The honest design answer is usually a declared route: a way for a guardian to identify themselves as acting for an adult with a lawful guardian, handled with the same verification rigour as parental consent, rather than an attempt to detect the situation automatically.

Two prohibitions that no consent can unlock

Sections 9(2) and 9(3) are not consent-gated. They are flat prohibitions, and this is the structural point teams most often miss: obtaining perfect verifiable parental consent does not license the conduct they forbid.

Section 9(2) forbids processing likely to cause any detrimental effect on the well-being of a child. Section 9(3) forbids tracking, behavioural monitoring of children, and targeted advertising directed at children.

A parent cannot consent to their child being behaviourally profiled for advertising, because the Act does not make that a matter for consent at all. Any product whose economics depend on advertising to under-eighteens in India needs to confront that at the business-model level rather than the consent-flow level.

What section 9(3) rules out in practice

Tracking and behavioural monitoring cover more than advertising pixels. Engagement optimisation that profiles a child's behaviour to decide what to show next, retention mechanics tuned on individual behavioural signals, and cross-service activity linking all sit uncomfortably close to the line.

The safe reading is that a child account should not be subject to individual behavioural profiling for commercial optimisation. Aggregate, non-individualised analytics used to improve a service, and monitoring genuinely necessary for safety - abuse detection, for instance - are a different matter and are the strongest candidates for the carve-outs.

This is the provision most likely to require a product change rather than a policy change, which is why it should be assessed early. A team that discovers in April 2027 that its recommendation system is not permissible for a third of its users has a rebuild, not a compliance task.

The Fourth Schedule carve-outs

Section 9(4) anticipated that a blanket rule would produce absurd results, and Rule 12 with the Fourth Schedule delivers the exceptions. Part A lists classes of Data Fiduciary exempt from sections 9(1) and 9(3); Part B lists exempt purposes.

Part A begins with clinical establishments, mental health establishments and healthcare professionals, where processing is restricted to providing health services to the child. Without that carve-out, verifiable parental consent would gate a child's emergency care - which is exactly the outcome section 9(4) exists to prevent.

Read the Schedule against your own activity rather than assuming either that it rescues you or that it does not apply. The exemptions are drawn by class and by purpose, and they are conditional - an exempt class processing for a non-exempt purpose is outside the carve-out.

Age assurance is the real engineering problem

Section 9 creates a duty that only bites once you know, or should know, that a user is a child - and the Act does not tell you how to find out. That gap is where most of the implementation effort actually goes.

Three approaches exist and each has a cost. Self-declared age is cheap and weak. Verified identity is strong and excludes users who have no identity document, which disproportionately affects the children the provision protects. Inference from behaviour is a form of profiling and sits awkwardly beside section 9(3).

There is no clean answer, which is why the decision should be made deliberately, documented with its reasoning, and revisited. A product that has never asked the question at all is in a materially worse position than one that chose a defensible method and wrote down why.

Section 9(5): a safe harbour that does not exist yet

Section 9(5) allows the Central Government, if satisfied that a Data Fiduciary processes children's data in a manner that is verifiably safe, to notify an age above which that Fiduciary is exempt from the section 9(1) and 9(3) obligations.

This is a per-Fiduciary, discretionary mechanism rather than a general standard, and it is not something to build a launch plan around. Treat it as a possible future relief for organisations that have already built a strong regime, not as a route to avoid building one.

The planning assumption for anything shipping before 13 May 2027 should be that sections 9(1) to 9(3) apply in full, with only the Fourth Schedule carve-outs available.

What an edtech, gaming or social product should build

The work divides into a determination layer, a consent layer and a restriction layer, and they are independent enough to be built in parallel by different teams.

The restriction layer is the one to start with, because it is the one that can invalidate a product decision. Establishing which of your systems profile individuals, and whether they can be switched off per account, tells you early whether you have a configuration change or a rebuild.

• An age determination method, chosen deliberately and documented with its reasoning.
• A verifiable parental consent flow that produces evidence, not a declaration.
• A separate route for lawful guardians of persons with disability.
• A per-account switch disabling behavioural profiling, tracking and targeted advertising.
• An assessment of section 9(2) well-being risk for features aimed at engagement.
• A Fourth Schedule assessment recording which carve-outs you rely on, and why.

How this differs from GDPR and COPPA

Teams porting an existing children's-privacy implementation into India usually find that the shape is familiar and the details are not. Three differences matter enough to redo the analysis rather than adapt it.

The age is the first. COPPA sets thirteen; the GDPR sets a member-state age between thirteen and sixteen for information-society services; the DPDP Act sets eighteen with no variation. A user population that was largely adult under one regime can be largely child under this one.

The second is that section 9(3) is a prohibition rather than a consent condition. Under the GDPR, profiling a child for marketing is lawful in principle with an appropriate basis and heightened safeguards. Under the DPDP Act, tracking, behavioural monitoring and targeted advertising directed at children are simply not permitted, and no consent cures that.

The third is the absence of a general age-assurance standard. The GDPR requires reasonable efforts to verify consent taking available technology into account, and regulators have published detailed age-assurance guidance. The DPDP framework leaves the method to the Data Fiduciary, which places more of the burden of justifying the choice on you.

Write down the assessment, whatever you conclude

Because so much of section 9 turns on judgement - whether you have child users, whether a feature is behavioural monitoring, whether a Fourth Schedule carve-out applies - the record of how you decided is a substantial part of the compliance position.

A short written assessment per product, revisited when the product changes materially, is enough. It should state whether children are expected users and on what evidence, which processing was assessed against section 9(3) and what was concluded, which carve-outs are relied on and why they apply, and what age-assurance method was chosen and what was rejected.

The value of writing it down is not the document. It is that section 9(3) questions get answered by the people who know what the system does, at a point when the answer can still change the design, rather than by whoever is available during an inquiry.

Before 13 May 2027

Section 9 commences with the main operational tranche. The compliance work is unusually front-loaded compared with the rest of the Act, because two of the three obligations are product constraints rather than paperwork.

Sequence it as: determine whether you have child users at all and roughly how many; assess which features section 9(3) forbids for them; then build consent and age assurance. Teams that reverse this order build an elaborate consent mechanism and then discover the underlying processing was never permissible.