Building Apps for Children in India: Verifiable Parental Consent Under the DPDPA

The three commandments of Section 9

Section 9 does three things, and each reshapes product design. First, before processing any personal data of a child, a Data Fiduciary must obtain verifiable consent of the parent or lawful guardian, verifiable being the operative word, an unticked box asking “are you over 18?” verifies nothing and everyone knows it. Second, fiduciaries must not undertake processing likely to cause any detrimental effect on the well being of a child, a broad protective standard that will grow case law of its own. Third, fiduciaries must not undertake tracking or behavioural monitoring of children or targeted advertising directed at children, a flat ban, not a consent gate: a parent cannot consent your ad targeting into legality. Pause on the third, because its product implications are the largest. The advertising funded model, where engagement data feeds profiles that feed targeted ads, is simply unavailable for users under eighteen in India. Contextual advertising, ads matched to content rather than to the child’s profile, remains the workable lane, and analytics must be re examined: aggregate product analytics survive, individual level behavioural profiling of child users does not.

Verifiable parental consent: how verification actually works

Rule 10 turns “verifiable” into machinery. The fiduciary must adopt appropriate technical and organisational measures to ensure the consenting adult is identifiable and is in fact the parent or lawful guardian, and verification can rest on reliable identity and age details already held by the fiduciary, on details voluntarily provided, or on a virtual token mapped to identity documents, with the Rules pointing at Digital Locker, DigiLocker, integration as a sanctioned route: the parent authenticates through the government backed document wallet, establishing adulthood and identity without the app warehousing copies of Aadhaar cards. Practically, compliant flows are converging on a pattern. The app determines whether the user is a child, honest age gating at signup, with design that does not coach the lie. If a child, the flow forks to the parent: an invitation by phone or email, the parent completes verification, DigiLocker token, or verified details, receives the itemised notice, what data, what purposes, the standard our consent notices article details, and gives the affirmative consent that unlocks the child’s account. The consent is recorded, notice version, verification method, timestamp, because the burden of proving it sits on the fiduciary, and the parent gets standing controls: visibility, withdrawal, and grievance access. Teams that build this as reusable infrastructure, a parental consent service rather than a one off screen, ship every subsequent feature faster. The honest engineering note: age assurance at scale is genuinely hard, self declaration is gameable, document checks add friction, and inference is imperfect. The Rules ask for appropriate measures rather than perfection, which means documented, risk proportionate design: an edtech platform marketed to schools needs stronger assurance than a general news app, and your reasoning should live in a written assessment you can show the Data Protection Board.

The exemption lanes, read narrowly

The framework provides relief valves, each narrower than hopeful readings suggest. Certain classes of fiduciaries and purposes are exempted from parts of Section 9, healthcare providers verifying for treatment, educational institutions for defined educational purposes, childcare contexts, and specified protective purposes, with the exemptions attached to the Rules’ schedules and conditions rather than available for self service. The government can also notify age assurance relaxations and lower effective burdens for defined cases. Two disciplines keep teams safe here: map your claimed exemption to the exact schedule entry and conditions, not to its vibe, and remember the tracking and targeted advertising bans are not among the things a typical exemption washes away. Persons with disabilities have a parallel protection: verifiable consent of the lawful guardian is required where a guardian acts for a person with disability, with the Rules detailing guardian verification, a requirement product teams routinely forget because the American playbooks contain nothing like it.

The build sequence for the May 2027 deadline

Sequenced for a real roadmap. First, the census: determine honestly whether children can be on your product, not whether your terms say they cannot, a terms clause banning under eighteens that your marketing contradicts is evidence against you, not protection. Second, the fork: design the age gate and parental flow, choosing verification methods per your risk assessment, with DigiLocker integration scoped early because government integrations take quarters. Third, the purge: locate and shut off behavioural profiling, ad targeting, and tracking for child users, including the SDK exhaust, third party kits do not know your user is a child unless your integration tells them, and their collection is your liability. Fourth, the paperwork: children’s clauses in your privacy notice, the consent records, the written age assurance assessment, and the DPIA if you are a Significant Data Fiduciary, a designation processing children’s data at scale makes more likely, as our SDF criteria article explains. Fifth, the drill: a breach involving children’s data is the worst day version of the seventy two hour reporting duty, rehearse it.

Can AI help with children’s data compliance?

In several load bearing places. AI can power age assurance itself, inference models flagging probable child accounts for the consent fork, and audit your SDK and data flows to find where child data leaks into profiling pipelines, the purge step’s hardest labour. It can draft the parental notices in plain language and multiple Indian languages, simulate the consent flows for usability, parents abandon flows that feel like visa applications, and keep the consent records queryable for the Board. Two cautions carry special weight here. Age inference models process children’s data to protect children’s data, so they need their own lawful basis, minimisation, and bias testing, the irony is regulatory, not rhetorical. And the detrimental effect standard, whether a feature harms a child’s well being, is a human judgment with ethical weight that no classifier should own. Use AI for detection, drafting, and audit; keep qualified humans on the judgments, because the statute’s strictest chapter protects the people least able to complain.

When to Review This

• India’s children’s data regime is strict by design: eighteen as the line, verifiable parental consent with real identity machinery behind it, DigiLocker as the sanctioned route, flat bans on tracking and targeted advertising that no consent can unlock, narrow scheduled exemptions, and a 200 crore penalty head enforceable from May 2027. For builders the work is a sequence, census, fork, purge, paperwork, drill, and the teams that treat parental consent as infrastructure rather than a screen will ship faster forever after. The strictest chapter of the DPDPA protects users who cannot advocate for themselves; build like the Board will read your flow, because one day it might.