How to implement age-verification gates for Indian apps under DPDP

At a glance

The DPDP Act makes you treat under-18s differently, but it doesn’t hand you an age-verification method — Rule 10 verifies the parent, not the child. So age assurance is your design problem: reliable enough to route real minors into the parental-consent flow, proportionate enough that you’re not demanding ID from every adult to check. The workable pattern is a tiered gate — a low-friction age signal first, stepping up to stronger checks only where risk or signals warrant — never a self-declared birthdate treated as proof.

Educational resource only. This explains how to design age-assurance gates for children’s-data compliance under India’s Digital Personal Data Protection Act, 2023 (DPDP Act) and its Rules; it is not formal legal advice.

The situation

To apply the children’s-data rules you first have to know who your children are — which sounds like it needs an age-verification system, and you may have assumed the Act tells you which one to build. It doesn’t. Section 9 of the DPDP Act creates the obligation to treat under-18s differently, but leaves the mechanics of working out who’s under 18 to you. That’s freedom and a trap at once: freedom to design proportionately, and a trap if you either under-build (a birthdate box you treat as proof) or over-build (collecting everyone’s ID and creating a bigger data problem than the one you solved).

Why DPDP creates the need but not the method

The Act mandates the outcome — no unconsented processing of a child’s data — without prescribing an age-gate technology. Rule 10 of the DPDP Rules is specific about verifying the parent’s identity and adult status when you obtain parental consent; it does not lay down a method for verifying the child’s age in the first place. So there’s no statutory age-verification product you’re required to bolt on, and anyone selling you a mandated “DPDP age gate” is overstating the Rules. What the Act does require, in effect, is that you don’t end up processing a child’s data as if they were an adult — which means your age-assurance step has to be good enough that real minors actually get routed into the child-data handling, not waved through. The obligation is on the result, and the design is yours to justify.

The Act does contemplate one future flexibility here: Section 9(5) lets the government notify a lower age for a fiduciary that processes children’s data in a verifiably safe manner, above which users could be treated as adults. Nothing has been notified to date, so design today to a flat under-18 line — the verifiably-safe pathway is worth tracking, but it isn’t a threshold you can assume yet.

The proportionality trap: don’t ID everyone

Forcing hard identity checks on your entire user base to catch the minority who are minors trades one compliance problem for a worse one. The tempting over-correction is to demand government ID or a full identity verification from every user at signup. That does establish age — and it also turns your whole product into a collector and custodian of sensitive identity documents for millions of adults who never needed to provide them, expanding your attack surface, your retention duties, and your breach exposure dramatically. Minimisation cuts against that: the age check should be proportionate to the actual risk your product poses to children, not maximal by default. A low-risk service doesn’t need to fingerprint every adult to satisfy the Act; it needs a sensible gate that reliably catches minors and steps up its rigour only where the stakes or the signals justify it.

What “reliable enough” actually means

A self-declared birthdate isn’t proof, but it isn’t worthless either — the question is what you do when signals suggest a minor. A date-of-birth field that anyone can type past is not, on its own, a reliable age gate; treating it as one is the under-building failure. But age assurance isn’t binary between “typed birthdate” and “full ID.” Reliability comes from combining signals and escalating: the declared age, behavioural and contextual cues, whether the account trips youth-associated patterns, and a step-up to stronger verification where a lighter check isn’t enough. The standard to aim for is that a genuine minor is unlikely to sail through as an adult, and that when your signals point to a child, you actually act on it — route them to the parental-consent flow rather than assuming the birthdate box did its job. “Reliable enough” is judged against the risk to children in your specific product, which is why a game or social app is held to a stiffer version of this than a low-risk utility.

Step by step: building a tiered age-assurance gate

Start light, escalate on signal, hand off cleanly.

1. Assess your product’s risk to children first — how likely minors are to use it and how sensitive the processing is. This sets how strong your gate needs to be; don’t pick a mechanism before you’ve sized the risk.
2. Collect an initial age signal at the entry point — a genuine date-of-birth or age input, framed neutrally so it isn’t obviously nudging users to claim adulthood.
3. Layer in corroborating signals rather than trusting the declared age alone — contextual and behavioural cues that flag likely-minor accounts for a closer look.
4. Define a step-up path for when signals suggest a minor or the risk is higher: a stronger age-assurance check, proportionate to the situation, instead of one heavy check imposed on everyone.
5. On a minor determination, route to the parental-consent flow — don’t let the account proceed as an adult. This is the whole point of the gate.
6. Keep the age check itself minimal and well-retained — collect only what the assurance needs, and don’t hoard identity documents you gathered along the way beyond their purpose.
7. Log how each age determination was made, so you can show your gate is reasonable and consistent if it’s ever questioned.

Where age assurance hands off to parental consent

Age assurance and parental consent are two stages of one flow — the gate decides who’s a child; Rule 10 decides how their guardian consents. It helps to see them as sequential, not competing. The age-assurance step answers “is this user under 18?” using your proportionate gate; when the answer is yes, the flow hands off to the verifiable-parental-consent route, where the Rules do prescribe how you confirm the adult guardian. Building them as one connected pipeline — assurance, then verified parental consent, then child-safe defaults with tracking and targeting suppressed — is what turns a scatter of half-measures into a compliant design. The mistake to avoid is treating age-gating as the finish line: identifying a minor is the trigger for the real obligations, not the discharge of them.

FAQ