Verifiable Parental Consent Under DPDP Rule 10: A Compliance Guide for Platforms With Under-18 Users
A practical breakdown of how to obtain and verify parental consent under DPDP Rule 10, covering the three verification routes and how to build a compliant workflow.
Once your platform has established that Section 9 of the DPDPA applies to it, the next question is operational. Obtaining verifiable parental consent under DPDP Rule 10 needs to hold up to scrutiny, without turning onboarding into a dead end for legitimate users. Get this wrong, and a platform ends up either blocking genuine parents at sign-up or building a consent record that cannot survive a regulator's or a court's later review.
Section 9 establishes the obligation: parental consent is required before a platform processes a child's personal data. Rule 10 of the DPDP Rules, 2025 addresses the part Section 9 leaves open, setting out how that consent has to be obtained and verified so it counts as evidence, not just a checkbox.
For the broader obligations governing children's personal data, see the guide to processing children's data under DPDPA Section 9.
This article stays on the mechanics: what verifiable parental consent means in practice, the three verification routes Rule 10 permits, how those routes map to real onboarding scenarios, and what a workable consent workflow and evidence trail look like once you build it.
What Verifiable Parental Consent Means Under Rule 10
Verifiable parental consent under DPDP Rule 10 means the organisation has confirmed, through a defined and repeatable method, that the person giving consent on a child's behalf is an identifiable adult, before any of the child's personal data is processed.
Section 9(1) of the DPDPA sets the underlying obligation: a Data Fiduciary must obtain the consent of the parent or lawful guardian before processing a child's personal data. Rule 10 builds on that obligation with a due diligence standard. The organisation must take appropriate technical and organisational measures to establish two things about the person identifying as the parent: that they are an adult, and that they are identifiable if a regulator or court later needs to check. A form field asking someone to confirm their age does not meet that standard on its own, because it does not establish either fact.
The Three Ways a Platform Can Verify a Parent
Rule 10 does not prescribe one verification technology. It sets out three routes for reaching the same standard, and an organisation can rely on whichever route fits the situation in front of it.
Identity and age details the platform already holds
If the parent is already a registered adult user of the platform, and the organisation holds reliable identity and age information from that existing relationship, this can support verification directly. A retail app where a parent already has a verified account, and is now setting up a linked profile for a child, sits in this category.
Identity and age details the parent provides directly
Where the platform has no prior relationship with the parent, the parent can provide identity and age information voluntarily as part of the consent journey. This route depends entirely on the reliability of the details supplied and the checks the organisation runs against them.
A virtual token issued by an authorised entity
The third route uses a virtual token, mapped to the individual's identity and age details, issued by an entity entrusted with issuing such tokens. The Rules name Digital Locker service providers as an example of such an entity. It is worth being precise here: DigiLocker is one example of an authorised entity, not the prescribed mechanism itself. The final Rules also tightened the definition of authorised entity. The draft version described an entity entrusted with maintaining identity and age details. The final Rules describe an entity entrusted with issuing those details or a token mapped to them.
Each route places a different amount of verification work on the parent. Details already held by the platform create the least friction but only work for existing users. Details provided directly create more friction and depend on the platform's own checking process. A token from an authorised entity shifts the verification work to a third party the parent already trusts, at the cost of an extra step in the journey.
How Rule 10's Illustrations Apply in Practice
The Rules include illustrations to clarify how these routes work in practice. Translated into platform scenarios, three situations come up most often.
The parent is already a registered user. A parent with an existing, verified account on the platform wants to create a linked account for their child. The organisation can rely on the identity and age details it already holds for that parent, provided those details remain current and reliable.
The parent is new to the platform. A child wants to sign up, and the platform has no existing relationship with the parent. The organisation needs to collect identity and age details directly from the parent, or route the parent through an authorised entity, before the child's account can be created.
Verification runs through a virtual token. The parent uses a token issued by an authorised entity, such as a Digital Locker service provider, to confirm their identity and age without submitting the underlying documents directly to the platform. The platform verifies the token, and does not need to see the raw identity document.
Building the Verification and Consent Workflow
A Rule 10 workflow generally follows the same sequence in your organisation, regardless of which verification route applies in a given case.
Identify the child account. The platform determines, at sign-up or account creation, that the user is under 18.
Initiate the parent journey. The platform routes the flow to a parent or guardian instead of allowing the child to self-certify.
Verify the parent's adult status. The organisation applies one of the three routes above to confirm the parent is an identifiable adult.
Present the consent request. The parent sees a clear notice describing what data will be collected and why, before being asked to consent.
Capture affirmative consent. The parent takes a deliberate action to consent. Silence or inaction should not be treated as consent.
Associate consent with the child account. The system links the verified parent's consent record to the specific child account it covers.
Maintain the evidence. The organisation retains a record of how and when the consent was obtained, in case it needs to demonstrate compliance later.
Each step matters on its own. A platform that verifies the parent correctly but fails to link that consent record to the right child account, or fails to retain evidence of it, has not built a defensible workflow even if the verification step itself was sound.
What Counts as Good Evidence of Parental Consent
Rule 10 does not prescribe an exact record format for your organisation to follow. The following is a practical governance recommendation, not a mandated checklist. A useful consent record typically includes:
the child account or internal identifier the consent applies to
the verified relationship between the parent and the child
the verification route used (existing details, directly provided details, or a virtual token)
the date and time verification and consent were completed
the purpose for which consent was requested
the version of the notice presented to the parent at the time
the current consent status, and any later withdrawal or change
Recording this at the point of consent makes the evidence usable if a grievance or regulatory query arises later. Reconstructing it afterward is far harder and less reliable.
Keeping Parental Consent Consistent Across Connected Systems
Parental consent captured once at onboarding needs to reach every system that later processes that child's data. Most platforms with any scale run more than one system: an app or website, a CRM or CDP, and one or more backend processing systems, and each of these needs to respect the same consent status.
A few design questions are worth working through before this becomes a problem. Does the consent status attach to the correct child account across every connected system, including the ones where it was not first captured? Does a withdrawal reach every downstream system it needs to, and not stop at the one it was submitted through? Does the organisation have a single source of truth for consent status, so two systems cannot hold conflicting records for the same child? Working through these questions early, as part of the workflow design in the previous section, costs far less than retrofitting consent propagation after the systems are already live.
A Rule 10 Readiness Checklist
Use these questions as a working checklist when your product, legal, and compliance teams review a Rule 10 workflow:
Verification: Can the platform establish that the consenting individual is an adult?
Identity: Can that individual be identified if legally required?
Timing: Is parental consent obtained before the child's personal data is processed?
Association: Is the verified consent linked to the correct child account?
Evidence: Can the organisation reconstruct how and when consent was obtained?
Propagation: Does consent status reach every system that processes the child's data?
Lifecycle: Do withdrawal and subsequent changes update every connected system?
One scope note worth keeping in mind while working through this checklist: Rule 10 governs how consent is verified once the obligation applies. It is separate from the Fourth Schedule exemptions, which relieve specific classes of Data Fiduciaries, such as certain healthcare, education, and child transport providers, from Section 9(1) and 9(3) for narrowly defined purposes, including real-time location tracking carried out for a child's safety. This article addresses the Rule 10 verification workflow. It does not cover whether your organisation qualifies for a Schedule IV exemption, which is a separate assessment.
Where a Consent Management Platform Fits Into Rule 10 Compliance
Verifying that a parent is an adult, and confirming their identity, typically involves systems and processes outside a consent platform, such as identity verification services or an authorised entity's token issuance. A Consent Management Platform is not a substitute for that step. Where a CMP like OneConsent supports Rule 10 compliance is everything that happens after verification: capturing consent against the correct purpose, associating it with the right child account, keeping consent status synchronised across connected systems, recording a time-stamped evidence trail, and propagating withdrawal or changes without manual work.
If your organisation is building or reviewing a Rule 10 workflow and wants to see how consent capture, evidence, and synchronisation fit into that process, visit OneConsent to learn more about the platform.
To walk through how this would apply to your specific onboarding flow, book a demo with the OneConsent team.
Frequently Asked Questions
Have more questions?
Search our full DPDP knowledge base for more answers.