# Children's data under DPDP: verifiable parental consent in practice

Source: https://dpdp.d2c.in/guides/dpdp-children-data/ · Updated 2026-11-13 · DPDP Ready by Mirav Labs

**Short answer:** Under the DPDP Act, anyone under 18 is a child (section 2(f)), and section 9 requires verifiable consent of a parent or lawful guardian before processing their data. Rule 10 sets how to check the parent is an identifiable adult. Tracking, behavioural monitoring and targeted ads aimed at children are barred. These duties apply from 13 May 2027, with penalties up to ₹200 crore.

## Key takeaways

- A child is anyone under 18 (section 2(f)); there is no lower age band for teenagers.
- Rule 10: verify the parent is an identifiable adult using details you already hold, or details or a virtual token from an authorised entity such as DigiLocker.
- Section 9(3) bars tracking, behavioural monitoring and targeted advertising directed at children.
- The Fourth Schedule exempts schools, healthcare, crèches and school transport for narrow purposes only.
- Breaching section 9 can attract a penalty of up to ₹200 crore.

Children's data gets its own section in the DPDP Act, and it is one of the few places where the law tells you what you may not do, not just how to do it. If your product has any users under 18, or serves parents, schools or families, section 9 and Rules 10 to 12 change your sign-up flow, your analytics and your advertising stack.

The good news is that the Rules are practical. They do not demand that you collect identity documents from every user. They ask for due diligence that a parent is a real adult, and they carve out narrow exemptions for schools, healthcare and safety uses. This guide walks through each piece and how to build it.

## Who is a child under the DPDP Act?

A child is an individual who has not completed 18 years (section 2(f)). There is no separate band for 13 to 17 year olds, so a 17-year-old on a learning app is treated the same as a 7-year-old. Under section 2(j), the Data Principal for a child includes the parent or lawful guardian, which means the parent exercises the child's rights and gives consent.

Two points are often missed:

 
- **Persons with disability.** Section 9(1) also covers a person with disability who has a lawful guardian. The DPDP (Removal of Difficulties) Order, 2026 adjusted the wording of section 9(1) to read “child or of a person with disability”. The guardian gives consent on their behalf.
 
- **No section 9(5) age has been notified.** Section 9(5) lets the government notify an age above which a specific fiduciary, whose processing is verifiably safe, is exempt from all or any of the consent and tracking duties. No such notification has been issued. Until one is, plan for 18.

## What does section 9 require?

Section 9 sets three duties. They apply from 13 May 2027, together with Rules 10 to 12.

 1**Verifiable parental consent first**Obtain verifiable consent of the parent or lawful guardian before processing any personal data of a child.

s.9(1)
 2**No detrimental processing**Do not process a child's data in a way likely to cause a detrimental effect on their well-being. No Fourth Schedule exemption lifts this.

s.9(2)
 3**No tracking or targeted ads**No tracking, behavioural monitoring or targeted advertising directed at children.

s.9(3)
 4**Narrow exemptions**Prescribed classes and purposes are exempt from 9(1) and 9(3), on conditions.

s.9(4), Rule 12

These sit on top of everything else in the Act. Parental consent still has to meet the section 6 standard: free, specific, informed, unconditional and unambiguous, given by a clear affirmative action, and limited to the data necessary for the purpose. The parent needs a proper [privacy notice](https://dpdp.d2c.in/guides/dpdp-privacy-notice/), and must be able to withdraw as easily as they consented.

## How does verifiable parental consent work under Rule 10?

Rule 10 asks you to adopt technical and organisational measures so that parental consent is obtained before you process a child's data, and to do due diligence that the person identifying as the parent is an identifiable adult (18 or over). You can check this against either:

 
- **(a)** reliable identity and age details of that person you already hold, or
 
- **(b)** identity and age details provided voluntarily, either by the person or through a virtual token mapped to those details and issued by an authorised entity. Details made available and verified through DigiLocker count.

The Rules illustrate this with four scenarios. They turn on two questions: who starts the sign-up, and whether the parent already has a verified account with you.

| Scenario | Who starts | Parent already a user with you? | How you verify the parent |
|---|---|---|---|
| 1 | The child, who says they are a child and names the parent | Yes, with identity and age details already given | Let the parent identify themselves, then confirm you hold reliable details showing an identifiable adult |
| 2 | The child, who names the parent | No | Check identity and age details from an authorised entity, or a virtual token; the parent may use DigiLocker |
| 3 | The parent, opening an account for the child | Yes | Confirm the details you already hold show an identifiable adult |
| 4 | The parent, opening an account for the child | No | Check details from an authorised entity, or a virtual token, such as via DigiLocker |

In every case, the check happens before you process the child's data for the account. In practice this means a holding state: the child's sign-up waits, with only the minimum needed to contact the parent, until the parent completes verification and consents.

### What to record

Section 6(10) puts the burden of proving notice and consent on you. For each child account, keep a consent record that links the child, the verified parent, the method of verification (held details, token, DigiLocker), the notice version shown, the purposes consented to, and the timestamp. Keep the verification result, not a copy of the parent's documents. The [consent guide](https://dpdp.d2c.in/guides/dpdp-consent/) covers record design in more detail.

### Guardians of persons with disability (Rule 11)

Rule 11 applies when someone says they are the lawful guardian of a person with disability. You must do due diligence that the guardian was appointed by a court, by a designated authority under the Rights of Persons with Disabilities Act, 2016, or by a local level committee under the National Trust Act, 1999, as the applicable guardianship law requires.

Operationally, this is a document-led check, not a token check. Build a short workflow: the guardian uploads the appointment order, a trained reviewer confirms the issuing body and the scope of guardianship, you record the outcome, and you delete the uploaded copy once its retention period ends. Keep the wording on these screens respectful; this is not a flow that should feel like fraud screening.

## Which organisations and purposes are exempt?

Rule 12 and the Fourth Schedule lift section 9(1) (parental consent) and section 9(3) (tracking, monitoring and targeted ads) for certain classes of fiduciary and certain purposes. Every exemption is conditional, and none of them lifts section 9(2), the duty not to harm a child's well-being.

| Part | Who or what | Condition: processing restricted to |
|---|---|---|
| A (class) | Clinical establishments, mental health establishments, healthcare professionals | Providing health services to the child, to the extent necessary to protect their health |
| A (class) | Allied healthcare professionals | Supporting a treatment and referral plan recommended for the child, as needed to protect their health |
| A (class) | Educational institutions | Tracking and behavioural monitoring for the institution's educational activities, or for the safety of enrolled children |
| A (class) | Individuals caring for children in a crèche or day-care centre | Tracking and behavioural monitoring for the safety of children in their care |
| A (class) | Transport providers engaged by a school, crèche or day-care centre | Tracking the location of enrolled children during travel to and from the institution, for their safety |
| B (purpose) | Exercising powers or duties under law in the child's interest | What is necessary for that power, function or duty |
| B (purpose) | Subsidies, benefits, services, certificates, licences or permits under section 7(b) | What is necessary to provide or issue them |
| B (purpose) | Creating a user account used only for email | What is necessary to create that email-only account |
| B (purpose) | Real-time location of a child | Tracking for the child's safety, protection or security |
| B (purpose) | Keeping harmful information, services or ads away from a child | What is necessary to block that content |
| B (purpose) | Confirming a user is not a child, and Rule 10 due diligence | What is necessary for that confirmation or check |

Read the conditions closely. A hospital is exempt for treating a child, not for sending the family a promotional newsletter. A school bus operator may track location during the journey, not build a profile of the family's movements.

## Does the DPDP Act apply to schools and edtech?

### Schools

Yes. A school is a Data Fiduciary for student, parent and staff data. The Part A exemption covers tracking and behavioural monitoring for educational activities and student safety, such as attendance, learning progress and campus safety. It does not cover admissions marketing, alumni fundraising, photo publication on social media, or sharing student data with vendors for their own purposes. For those, you need verifiable parental consent or another valid ground. Schools also remain responsible for their vendors (section 8(1)), so the learning platform, transport app and fee portal all need contracts with security terms.

### Edtech

The answer depends on the role. If an edtech company sells directly to families and decides how data is used, it is a fiduciary and section 9 applies in full: parental consent, no behavioural monitoring, no targeted ads. Whether an online platform counts as an “educational institution” under the Fourth Schedule is not settled, so do not build your product on that assumption without your counsel's view. If the platform runs on a school's instructions, it is likely the school's processor, and the school carries the consent duty. Many edtech companies are both, which is why a [role map](https://dpdp.d2c.in/guides/data-fiduciary-vs-data-processor/) per data flow comes first.

Watch the SDKsThird-party analytics, attribution and ad SDKs are an easy way for section 9(3) to be breached without anyone deciding to. For child accounts, switch off ad personalisation, cross-app identifiers and behavioural analytics, and confirm with each vendor what their SDK collects.

## How do you design age assurance without over-collecting?

You need to know whether a user is a child to apply section 9, but section 6(1) limits you to data necessary for the purpose. Collecting a government ID from every adult user to rule out the few children is hard to justify. A proportionate design looks like this:

 
- **Ask neutrally.** A date of birth or age prompt that does not hint at the “right” answer. Confirming a user is not a child is a Part B exempt purpose, limited to what is necessary.
 
- **Escalate on risk, not by default.** Use stronger checks only where the age answer opens up something sensitive, such as payments, open chat or adult content.
 
- **Verify the parent, not the child.** Rule 10 is about the adult. Use details you already hold, or a DigiLocker or other authorised token, before asking for anything new.
 
- **Keep the result, drop the evidence.** Store “parent verified on date, by method” rather than document images.
 
- **Default child accounts to safe settings.** No targeted ads, no behavioural profiling, limited discoverability.

Document these choices. If the Board ever asks why you did not verify every user, a written, reasoned design is far better than silence.

## What are the penalties for children's data breaches?

 
- **₹200 cr** maximum for breaching section 9 duties
 
- **18 yrs** age below which a user is a child
 
- **₹250 cr** maximum for failing to keep reasonable security safeguards

The Schedule to the Act sets ₹200 crore as the ceiling for breaching the children's obligations. The Board decides the actual amount after an inquiry, weighing the nature, gravity and duration of the breach, the type of data, whether it was repeated, and how quickly you mitigated it (section 33(2)). Children's data is likely to weigh heavily on gravity. The full table is in our [penalties guide](https://dpdp.d2c.in/guides/dpdp-act-penalties/).

## What to do next

 
- **Find your children.** List every product, form and data store where users under 18 could appear, including offline forms later digitised.
 
- **Map roles.** For each flow, decide whether you are the fiduciary or a processor for a school or partner.
 
- **Build the parent flow.** Design the four Rule 10 scenarios, a holding state for pending child sign-ups, and consent records.
 
- **Strip tracking.** Switch off targeted ads, behavioural analytics and ad SDKs for child accounts, and test it.
 
- **Check exemptions in writing.** If you rely on the Fourth Schedule, record which entry and condition applies to which processing.
 
- **Add guardian verification** for persons with disability under Rule 11.

Add these to your [DPDP compliance checklist](https://dpdp.d2c.in/guides/dpdp-compliance-checklist/) and schedule them in your [implementation roadmap](https://dpdp.d2c.in/guides/dpdp-implementation-roadmap/) well before 13 May 2027. If you want a team to design and build the parental consent flow with your engineers, [talk to us](https://dpdp.d2c.in/#contact).

## Frequently asked questions

### What is the age of a child under the DPDP Act?

Anyone who has not completed 18 years (section 2(f)). The Act has no separate band for teenagers. Section 9(5) lets the government notify, for a specific fiduciary whose processing of children's data is verifiably safe, an age above which that fiduciary is exempt from all or any of the section 9(1) and 9(3) obligations. No such notification has been issued.

### What is verifiable parental consent under DPDP?

Consent from a parent or lawful guardian, given before you process the child's data, where you have done due diligence that the person is an identifiable adult. Rule 10 lets you check this against reliable identity and age details you already hold, or details or a virtual token issued by an authorised entity, including through DigiLocker.

### Does the DPDP Act apply to schools?

Yes. Schools are Data Fiduciaries for student and parent data. The Fourth Schedule entry for educational institutions lifts the parental consent and tracking bar only for tracking and behavioural monitoring for educational activities or student safety. Admissions, fee collection, marketing and sharing with vendors follow the normal rules.

### Do edtech companies need parental consent for students under 18?

Usually yes, if the edtech company decides why and how the data is processed. Where it only runs a platform on a school's instructions, it is the school's processor and the school carries the consent duty. Do not assume an online platform is an "educational institution" for the exemption; take your counsel's view.

### Can we show ads to users under 18?

Section 9(3) bars targeted advertising directed at children, along with tracking and behavioural monitoring. Contextual ads are not named in the bar, but section 9(2) still prohibits any processing likely to harm a child's well-being. A safe approach is to switch off ad personalisation and third-party ad SDKs for child accounts.

### Do we have to verify the age of every user?

The Act does not prescribe a method of age verification for all users. You need a reasonable way to know whether a user is a child, so you can apply section 9. Confirming that a user is not a child is itself an exempt purpose under the Fourth Schedule, limited to what is necessary.

### What is the penalty for breaching children's data obligations?

Up to ₹200 crore under the Schedule to the Act. The Board weighs factors such as the nature, gravity and duration of the breach, the type of data and the impact on the person (section 33(2)).