What is verifiable consent under DPDP?
By Abhijeet Singh · Primary sources verified by dpdprules.orgPublished · Last reviewed 8 min read
What does verifiable consent mean under the DPDP framework?
The short answer
Verifiable consent is the consent that, once section 9 is in force, a Data Fiduciary must obtain from a parent or lawful guardian before processing the personal data of a child or of a person with disability who has a lawful guardian. The term is defined by cross reference: Rule 2(1)(d) says it means a consent as specified in rule 10 or 11, so its content is whatever those rules require. For a parent, Rule 10 requires appropriate technical and organisational measures plus due diligence that the individual identifying herself as the parent is an adult, identifiable if required in connection with compliance with any law in force in India, by reference to either identity and age details the Data Fiduciary already reliably holds, or details voluntarily provided, directly or through a virtual token issued by an authorised entity. Adult means having completed 18 years. For a lawful guardian, Rule 11 requires verifying appointment by a court, a designated authority or a local level committee under the applicable guardianship law. Section 9 and Rules 10 and 11 are all in 18 month commencement groups, computed as 13 May 2027 and interpretation until officially confirmed.
Ordinary consent is a design problem. Verifiable consent is a verification problem, and it is one of the few places in this framework where the Rules tell you, case by case, what a compliant flow looks like.
The term is defined by pointing somewhere else
Start with the definition, because it saves an argument. Rule 2(1)(d):
"“verifiable consent” means a consent as specified in rule 10 or 11."
That is circular on purpose. There is no abstract standard of verifiability in this framework, no threshold of confidence to reach, and nothing to benchmark against. Verifiable consent means whatever Rule 10 requires for a parent and whatever Rule 11 requires for a lawful guardian, and nothing more.
The Act uses the term without defining it. Section 9(1):
"The Data Fiduciary shall, before processing any personal data of a child or a person with disability who has a lawful guardian obtain verifiable consent of the parent of such child or the lawful guardian, as the case may be, in such manner as may be prescribed."
"In such manner as may be prescribed" is doing all the work. Until the Rules were notified in November 2025 the duty had no content at all, which is worth remembering when you read guidance written before then.
One structural point that catches people out: the parent is not a third party here. Section 2(j) folds the parent and the lawful guardian into the definition of Data Principal: where the individual is a child, the Data Principal includes her parents or lawful guardian. On this site's reading, a parent giving verifiable consent therefore does so as a Data Principal under the Act and not as an outside third party.
What Rule 10 actually requires for a parent
The whole sub rule, because the shape of the sentence matters:
"A Data Fiduciary shall adopt appropriate technical and organisational measures to ensure that verifiable consent of the parent is obtained before the processing of any personal data of a child and shall observe due diligence, for checking that the individual identifying herself as the parent is an adult who is identifiable if required in connection with compliance with any law for the time being in force in India, by reference to — (a) reliable details of identity and age of the individual available with the Data Fiduciary; or (b) details of identity and age, voluntarily provided — (i) by the individual; or (ii) through a virtual token mapped to such details, which is issued by an authorised entity."
2 duties, joined by "and": adopt appropriate technical and organisational measures, and observe due diligence. They are not the same thing, and a product team can satisfy the first with a consent screen while doing nothing about the second.
The due diligence has 2 reference routes, and they are alternatives, marked by "or":
Route (a): details you already hold. If the person claiming to be the parent is already your user and you reliably hold identity and age details for her, you check against your own records. No external verification, no document upload.
Route (b): details voluntarily provided. Either directly by the individual, or through a virtual token mapped to those details and issued by an authorised entity.
"Adult" is defined: an individual who has completed the age of 18 years. "Authorised entity" is an entity entrusted by law or by the Central or a State Government with issuing identity and age details or a token mapped to them, or a person that entity appoints or permits.
One sentence in Rule 10 is genuinely ambiguous, and it is expensive
Look again at "is an adult who is identifiable if required in connection with compliance with any law for the time being in force in India".
Where that condition attaches is not clear on the face of the sub rule. It can be read as qualifying "identifiable", so that establishing identifiability is required only where another law requires it. It can also be read as qualifying the due diligence more broadly. On the first reading a documentary identity check is conditional; on the second it is closer to standard.
This site does not decide which reading is right, and no authority construing it has been found. It is flagged because it is the difference between a light touch parent check and an identity verification programme, and because guidance that states one of these readings as settled is overstating.
The 4 illustrated cases, which are the useful part
The Illustration to Rule 10 walks 4 combinations, with C a child, P a parent and DF a Data Fiduciary. Map your onboarding onto them directly.
| Case | Who starts | Is P already your user? | What Rule 10 has you do |
|---|---|---|---|
| 1 | C, declaring P as her parent | Yes, and you already hold her identity and age details | Enable P to identify herself, then confirm you hold reliable identity and age details of P and that P is an identifiable adult |
| 2 | C, declaring P as her parent | No | Check P is an identifiable adult by reference to details issued by an entity entrusted by law or by the Government, or to a virtual token mapped to them |
| 3 | P, opening the account for C | Yes, and you already hold her details | Confirm you hold reliable identity and age details of P and that P is an identifiable adult |
| 4 | P, opening the account for C | No | Same external check as Case 2, and the Illustration adds that P may voluntarily make the details available using a Digital Locker service provider |
The pattern is simpler than it looks. Who initiates changes the interface, not the check. What changes the check is whether you already hold reliable details for the parent. Cases 2 and 4 are the only ones that need an authorised entity or a token.
The route everyone talks about is not operational
Digital Locker is the mechanism most discussed in this area, and it is the one that depends on something that has not happened. Rule 10(2)(c):
"“Digital Locker service provider” shall mean such intermediary, including a body corporate or an agency of the appropriate Government, as may be notified by the Central Government, in accordance with the rules made in this regard under the Information Technology Act, 2000 (21 of 2000)"
So the definition is not self executing. A given provider counts once the Central Government notifies it under the Information Technology Act rules. No such notification has been located as at 27 August 2026, on a check of every official document archived on this site and a search of the public record. That is a negative finding from a search rather than a statement in any instrument.
It is also not yet a problem, because Rule 10 is not in force either. But it does mean a build plan that assumes a named Digital Locker integration is available is assuming a notification, and should say so.
Guardians are verified legally, not biometrically
Rule 11 handles the other limb, and its due diligence is documentary:
"A Data Fiduciary, while obtaining verifiable consent from an individual identifying herself as the lawful guardian of a person with disability, shall observe due diligence to verify that such guardian is appointed by a court of law, or by a designated authority or by a local level committee, under the law applicable to guardianship."
3 appointment routes, and Rule 11(2) names the statutes that give them meaning: the Rights of Persons with Disabilities Act, 2016, whose section 15 supplies the designated authority, and the National Trust for the Welfare of Persons with Autism, Cerebral Palsy, Mental Retardation and Multiple Disabilities Act, 1999, whose section 13 supplies the local level committee.
Nothing here asks you to assess a disability. It asks you to verify an appointment, which is a different and more tractable task.
What Rule 10 does not ask for
Worth stating, because these get built when they are not required.
- No verification that the child is a child. Rule 10's due diligence is about the parent being an identifiable adult. It sets no duty to establish the age of the child. Confirming that a Data Principal is not a child appears elsewhere, as a Part B purpose in the Fourth Schedule to the Rules, and that is a route out of section 9 duties rather than a duty inside Rule 10.
- No prescribed document, and no biometric requirement. Route (b) is satisfied by details voluntarily provided, and the token route is an alternative rather than a mandate.
- No repeat verification cycle. Rule 10 fixes the check at a point in time, before processing, and prescribes no interval for repeating it.
When this starts, and what to do
Section 9 sits inside sections 7 to 10 in the 18 month group of G.S.R. 843(E), and Rule 1(4) puts Rules 10 and 11 in the Rules' own 18 month group. So the duty and the manner prescribed for it arrive together, computed as 13 May 2027 and interpretation until officially confirmed.
The build sequence that follows:
Work out whether you are in scope at all before designing a parent check. If your product is used by children, the exemptions in Rule 12 and the Fourth Schedule decide how much of section 9 you owe, and they are narrower than the sector assumes. What the Fourth Schedule exemption really covers reads the education entry line by line, and the children's data checker gives the duty set with sources.
Design for Case 1 and Case 3 first. Where the parent is already your user, the check runs against your own records and needs no external dependency. That covers most family accounts on an existing platform.
Treat Cases 2 and 4 as the integration work, and do not plan them around a named Digital Locker provider until one is notified.
Do not resolve the ambiguity in Rule 10(1) for yourself in a compliance document. Record both readings and the position you have taken, so that a later clarification does not make your file look like it asserted something the text does not say.
Rule 10, official text →Rule 11, official text →DPDP for schools and edtech: what the Fourth Schedule exemption really covers →