Few areas of the DPDP Act carry higher stakes than the handling of children's data. The Act sets demanding protections for minors, backed by some of its steepest penalties, and it applies to far more organisations than just those that deliberately target children. Any service realistically used by young people needs to take these rules seriously as part of dpdp compliance.
The core idea is simple: children cannot meaningfully consent to the processing of their own data, so the law requires a verifiable adult to consent on their behalf and prohibits uses that could exploit or harm them.
But translating that idea into practice — verifying age, obtaining verifiable parental consent, and removing harmful tracking — raises real design challenges that are far easier to build in from the start than to retrofit.
This guide explains who counts as a child under the Act, what verifiable parental consent means, the prohibitions on tracking and targeted advertising, and how organisations should design for compliance.
Who is a child under the Act
Under the DPDP Act, a child is anyone who has not completed eighteen years of age. This is a higher threshold than some other jurisdictions, which set the line at thirteen or sixteen, and it sweeps a large population into the special-protection regime.
Where the data principal is a child, the role effectively shifts to the parent or lawful guardian, who exercises rights and gives consent on the child's behalf. The child remains the subject of the data, but an adult acts for them.
The high age threshold means many mainstream services — social, gaming, education, streaming — will have substantial numbers of users who are legally children, whether or not the service was designed for them.
Because the threshold is so high, it is wise to assume, for any consumer-facing service, that some users are children unless you have strong reason and means to believe otherwise. That assumption drives protective defaults rather than reactive fixes.
Verifiable parental consent
Processing a child's personal data requires consent from a parent or lawful guardian, obtained in a verifiable manner. It is not enough to ask a user to confirm they are an adult or to tick a box claiming to be a parent; the consent must be genuinely verifiable.
This means an organisation must take reasonable steps to confirm both that the person consenting is an adult and that they are entitled to act for the child. The 2025 Rules describe how such verification can be approached in practice.
Building a verifiable parental-consent flow is a meaningful engineering task, involving age signals, identity verification, and a record of the consent obtained — which is why it should be planned early.
Recording the parental consent you obtain is as important as obtaining it. If challenged, you need to be able to show not just that consent was given, but that it was verifiable — who consented, how their adult status was established, and when.
The ban on harmful tracking and advertising
Beyond consent, the Act prohibits certain uses outright. A data fiduciary must not undertake tracking or behavioural monitoring of children, or targeted advertising directed at children. These are banned regardless of whether parental consent has been given.
This is a hard line, not a consent-based permission. It reflects a judgement that profiling and targeting children for commercial purposes is harmful in itself, so no amount of consent unlocks it.
For ad-supported and engagement-driven products, this requires real changes: turning off behavioural advertising and tracking for users identified as children, and rethinking features that rely on profiling young users.
For many ad-supported products, this prohibition forces a genuine rethink of the business model for younger users. Designing engaging, non-exploitative experiences for children, without behavioural targeting, becomes both a compliance requirement and a design challenge worth investing in.
Age assurance as a design problem
Because the protections turn on whether a user is a child, knowing a user's age becomes essential. This makes age assurance a central design question: how does the service determine, with reasonable confidence, whether a user is under eighteen?
Approaches range from self-declaration backed by signals, to more robust verification where the risk warrants it. The right level of assurance is proportionate to the service and the data involved, but doing nothing is not an option for services likely to reach minors.
A sensible default is to route users who cannot be reliably established as adults into the protective path, because over-protecting is cheap while under-protecting a child's data is among the costliest mistakes under the Act.
Age assurance need not be invasive to be effective. Combining declared age with behavioural and contextual signals, and escalating to stronger verification only where the risk warrants it, balances protection against a frictionless experience for adult users.
Exemptions for certain classes
The Act and Rules allow the Government to exempt certain classes of fiduciaries, or certain purposes, from some of the children's-data obligations — for instance, where processing is necessary in contexts such as healthcare or education, subject to conditions.
These exemptions recognise that rigidly applying every restriction could harm children in some settings, such as preventing a school or clinic from functioning. But they are defined and conditional, not a general escape.
Organisations should not assume an exemption applies; where they rely on one, they should confirm the conditions are met and document the basis, treating it as a deliberate exception rather than a default.
Where you rely on a notified exemption, document precisely which one and why it applies. Treating exemptions as deliberate, recorded exceptions — rather than convenient assumptions — is what keeps your position defensible if a regulator looks closely.
Why the stakes are so high
Children's-data failures sit among the Act's most serious. Breaching the obligations around children can attract penalties of up to ₹200 crore, reflecting how seriously the law treats the protection of minors.
Beyond the financial exposure, mishandling children's data carries acute reputational risk. Few failures attract public anger as quickly as the perception that a company exploited or endangered children's information.
This combination of legal and reputational risk means children's-data compliance deserves senior attention and conservative design, not a minimal, box-ticking approach.
Free resource
The Ultimate Guide to the DPDP Act
A practical, plain-English handbook to the DPDP Act & 2025 Rules — scope, roles, consent, safeguards and a readiness path.
Designing a compliant approach
A compliant approach combines several elements: age assurance to identify child users, a verifiable parental-consent flow for processing their data, the disabling of tracking and targeted advertising for children, and records that evidence the consent obtained.
It also means reviewing existing features and data flows to find places where children's data is processed without these protections — often in services that never intended to serve minors but do in practice.
Building these protections in from the design stage is far cheaper and cleaner than bolting them on after launch or after a regulator raises concerns.
Treating children's data as a priority
For any organisation whose services reach young people, children's-data compliance should be treated as a priority workstream, not an edge case. The high age threshold means the obligations apply broadly, and the penalties make the cost of getting it wrong severe.
The organisations that handle this well start from the assumption that some of their users are children, design protective defaults, and verify rather than assume. That posture protects both the children and the business.
Done thoughtfully, strong children's-data practice is also a trust signal to parents and regulators alike — evidence that the organisation takes its responsibilities to its most vulnerable users seriously.
Free consultation
Need help getting DPDP-ready?
Talk to our compliance team — we’ll map your gaps against the Act and the 2025 Rules.