# Verifiable parental consent under DPDP: methods that work without a smartphone

> Under the DPDP Act a child is anyone under eighteen, and before processing her personal data a Data Fiduciary must obtain the verifiable consent of a parent or lawful guardian (s. 2(f), 9(1)). Rule 10 requires due diligence on both the identity and the age of the person consenting, from reliable details you already hold, details she gives you such as a document she shows you, or a token from an authorised entity such as DigiLocker; a bare statement of age is a fallback at best. Tracking, behavioural monitoring and targeted advertising directed at children are barred except in the Fourth Schedule's narrow cases, and edtech companies must verify parents across their existing user base before 13 May 2027.

Source: https://dpdp.commons.inc/dpdp-childrens-data · Updated 25 October 2026 · By the Commons Trust team (commons.inc)

Under the DPDP Act a child is anyone who has not turned eighteen (s. 2(f)), and before you process any of her personal data you must obtain the verifiable consent of her parent or lawful guardian (s. 9(1)). Rule 10 sets what "verifiable" means: reasonable care to confirm that the person consenting as a parent is an identifiable adult, checking both her identity and her age against reliable details you already hold, details she gives you, such as a document she shows you, or a token from an authorised entity such as DigiLocker (Rule 10(1)). A parent without a smartphone can be verified in person from a document or from a record you already hold; a checkbox saying "I am the parent" does not do it. These duties start on 13 May 2027, and breaching them can cost up to ₹200 crore (Schedule, item 3).

Like the Act (s. 2(y)), we say "she" and "her" for every person.

**Jump to what you need:**

- **NGOs and field programmes:** [Methods and the order to use them](#verification-methods-and-the-order-to-use-them), [Hard cases in the field](#hard-cases-assent-absent-parents-guardians-and-camps), [Lawful guardians](#lawful-guardians-and-persons-with-disabilities-rule-11).
- **Schools, colleges and edtech:** [The Fourth Schedule](#the-fourth-schedule-row-by-row), [Schools, colleges and edtech](#schools-colleges-and-edtech), [Edtech before May 2027](#edtech-before-13-may-2027-your-existing-users).
- **Product, legal and DPOs:** [The tracking ban](#tracking-behavioural-monitoring-and-targeted-advertising), [Age assurance](#age-assurance-finding-out-who-is-a-child), [Where the law is unclear](#where-the-law-is-unclear-on-children-s-data).

## Who counts as a child, including 16- and 17-year-olds

The line is eighteen, with no exceptions for teenagers (s. 2(f)); Rule 10(2)(a) defines an adult as someone who has completed eighteen years. There is no self-consent at sixteen or seventeen. The government may notify a lower age only for a specific fiduciary whose processing it is satisfied is "verifiably safe", and only for the obligations the notification names (s. 9(5)). As of 25 October 2026 none has been notified.

That catches colleges with seventeen-year-old first-years, skilling programmes that enrol sixteen-year-olds, youth helplines, coaching services, and consumer apps that teenagers use whether or not they are the target. Plan on parental consent at enrolment and the person's own consent on her eighteenth birthday for anything that continues; a date of birth on the record lets the system flag the day.

A child's Data Principal "includes" her parents or lawful guardian (s. 2(j)(i)), so parents can exercise the child's rights, such as access (s. 11) and correction or erasure (s. 12).

## What section 9 asks

| Sub-section | The duty | In practice |
|---|---|---|
| s. 9(1) | Before processing any personal data of a child, obtain the verifiable consent of her parent, as prescribed. The Explanation says "consent of the parent" includes a lawful guardian. | Verification and consent come first. You cannot enrol the child and verify the parent next month. |
| s. 9(2) | No processing likely to have a detrimental effect on a child's well-being. | Always applies, even where a Fourth Schedule row lifts consent: identifying photographs, shaming leaderboards, profiles shared with recruiters. |
| s. 9(3) | No tracking or behavioural monitoring of children, and no targeted advertising directed at them. | See [the tracking section](#tracking-behavioural-monitoring-and-targeted-advertising). |
| s. 9(4) | Sub-sections (1) and (3) do not apply to prescribed classes and purposes, subject to conditions. | The Fourth Schedule, through Rule 12. |
| s. 9(5) | The government may notify an age above which a verifiably safe fiduciary is exempt from (1) and (3). | None notified. |

The same duty covers a person with a disability who has a lawful guardian (s. 9(1)); the Removal of Difficulties Order of 5 October 2026 tidied the wording of s. 9(1) and adds no duty ([SCC Online](https://www.scconline.com/blog/post/2026/10/15/dpdp-removal-of-difficulties-order-2026/)).

Section 9(1) speaks of "any personal data of a child", without an exception for the legitimate uses in section 7. Our reading is that it applies whichever ground you rely on, unless a Fourth Schedule row covers the processing. That Part B, item 2 had to exempt State benefits under s. 7(b) supports the reading.

## Rule 10: checking a parent's identity and age

You must adopt "appropriate technical and organisational measures" to ensure verifiable parental consent is obtained before processing, and observe due diligence that the person identifying herself as the parent is an adult, identifiable if required for compliance with any law (Rule 10(1)). The check is made by reference to:

- **(a) reliable details of identity and age available with you,** such as an account whose holder's age you checked, or a family record you hold for eligibility that shows her date of birth;
- **(b)(i) details of identity and age she voluntarily provides,** such as a document showing her name and date of birth;
- **(b)(ii) a virtual token mapped to those details, issued by an authorised entity.** That is an entity entrusted by law or by the Central or a State Government to issue identity and age details or tokens, or a person it appoints or permits, and it includes details or tokens verified by a Digital Locker service provider (Rule 10(2)(b)), meaning one the Central Government notifies under the IT Act rules (Rule 10(2)(c)). Check that the service you integrate qualifies.

**Both identity and age.** A school admission form listing "Mother: Sunita Devi" shows who she is but says nothing of her age.

**Before processing.** Consent must come "before the processing of any personal data of a child". Processing a child's data only to confirm her age or run the Rule 10 check is exempt (Fourth Schedule Part B, item 6), which is what lets an app ask a date of birth and then pause.

**The relationship.** Rule 10 checks only that she is an identifiable adult; it does not confirm that she is this child's parent. We recommend recording the basis for the relationship anyway, such as the name on the ration card, school record or birth certificate.

**The Rule's illustrations.** Rule 10 carries four illustrations about opening an online account for a child ([official text, MeitY](https://www.meity.gov.in/static/uploads/2025/11/53450e6e5dc0bfa85ebd78686cadad39.pdf)). Where the parent is already a registered user who gave identity and age details earlier, the fiduciary confirms that it holds reliable details (Cases 1 and 3). Where she is new, it checks her "by reference to identity and age details issued by an entity entrusted by law or the Government", or a token mapped to them, which she may provide through DigiLocker (Cases 2 and 4). Illustrations guide interpretation; they are not binding text. Read with the due-diligence wording, they point to government-issued details for a parent new to you, and a bare statement of age as a fallback at best.

## Verification methods and the order to use them

| Method | Rule 10 limb | Identity | Age | Smartphone? | What you keep | Our assessment |
|---|---|---|---|---|---|---|
| Parent already holds an account with you, age checked when opened | (a) | Yes | Yes, if the earlier check was real | Depends | Account reference | Strong. Weak if the earlier check was a self-declared birth year. |
| Record you hold for another reason showing her age or date of birth, such as a ration card copy listing ages, or an employee record | (a) | Yes | Yes | No | Reference to the record | Strong; adds no new data. Confirm it is hers and current. |
| DigiLocker or other authorised-entity token | (b)(ii) | Yes | Yes | Usually | Token reference and result | Strongest and most private. Rare where parents use basic phones. |
| Government document with date of birth, viewed in person, not copied | (b)(i) | Yes | Yes | No | Document type, "seen", facilitator, date | Strong where facilitators are trained. |
| Voter ID card viewed in person | (b)(i) | Yes | Implied: only adults are enrolled as voters (Constitution, art. 326) | No | "Voter ID seen", facilitator | Good; shows adulthood without a birth date. |
| Scan or photo of an ID uploaded online | (b)(i) | Yes | Yes | Yes | The image, unless deleted after checking | Acceptable if checked and deleted promptly. Weak against forgeries. Never for Aadhaar. |
| Parent states her name and age, in writing or aloud | (b)(i), on a wide reading | Weak | Weak | No | Stated details, who recorded them | Fallback only, within the ceiling below. In our view it does not on its own meet Rule 10. |
| One-time password to the parent's mobile | None alone | No | No | No | Number, time | Shows control of a number. Use with another method. |
| Small payment from a bank or UPI account | None alone | Partly | No | Often | Transaction reference | Shows access to an account and says nothing about age. |
| Confirmation by a teacher, anganwadi worker, ASHA or sarpanch | None alone | Supporting | Supporting | No | Name and role | Supports a weak method; replaces none. |

The Aadhaar Act and UIDAI's regulations govern Aadhaar authentication and the storing of numbers. Do not photograph or store Aadhaar cards to meet Rule 10.

Rule 10 asks nothing digital of the parent. Where parents have basic phones or none, work down this order and stop at the first method that works:

1. **A record you already hold** that shows her age (Rule 10(1)(a)).
2. **A token,** if she has DigiLocker on a phone, or a family member's phone she trusts (Rule 10(1)(b)(ii)).
3. **A document viewed in person:** voter ID, or another government document with her date of birth (Rule 10(1)(b)(i)).
4. **Fallback:** her stated identity and age, a known community worker's confirmation, and a document check booked within 30 days.

Our recommended ceiling: no more than 10% of verifications in any programme on the fallback, and none for higher-risk processing such as photographs for publication or health data. Above the ceiling, stop enrolling through that channel and fix the method.

Then take her consent in a form she can give, after the whole notice, including how to withdraw, exercise her rights and complain to the Board, in English or an Eighth Schedule language such as Hindi, with dialect audio where she needs it (s. 5(1), 5(3), 6(3), Rule 3). [Consent in the field](/dpdp-field-consent) has scripts and a paper register; [our notice guide](/dpdp-consent-notice) has a parent notice.

### Checking the quality of verification

*Our recommendation, not a legal requirement.* Each month, sample 5% of new verifications, and at least 20, by reviewing the record and calling the parent. Track two numbers per programme and per facilitator: the share of sampled records where the method recorded matches what the parent describes, and the share of all verifications on the fallback. Report both to whoever owns the programme.

## Two illustrative flows

These are illustrative composites, not client stories, set after 13 May 2027.

**A learning app sold to families.**

1. Sign-up asks for date of birth with no hint of the "right" answer (Fourth Schedule Part B, item 6).
2. If she is under eighteen, the app stops and asks only for a parent's mobile number or email.
3. The parent gets a link to the full notice: the child's and parent's data, itemised; each purpose; how to withdraw, exercise rights and complain to the Board (Rule 3).
4. The parent verifies through DigiLocker, or by signing in to an account whose age was checked (Rule 10(1)(a), (b)(ii)).
5. She answers each purpose separately, with nothing pre-ticked. Only then is the child's account created.
6. If verification is not completed within seven days, the app deletes the date of birth and contact details it collected.

**An after-school centre where most parents have basic phones.**

1. A facilitator visits and plays the notice in the local dialect, with the Hindi text on screen, before asking anything.
2. She matches the mother to the ration card copy the NGO holds for eligibility, which lists ages, or views her voter ID.
3. The mother answers each purpose: learning records yes, SMS when the child misses class yes, photos in donor reports no. The app records the spoken answers, time and facilitator.
4. The child is enrolled only after step 3 is saved. The record looks like this:

| Field | Example |
|---|---|
| Child | Learner ID 5521 |
| Consenting adult and relationship | Mother; relationship shown on ration card |
| Rule 10 limb and method | (a): matched to ages on ration card copy, ref 2231 |
| Kept | Reference only; no copy |
| Notice | Parent notice v1.2; Hindi text offered, Bundeli audio played |
| Decisions | Learning records yes; SMS yes; photos no |
| Who and when | Facilitator F-07, 12 June 2027, 16:10, home visit |
| Child enrolled | 12 June 2027, 16:14 |

The last row shows the check came first; s. 6(10) puts the burden of proving notice and consent on you.

## Hard cases: assent, absent parents, guardians and camps

**The child's own view.** The Act does not require a child's assent. We recommend asking anyway, and respecting a no for photographs, videos and stories: a 14-year-old who does not want her photograph taken should not have it taken because her father agreed. The well-being duty (s. 9(2)) supports this.

**A parent who has migrated for work.** On its face, "the parent" in s. 9(1) can be either parent (our reading), so the parent at home can consent. Where neither is present and a grandparent is raising the child, the grandparent is not a parent and is a lawful guardian only if the law makes her one. Reach the absent parent: play the notice on a call, take her consent by keypress, and verify her against a record you hold that shows her age, such as the family's ration card copy (Rule 10(1)(a)), and confirm on the call that she is that person, for example through the number registered with you and a detail only she would know.

**Single parents and relatives caring for a child.** One parent's verified consent meets s. 9(1). An aunt or older sibling caring for a child is not a lawful guardian unless a court order or other law makes her one; ask counsel where that matters, and contact a parent if one is reachable.

**Children who arrive alone at a camp or session.** Without a verified parent you cannot process the child's personal data digitally, except as a Fourth Schedule row or emergency allows: a clinical establishment giving health services (row A1). In a genuine medical emergency (s. 7(f)) our view is to act first and record why; see the unclear-law section. Otherwise keep a headcount, or take the parent's contact on paper and verify before anything is entered into a system. A paper register is outside the Act only until someone digitises it (s. 3(a)).

## Lawful guardians and persons with disabilities: Rule 11

For a person with a disability who has a lawful guardian, the guardian gives the verifiable consent (s. 9(1)). You must verify that the guardian was appointed by a court, by a designated authority under section 15 of the Rights of Persons with Disabilities Act, 2016, or by a local level committee under section 13 of the National Trust Act, 1999, under the law applicable to guardianship (Rule 11(1), (2)(a), (c)).

The rule applies to a person who has a long-term impairment that hinders full participation, or autism, cerebral palsy, mental retardation (the statute's term) or a combination including severe multiple disability, and who, in either case, despite adequate and appropriate support, is unable to take legally binding decisions (Rule 11(2)(d)). An adult with a disability who can decide with support consents herself. A family member without an appointment order does not meet Rule 11. View the order or certificate, record its reference and date, and keep no copy unless you need one.

## The Fourth Schedule, row by row

Rule 12 lifts section 9(1) and 9(3) for the classes in Part A and the purposes in Part B, each "restricted to" a stated extent ([official text](https://www.meity.gov.in/static/uploads/2025/11/53450e6e5dc0bfa85ebd78686cadad39.pdf)). The well-being duty in s. 9(2) is never lifted, and neither is anything outside section 9: security, breach notice, retention and the need for a ground under section 4 all still apply.

### Part A: classes of fiduciary

| Row | Who | Processing is restricted to | Not covered |
|---|---|---|---|
| A1 | A clinical establishment, mental health establishment or healthcare professional, as defined in the Clinical Establishments Act, 2010, the Mental Healthcare Act, 2017 and the National Commission for Allied and Healthcare Professions Act, 2021 | Health services to the child, to the extent necessary to protect her health | Fundraising stories, research beyond care, marketing, health apps that are not establishments or professionals |
| A2 | An allied healthcare professional, as defined in the 2021 Act | Supporting a treatment and referral plan the professional recommended, to the extent necessary to protect her health | Anything outside that plan |
| A3 | An educational institution, which "shall mean and include an institution of learning that imparts education, including vocational education" | Tracking and behavioural monitoring for its educational activities, or in the interests of the safety of children enrolled with it | Admissions, fees, sharing with third parties for their purposes, publicity photos, marketing |
| A4 | An individual in whose care infants and children in a crèche or child day-care centre are entrusted | Tracking and behavioural monitoring in the interests of the safety of the children entrusted | Learning analytics, marketing, publicity photos |
| A5 | A fiduciary engaged by an educational institution, crèche or child-care centre to transport children enrolled with it | Tracking their location, for their safety, during travel to and from it | Transport arranged by parents; location outside the trip; other uses |

### Part B: purposes

| Row | Purpose | Processing is restricted to | Notes |
|---|---|---|---|
| B1 | A power, function or duty in the interests of a child, under any law in force in India | The extent necessary for it | Our view: it needs a law conferring the power or duty; a policy or a funder's requirement is not enough. |
| B2 | A subsidy, benefit, service, certificate, licence or permit, under law or policy or using public funds, in a child's interest, under s. 7(b) | The extent necessary for it | Tied to s. 7(b), which only the State uses. A private partner acting on the State's instructions processes for the State. |
| B3 | Creating a user account for communicating by email | The extent necessary to create it, its use limited to email | An email-only school account fits; a suite with classrooms and chat goes beyond it. |
| B4 | Determining a child's real-time location | Tracking her real-time location for her safety and protection or security | Our view: location histories, or other uses of location, go beyond "real-time". |
| B5 | Keeping information, services or advertisements likely to harm her well-being away from her | The extent necessary to do so | Supports content filters and ad blocking. "Advertisement" has its Consumer Protection Act, 2019 meaning. |
| B6 | Confirming that a Data Principal is not a child, and the Rule 10 due diligence | The extent necessary for it | Lets you ask a date of birth and run the parent check. Delete what you collected if the check is never completed. |

Before relying on any row, record which row, its exact limit, and why your processing fits it.

## Schools, colleges and edtech

**Schools.** Our view: a school's tracking and behavioural monitoring for its educational activities or the safety of enrolled children, such as proctoring, CCTV and safety tracking, and probably learning analytics, falls within row A3. Plain attendance and marks records are not obviously tracking or monitoring; take parental consent or rely on another row for them. Admissions data, photos in the prospectus or on social media, sharing with an NGO's programme, and anything a vendor does for itself all need verified parental consent unless another row applies. A government school will often rely on row B1 for duties it carries out under law.

**Colleges.** Every student under eighteen is a child. Admissions, hostel, placement and alumni processing for a seventeen-year-old needs a parent's verified consent. Add an age check and consent step to the admission form, and switch to the student's own consent on her eighteenth birthday.

**Edtech vendors working for schools.** Processing for the school, on its instructions and for its purposes, makes you its processor under a contract (s. 8(2)). Our view is that the school's row A3 exemption extends to processing you do on its behalf within those purposes, because that processing is the school's (s. 8(1)). Using the data for your own product, profiles, models or marketing makes you a fiduciary for that use, with no exemption. The contract should rule those uses out, alongside the processor terms in [DPDP for SaaS startups](/dpdp-for-startups).

**Edtech selling directly to families.** You are the fiduciary and need verified parental consent before creating a child's account. Whether a learning app is an "institution of learning" under row A3 is untested; even if it were, the row lifts only tracking and monitoring, never consent for account creation.

## Edtech before 13 May 2027: your existing users

An edtech company with an existing base of child users has to bring it into line before the duties start, because storing data is itself processing (s. 2(x)). Our recommended sequence:

- **Find the children.** Use date of birth where you hold it, and signals such as school class or grade where you do not. Treat unknown ages in a children's product as children.
- **Notify and verify parents.** Send each parent a full notice and a verification link, by the email or mobile on file, with reminders. Our view is that s. 5(2), which lets consent given before commencement continue, does not dispense with the verifiable parental consent that s. 9(1) requires, so a child's own sign-up does not carry over.
- **Freeze, then delete.** Set an internal cut-off well before 13 May 2027. From it, unverified child accounts are frozen: no new features, no analytics, no messages. Offer the parent an export, then delete unverified accounts' data by 12 May 2027, except what a law requires you to keep.
- **Inventory every SDK** in child-facing builds: advertising, attribution, analytics, crash reporting, push. Remove advertising and attribution SDKs, and configure the rest to send no identifiers, or ship a separate child build.
- **Parent accounts with several children.** One verified parent can hold several child profiles. Record consent per child and per purpose, and let her withdraw for one child without closing the others.
- **Shared devices.** A child using a parent's logged-in phone is still a child. Offer a child profile that switches advertising and tracking off, and treat in-app signals of a child user as a trigger to prompt for one.
- **What withdrawal does.** When a parent withdraws, stop processing the child's data within a reasonable time (s. 6(6)) and erase it unless a law requires retention (s. 8(7)). The child's account closes or reverts to the parent; the consequences fall on the person withdrawing (s. 6(5)), so say plainly in the notice that progress history will be deleted, and offer an export first.
- **Upselling to the parent from the child's performance.** Our position: send offers to the parent based on her child's performance data only with the parent's separate, specific consent; use only data the service already needs; build no profile beyond it; and never show the offer to the child. Generic offers are safer. *Confidence:* low, because the line between this and monitoring the child for commercial ends is untested (s. 9(2), 9(3)).

[The data you already hold](/dpdp-existing-data) covers the notice campaign in more detail.

## Tracking, behavioural monitoring and targeted advertising

Section 9(3) is a prohibition, and a parent's consent does not lift it; only a Fourth Schedule row can (s. 9(4)). The Act does not define tracking, behavioural monitoring or targeted advertising, so these lines are our working positions.

| Practice | Our position |
|---|---|
| An advertisement chosen using data about the child: profile, behaviour, interests or location | Targeted advertising. Barred. |
| Advertisements chosen only by the page's content, without personal data | Probably outside s. 9(3); the well-being duty still applies (s. 9(2)). |
| Third-party advertising or analytics tags on pages children use | Treat as tracking unless the tag collects no identifiers and builds no profile. |
| Aggregate product analytics with no per-child profile | Lower risk. Strip identifiers at collection. |
| Engagement nudges driven by a child's usage history, such as streaks and re-engagement pushes | Behavioural monitoring. Barred outside the Fourth Schedule. |
| Adaptive exercises that set the next question from her last answers, within a session she chose | Closer to delivering the service. Grey area; see below. |
| School-run proctoring and safety monitoring | Within row A3. |
| Location sharing with parents for safety | Within row B4, real-time only. |

## Age assurance: finding out who is a child

The Act does not say how to find out whether a user is a child and sets no "knowledge" standard; it does exempt processing to confirm that someone is not a child (Fourth Schedule Part B, item 6). Our recommendation is to match effort to risk:

- **Services built for children:** assume users are children and verify the parent every time.
- **General services children are likely to use,** such as messaging, gaming and youth helplines: a neutral date-of-birth question at sign-up, and action on signals such as a stated school class or a parent's complaint.
- **Adult-only services:** a declaration where risk is low; stronger checks where harm to a child would be serious.

Do not collect identity documents from every user to find the few children (s. 6(1)), and delete age-check data once the check is done.

## Where the law is unclear on children's data

**Can a parent's own statement of her identity and age satisfy Rule 10(1)(b)(i)?** Only as a fallback, within a ceiling. *Why:* the text accepts details "voluntarily provided by the individual", but the Rule's illustrations describe checks against government-issued details for parents new to the fiduciary, and due diligence implies checking. *Would change if:* the Board accepts self-declaration in low-risk settings, or rejects it outright. *Confidence:* low.

**Must you verify that the adult is this child's parent?** Not under Rule 10's text; record the basis anyway. *Why:* Rule 10 checks that she is an identifiable adult and is silent on the relationship. *Would change if:* guidance requires relationship checks. *Confidence:* high on the text, medium on the practice.

**Does s. 9(1) apply when you rely on a legitimate use?** Yes, except where a Fourth Schedule row applies. *Why:* s. 9(1) covers "any personal data of a child", and the express exemption for s. 7(b) would be unnecessary otherwise. In a genuine medical emergency (s. 7(f)) we would act first and record why. *Would change if:* the Board reads s. 7 as standing apart from s. 9. *Confidence:* medium; low for emergencies.

**Where a Fourth Schedule row lifts parental consent, what ground covers the processing?** You still need one under s. 4. *Why:* Rule 12 lifts s. 9(1) and 9(3), not s. 4. For a clinic treating a child, we would rely on the purpose for which she or her parent sought care (s. 7(a)), or on emergency grounds. *Would change if:* the Board treats the exemption as authorising the processing. *Confidence:* medium.

**Does a school's row A3 exemption extend to its edtech processor?** Yes, within the school's own purposes. *Why:* processing on the school's behalf is the school's processing (s. 8(1), s. 2(k)). *Would change if:* the Board limits the row to processing the institution does itself. *Confidence:* medium.

**Is a learning app an "educational institution"?** We would not rely on it. *Why:* "institution of learning that imparts education" reads naturally as a school, college or training centre, though the inclusive "mean and include" wording leaves room for a wider reading. *Would change if:* the Board applies row A3 to online providers. *Confidence:* low.

**Is adaptive learning behavioural monitoring?** Within a session the child chose, setting the next exercise from her answers is closer to providing the service. Profiles built across sessions to change her behaviour are monitoring. *Why:* "behavioural monitoring" suggests observing behaviour over time to influence or assess it. *Would change if:* the Board defines the term. *Confidence:* low.

## What to fix first

Work in order of risk:

1. **Advertising and tracking on anything children use.** Remove ad and attribution SDKs and third-party tags now; these have no consent route at all (s. 9(3)).
2. **Your existing child users.** Start the parent notice and verification campaign, and fix the freeze-and-delete date.
3. **New enrolments.** Put the date-of-birth screen, the parent notice and a verification method from the order above in front of every new child record.
4. **Fourth Schedule reliance.** For each system, write down the row you rely on and its exact limit; everything outside it goes behind parental consent.
5. **Field teams.** Train facilitators on the method order, the fallback ceiling and the hard cases, and start the monthly quality sample.
6. **Contracts.** Sign processor terms with every vendor touching children's data, ruling out their own uses.
7. **Reporting.** From 13 May 2027, report each quarter the share of child records with a recorded method, the share on the fallback, and the quality-sample results.

For breaches involving children, see [our breach guide](/dpdp-breach-response); for the overall calendar, [DPDP deadlines](/dpdp-timeline).

**How we wrote this guide.** We worked from the text of the Digital Personal Data Protection Act, 2023 (No. 22 of 2023) and the Digital Personal Data Protection Rules, 2025 (G.S.R. 846(E), as corrected by G.S.R. 892(E)), checking Rule 10, its illustrations and the Fourth Schedule, including its definitions, against the official text published by MeitY. Events after November 2025 were last checked on 25 October 2026. Statements marked as our view, position or recommendation are judgement, not law. This guide explains the law; it is not legal advice for your situation.
{: .note }

## Questions people ask

### Can one parent's verification and consent cover all her children?

One verification can: Rule 10 checks that the person consenting is an identifiable adult, and once you hold reliable details of her identity and age you may rely on them again (Rule 10(1)(a)). Consent is different. It must be specific to the processing (s. 6(1)), so record it per child and per purpose, even if she gives it for three children in one sitting. Record the relationship to each child separately, because a mother of two is not necessarily the guardian of the cousin who lives with them.

### If a school licenses our app, do we still need the parent's consent?

If you act only as the school's processor, on its instructions and for its purposes, the school is the fiduciary and the duty to obtain verified parental consent is the school's, except for processing within its Fourth Schedule row (s. 8(1), Rule 12). Your contract should say who collects the consent and how you see the record. If you use any of the data for purposes of your own, such as product analytics, marketing to families or model training, you are a fiduciary for that use and need the parent's verified consent yourself.

### What happens to a child's data if the parent never completes verification, or later withdraws?

Stop processing it. Without verified consent there is nothing to process on, apart from the narrow processing needed to confirm age and run the Rule 10 check (Fourth Schedule Part B, item 6). Erase what you collected unless a law requires you to keep it (s. 8(7)). After a withdrawal you and your processors must stop within a reasonable time (s. 6(6)). Rule 8(3) requires a year of data and logs for the Seventh Schedule purposes, so keep only those, separately and with restricted access.

### What if a child lies about her age to get past our age screen?

The Act's user duties do not squarely cover a child misstating her age. Section 15(b) bars impersonating another person, which would fit a child posing as her own parent at the consent step (penalty up to ₹10,000, Schedule item 5), but not one who only gives a false birth date. Your exposure turns on whether your due diligence was reasonable. Use a neutral age question, watch for signals such as a stated school class, and when you learn a user is a child, stop, contact the parent and verify before continuing.

### Do children's photos taken at a public event need parental consent?

If the photos are digital and a child can be identified from them, processing them is processing her personal data, and section 9(1) requires a parent's verifiable consent first, unless a Fourth Schedule row applies. The public setting does not change this: the exclusion for public data covers only data the person herself made public, or that a law required someone to publish (s. 3(c)(ii)), and a photograph someone else took of her is neither. Our view: photograph crowds from behind or at a distance, and take named consent for any close-up you intend to publish.

## About Commons Trust

Commons Trust is a DPDP compliance programme and consent management platform from commons.inc that takes nonprofits, foundations, startups and corporates from wherever they are to fully compliant with India's Digital Personal Data Protection Act. Contact: hello@commons.inc · https://dpdp.commons.inc/#start