At a glance
Under the DPDP Act, anyone under 18 is a child, and the moment your service processes a child’s personal data you owe verifiable parental consent and a ban on tracking or targeting them — whether or not you set out to serve minors. The trigger is use, not intent: “we’re not a kids’ app” isn’t a defence if minors are on it. The first job is to work out honestly whether children are among your users, then build age-gating and parental-consent flows to match.
Educational resource only. This explains when the children’s-data obligations under India’s Digital Personal Data Protection Act, 2023 (DPDP Act) and its Rules apply to a business; it is not formal legal advice.
The situation
You built a product for a general audience — a fitness app, a game, a learning tool, a social feature — and you never marketed it to children. But some of your users are under 18, because that’s true of almost any consumer service in India. The question that decides a real chunk of your compliance work is whether the Act’s children’s-data rules apply to you, and the answer turns on facts about your actual users, not on how you positioned the product.
Who counts as a child under the Act
The DPDP Act sets the bar at 18 — higher than most product age gates assume. Section 9 of the DPDP Act governs the processing of a child’s personal data, and the Act defines a child as anyone under the age of eighteen. That’s notably higher than the 13-or-16 thresholds baked into a lot of platforms designed around foreign law, so a product that treats its “teen” users as ordinary adults is very likely mis-classifying a group the Act protects. There’s no partial-adult tier: someone who is 17 is a child under the Act, with the full set of protections that follow, right up to their eighteenth birthday.
One forward-looking caveat: the Act does contain a mechanism (Section 9(5)) for the government to notify a lower age for a Data Fiduciary that processes children’s data in a verifiably safe manner — in which case users above that notified age could be treated as adults. Nothing has been notified to date, so today the line is a flat 18. Treat it as a space to watch, not a current exception you can build on.
The trigger is use, not intent
You don’t get to opt out of the children’s rules by saying you didn’t mean to have child users. The obligations attach to processing a child’s personal data, and if children are demonstrably using your service, you are processing it — regardless of your terms of service saying under-18s aren’t allowed. A blanket “you must be 18 to use this” line in the fine print doesn’t discharge the duty if your product is, in reality, used by minors. This is the single most common misread: teams assume a terms-of-service age bar is a shield, when what the Act cares about is what’s actually happening. If a meaningful number of your users are under 18 — or your product is the kind that predictably attracts them — the rules are in play, and the honest starting question is factual, not aspirational.
What switches on the moment minors are on your service
Three obligations arrive together — a consent gate, a processing ban, and a wellbeing duty. Once you’re processing a child’s data, the Act requires, at minimum:
- Verifiable parental consent before you process the child’s personal data — real confirmation that an adult parent or guardian has consented, not a self-reported checkbox. This is a genuine verification step, and it’s covered in depth in its own guide.
- No tracking, behavioural monitoring, or targeted advertising directed at the child — a hard prohibition that parental consent does not unlock. Even a fully consented account can’t be profiled or ad-targeted.
- No processing likely to cause a detrimental effect on the child’s wellbeing — a broader duty of care over how the data is used.
There’s a defined set of exemptions for specific sectors and purposes (certain educational, healthcare, childcare and child-safety uses), but they apply only where the specific purpose genuinely fits — they aren’t a category you can self-assign to skip the rules. And the penalty exposure here is not the baseline: children’s-data breaches sit near the top of the Act’s penalty scale, which is why getting the applicability question right matters before anything else.
Step by step: working out if this applies to you
Answer the factual question first, then design to the answer.
- Estimate your real under-18 user base, honestly. Use whatever signals you have — age fields, school or exam-linked usage, support interactions, the nature of the product. Don’t reason from your marketing; reason from your users.
- Ask whether your product predictably attracts minors even if they’re a minority — games, learning tools, social and video features, anything with a youth pull. “Predictably used by children” carries the same weight as “designed for children.”
- If the answer is yes or probably, treat the children’s-data obligations as live and move to an age-assurance and parental-consent design rather than relying on a terms-of-service age bar.
- If the answer is genuinely no — a B2B tool, a product realistically used only by adults — document your reasoning, and revisit it if your audience shifts. “No” is a position you should be able to justify, not just assert.
- Check any exemption against your actual purpose, not the sector you belong to, before assuming it lets you skip verification.
Designing for it before you’re sure
When you can’t cleanly rule minors out, build as if they’re there — retrofitting child protections is far more expensive than designing for them. The costly version of this problem is discovering, after launch and after you’ve been profiling and ad-targeting your whole base, that a chunk of it was under 18 the entire time. The cheaper path is to assume some users are children unless you have a solid reason not to, and to build the age-assurance step and the parental-consent route early, so the tracking-and-targeting suppression can switch on for confirmed minors from day one. Treating children’s-data compliance as a design input rather than a post-launch patch is the difference between a feature you shipped and a liability you’re unwinding under a penalty tier you don’t want to be near.
FAQ
Does the DPDP Act’s child definition really go up to 18?
Yes. A child is anyone under eighteen. That’s higher than the 13/16 thresholds common in products built around US or EU norms, so “teen” users you’ve been treating as adults are children under the Act.
Our terms say under-18s can’t sign up — are we covered?
No, not on its own. If minors are actually using the service, you’re processing their data and the rules apply. A terms-of-service age bar doesn’t discharge the obligation when the real-world usage contradicts it.
What if only a small fraction of our users are minors?
The obligations still apply to the processing of those children’s data. A small proportion doesn’t make the rules optional — it just scopes how many accounts need the child-specific handling.
Are we exempt because we’re an ed-tech or healthcare product?
Not automatically. The exemptions cover specific sectors and purposes, but only where the actual purpose fits — commercial ed-tech, for instance, isn’t blanket-exempt. Check the specific use, not the label.
What’s the risk if we ignore this?
You’d be processing children’s data without a valid basis and likely tracking or targeting them in breach of the Act — exposure that sits near the top of the DPDP penalty scale, well above the general baseline.