DPDPA Rule 10: Verifiable Parental Consent for Processing a Child’s Personal Data

For two decades, the internet’s primary age verification system has been a button that says, “Yes, I am 18.” It is a well-written lie we all agreed to ignore. DPDPA Rule 10 ends the joke.

If you are processing child data under DPDPA, the burden shifts from a simple UI checkbox to actual, verifiable identity confirmation. Rule 10 sets a clear operational requirement for any Data Fiduciary: before processing, you must obtain verifiable consent from the parent, and you must perform due diligence to confirm that the person claiming to be the parent is an identifiable adult.

What Rule 10 Requires

A checkbox is not a technical measure. Under DPDPA Rule 10, a Data Fiduciary must adopt appropriate technical and organisational measures to ensure that verifiable consent of the parent is obtained before processing any personal data of a child.

But the rule goes further. You must also check that the person identifying herself as the parent is an identifiable adult for compliance purposes. You can do this by referencing either:

• Reliable identity and age details already available with you, or
• Identity and age details voluntarily provided by the individual, or
• A virtual token mapped to identity and age details issued by an authorised entity.

The duty is twofold. First, secure valid parental consent. Second, verify that the consenting person is an identifiable adult using acceptable references or tokens.

Key Definitions That Shape Execution

To build a compliant verification flow, you need to know whose authority actually counts. The rule defines the boundaries:

• Adult: An individual who has completed 18 years of age.
• Authorised entity: An entity entrusted by law or by the Central or State Government with issuing identity and age details or a virtual token mapped to such details. This includes a person appointed or permitted by that entity for such issuance, including details made available and verified by a Digital Locker service provider.
• Digital Locker service provider: An intermediary, including a body corporate or a government agency, notified by the Central Government under the Information Technology Act rules.

You cannot just take the user’s word for it. You have to take a verified source’s word for it.

Verification Pathways in Practice

Rule 10’s illustration provides four concrete situations that collapse into two operational flows. Use these as design patterns for your onboarding and consent workflows:

1) When the child initiates and identifies a parent

• If the parent is already a registered user and has previously provided identity and age details, you must check that you hold reliable identity and age details and that the parent is an identifiable adult before processing the child’s data.
• If the parent is not a registered user, you must check that the parent is an identifiable adult by referencing identity and age details issued by an authorised entity or a virtual token mapped to those details. The parent may voluntarily make these details available using a Digital Locker service provider.

2) When the parent initiates on behalf of the child

• If the parent is a registered user and has already provided identity and age details, you must confirm you hold reliable identity and age details and that the parent is an identifiable adult before processing the child’s data.
• If the parent is not registered, you must reference identity and age details issued by an authorised entity or a virtual token mapped to identity and age. The parent may use a Digital Locker service provider to make these details available.

The rule does not prescribe a single technology. It sets acceptable sources and requires due diligence that results in a verifiable link between the parental identity and the consent.

What Verifiable Consent Means

Verification is only half the battle. The consent itself must still meet Section 6 standards when consent is your legal basis. That means DPDP Act parental consent must be free, specific, informed, unconditional, unambiguous, and given through a clear affirmative action.

Pre-ticked boxes or bundled consents do not meet this standard. They are compliance theatre.

You also carry the burden of proof. If a question later arises, a database flag that says `consent=true` will not save you. You will need to show that you provided proper notice and obtained consent in accordance with the Act and Rules. Keep an audit trail for each consent instance and each verification check.

Documentation and Controls You Should Implement

Turn legal requirements into engineering realities.

• Age gating and declaration: Detect when a user is a child and trigger the parental consent flow.
• Parent identity verification: Support verification for both registered and unregistered parents, including references to data you already hold and integrations with authorised entities or Digital Locker service providers.
• Token handling: If you accept virtual tokens mapped to identity and age, ensure you validate token integrity and provenance and map it to a specific transaction.
• Consent records: Maintain timestamped records of notices, consent artefacts, identity checks, token validations, and decision logs.
• Access controls and restricted processing: Prevent any processing of a child’s personal data until verification and parental consent are complete. A locked door is useless if the data is already inside the house.

Scope Boundaries and Interplay With Section 9

Section 9 requires verifiable parental consent before processing a child’s personal data and prohibits processing likely to cause harm to a child.

The provided interpretation also describes an exemptions framework tied to a Fourth Schedule with two possible carve-outs:

• Class-based exemptions for specified Data Fiduciaries, subject to conditions.
• Purpose-based exemptions for specified processing purposes, subject to conditions.

Do not build your architecture on a hypothetical exemption. If and when such schedules are notified, exemptions would only apply where your organisation or purpose is listed and you comply with all stated conditions. They would not be blanket waivers of child protection. All other DPDPA obligations continue to apply.

Until those schedules are clear, the safest operational stance is to assume full compliance with Section 9 is required. That means obtain verifiable parental consent and avoid processing that is likely to cause harm to a child.

Ongoing Obligations That Still Apply

Even if an exemption is available in future, core obligations remain. You still own Section 8 general duties, including purpose limitation, data minimisation, retention control, and security safeguards. You still owe Section 6 consent standards if you rely on consent. Data breach notification and grievance redressal duties do not disappear.

These obligations continue regardless of how you verify parental status.

Enforcement, Risk, and Penalties

Non-compliance can trigger regulatory scrutiny. If you rely on any exemption and fail to meet its conditions, you lose the benefit and face the underlying duties. Complaints can be raised with the Board, and penalty provisions under the Act may apply.

Processing of children’s data carries elevated reputational risk. In a regulatory audit, documentation and demonstrable controls are your best defence.

Practical Implementation Checklist

• Build neutral, effective age-screening that routes children to a parental consent workflow.
• Offer multiple verification options for parents, including government ID verification, Digital Locker based attestation, tokens issued by authorised entities, or other reasonable methods.
• Prevent processing until verification completes. Enforce this with technical controls.
• Minimise data collected from children and parents. Set strict retention and deletion rules.
• Secure data with role-based access and audit logging. Regularly test your controls.
• Provide parent-facing notices and controls that are clear, concise, and actionable.
• Run periodic audits of consent records and verification artefacts. Test the integrity of identity sources and tokens.

Areas That May Require Clarification

The regulatory landscape is still settling. The provided interpretation points to a Fourth Schedule that would define exempted classes and purposes, along with conditions. It also references Section 9 coverage for persons with disability, where a lawful guardian may provide consent. Monitor official notifications for the Fourth Schedule and any guidance that sets standards for what counts as a reasonable verification method.

Closing

Rule 10 is straightforward on its core expectation, but brutal in its execution. If you process a child’s personal data, you need verifiable parental consent and a reliable way to confirm that the consenter is an identifiable adult. Build your systems so verification is repeatable, provable, and resilient. Maintain accurate records and be prepared to evidence every decision.

Execution is where teams stumble. Identity integrations, token validations, consent artefact storage, and audit trails need to work together without slowing the business to a halt. That is the difference between a compliance theory and operational reality.

At Regodit, we provide a structured way to manage these controls, document your decisions, and stay aligned with the Act. If you want to operationalise parental consent, verification, and recordkeeping across your data flows without the friction, schedule a call with our team to review your current approach.