Processing Children's Data Under DPDPA Section 9: What Every Platform Must Do

If a company operates a website, app, or any kind of digital service in India, there is a good chance Section 9 of the DPDPA applies to you, even if the platform was never set out to build something for children. That is the part a lot of businesses miss. It does not matter who you intended your audience to be. What matters is who can actually access the platform.

And once children are in the picture, the rules get a lot stricter, a lot faster.

Why This Section Deserves Attention

Let us start with the number that tends to grab people's attention: penalties under Section 9 can go up to ₹200 crore. That alone should be enough to make any founder or compliance team sit up straight. But honestly, the fine is not even the scariest part.

Think about what happens to a brand's reputation the moment a story breaks about a platform mishandling children's data. Trust, once broken that way, is brutally hard to rebuild. Parents talk. Media picks it up fast. And regulators tend to move quicker when kids are involved. So while the legal risk is real, the reputational fallout can end up being the more expensive problem long-term.

The bottom line for founders: if your app, website, service, or even a physical channel is something a minor could use, Section 9 is not optional reading. It is the rulebook you are operating under.

Who Actually Counts as a Child

This is one area where the DPDPA does not overcomplicate things. Section 2(f) defines a child as an individual who has not completed 18 years of age. That is consistent with most other Indian laws, so there is no ambiguity to hide behind.

Compare that to something like GDPR, where certain EU countries allow a lower age threshold for consent purposes. India has not gone that route. There is no wiggle room, no "well, in our case maybe 16 is fine" argument. If someone under 18 can land on your platform, the child-data obligations kick in, whether or not you ever marketed to them.

The Real Challenge: Verifiable Parental Consent

Here is where things get genuinely tricky for a lot of businesses. Section 9(1) does not just ask you to collect consent. It demands verifiable consent from a parent or legal guardian. Not the child. The parent.

That single requirement changes everything about how you design onboarding. A checkbox that says "I confirm I am over 18" does not cut it anymore, and honestly, it probably never should have. You now need a system that can genuinely confirm the person giving consent is who they claim to be, an actual verified adult, not just someone typing "yes" on a form.

This is, understandably, the part that keeps product teams up at night. Verification is not just a legal checkbox; it is an engineering and UX problem rolled into one.

What Counts as Valid Age Verification

So what does "verified" actually look like in practice? The DPDP Rules, 2025 (Rule 10) go further than the Act, requiring that verifiable consent be tied to an authenticated adult established through a reliable identity and age source.

The Rules sketch two broad pathways for age and identity verification: an Aadhaar-linked DigiLocker mechanism in which a parent's credentials get associated with a child's account, and an electronic token system in which a government identity document is converted into a limited disclosure credential.

What definitely does not work: a child simply declaring they are over 18, or an unverified adult claiming parental status without any backing proof. Self-declaration, in either direction, is not going to hold up.

If your current sign-up flow relies on a simple age-gate question, it is worth pausing here and asking whether that would actually survive scrutiny.

No More Quiet Tracking

Here is something a lot of platforms do not expect: even after you have got valid parental consent, Section 9(3) prohibits tracking or monitoring a child's behaviour. That means no cookies-based tracking, no device fingerprinting, no location tracking, no behavioural analytics, none of it.

Consent for basic data collection does not open the door to profiling. These are treated as two completely separate things under the law, and that distinction matters a lot if your platform leans on personalization or analytics to function.

If your product roadmap includes features like "smarter recommendations based on user activity," you will need a very clear line drawn around child accounts before that logic touches them.

Targeted Ads Are Off the Table Too

Following the same logic, the Act draws a hard line on advertising. You simply cannot serve targeted ads to children based on their personal data. This holds true even when a parent has already agreed to basic data processing for that account.

So even if consent exists on paper, your ad delivery system still needs to know which users are children and quietly exclude them from anything that relies on behavioural or personal targeting.

Turning This Into an Actual Plan

Reading the law is one thing. Building around it is another. If your platform is accessible to minors, here is roughly what needs to happen on your end:

Put real age verification in place at sign-up, not a checkbox, an actual mechanism.

Build a parental consent flow that genuinely verifies the parent's identity through a reliable source.

Create a separate data-handling path for verified child accounts, one that skips behavioural tracking and ad targeting entirely.

Go through your analytics and advertising SDKs with a fine-tooth comb to make sure none of them are quietly pulling data from child users.

Keep documentation of your verification and consent processes, because if you are ever audited, "we are pretty sure we did it right" will not count for much.

None of this is a weekend fix. It usually means rethinking parts of your architecture, not just adding a new form field.

Section 9 Obligations Are a Core Part of DPDPA Compliance

Section 9 is not just another compliance checkbox tucked away in the DPDPA. It is arguably the strictest part of the whole Act, and for good reason. It reflects a fairly simple idea: kids deserve a higher bar of protection online than adults do, and that protection should not depend on whether a business intended to serve them.

If there is even a chance minors can reach your platform, it is worth treating this seriously now rather than reactively later. Getting it right is not only about avoiding a massive fine. It is about building something that parents, regulators, and users alike can actually trust.
For organisations building child-focused or age-accessible digital services, managing parental consent requires more than a basic age gate. A dedicated consent management platform can help centralise age verification, parental consent records, consent status, and audit trails while supporting DPDPA-focused workflows. OneConsent is designed to help organisations build a structured approach to consent management and child-data compliance.