Verifiable Parental Consent Under DPDP: What It Means for Your Product

India's DPDP Act defines a child as anyone under 18, and it requires verifiable parental consent before processing a child's personal data. Two things make this different from the GDPR equivalent: the threshold is higher (GDPR is 16, with member states able to lower it to 13), and the Rules go further by prohibiting behavioural monitoring and targeted advertising directed at children entirely.

For products with any under-18 user base, this is not a footnote. It is a design constraint that changes onboarding, data collection, and advertising. This post covers what the law requires, what "verifiable" means in practice, and how to build for it. It is not legal advice.

The legal shape

The DPDP Act requires a data fiduciary to obtain verifiable parental consent before processing the personal data of a child. The Rules add specifics:

• The parent or guardian must be identifiable and contactable
• The consent must be verifiable: the fiduciary must have a reasonable basis to believe the consenting adult is the parent or lawful guardian
• Behavioural monitoring of children is prohibited
• Targeted advertising directed at children is prohibited

The prohibitions are the sharp edge. Under GDPR, the equivalent protections are largely consent-gated; under DPDP, these two activities are banned outright for children, not subject to consent at all.

Why "verifiable" is the hard part

"Verifiable parental consent" sounds administrative and is actually a hard product problem. How do you know the adult on the other end is the parent? The spectrum of approaches:

• Self-declaration. The user states they are a parent. Weak, but it is a floor.
• Age-gated flows with parent confirmation. The child's flow pauses and hands off to a parent confirmation step (email or OTP to a parent).
• Documentary verification. ID checks, appropriate for the highest-risk processing (health, financial).
• Payment-adjacent verification. A card present or UPI confirmation, where the product already has a payment relationship.

The right answer depends on your sector. A game with children users needs a lighter touch than a health product. The phrase to hold onto: verifiable means you can demonstrate a reasonable basis for believing the adult is the parent, which is an evidence requirement, not a checkbox.

Age assurance: the prerequisite

You cannot route children into a parental consent flow if you do not know who is a child. Age assurance is the upstream problem, and it has its own spectrum:

• Self-declared age at signup (easy to defeat, but it is the baseline)
• Behavioural and interaction signals (estimate, not proof)
• Document-based verification (strong, higher friction)

The honest engineering guidance: start with declared age plus friction at the boundary, and increase verification where the data is sensitive or the audience skews young. The DPDP Rules' ban on behavioural monitoring of children means your age assurance cannot itself rely on monitoring a child's behaviour, which rules out the creepier estimation techniques for this population.

What this does to your product

For a product with under-18 users, the DPDP requirements change several surfaces:

1. Onboarding. An age gate before collection, with a parental handoff for minors.
2. Data minimisation. Collect less from children by default; the consent surface is parental, and the data should match the purpose.
3. No behavioural ads to children. The advertising stack needs an age check before targeting, and the safest design is not to target children at all.
4. The record. Parental consent needs the same proof properties as ordinary consent: what the parent was shown, what they approved, when. The consent receipts post covers why the record matters.

The parental consent lifecycle

A parental consent flow is a consent flow with an extra actor:

Child reaches age gate
        ↓
Declared as under 18
        ↓
Parent handoff (OTP / email / verification)
        ↓
Parent shown notice + purposes
        ↓
Parent gives or withholds consent
        ↓
Receipt records what the parent saw and chose
        ↓
Child's data processed only within that consent

Withdrawal parity applies to parents too: a parent must be able to withdraw consent as easily as they gave it.

Where this fits in the platform picture

Parental consent is a specialised consent flow on top of the same machinery: versioned notice, per-purpose choice, immutable receipts, withdrawal parity. Erasure's Accord is built around that machinery, and the consent manager ecosystem, with registration opening November 2026, will eventually be part of how parents manage consent across fiduciaries. The consent manager post covers that angle.

The bottom line

Verifiable parental consent under DPDP is an under-18 threshold (higher than GDPR's 16), a verifiability requirement, and a pair of outright prohibitions on behavioural monitoring and targeted ads to children. Products with minor users need an age gate, a parental handoff with a real verification step, and the same evidence discipline as every other consent event.

The consent under DPDP post covers the consent test these flows must satisfy, and the compliance checklist slots parental consent into the full work list.