Age Assurance Under the DPDP Act: Knowing Who Is a Child
The DPDP Act makes businesses treat children differently but never tells them to check every user's age, so the answer lies in matching the check to the risk and keeping the result, not the evidence.
- CATEGORY
- Article · Age assurance
- POSITION AS OF
- October 2026
- READING TIME
- 9 min read
- TAGS
- Age assurance, Children's data, Data minimisation, Online gaming, DPDP Act
Introduction
Every duty the Digital Personal Data Protection Act, 2023 (the DPDP Act) places around children starts with one fact: whether the user is under 18. A data fiduciary, the business that decides why and how personal data is processed, cannot seek a parent's consent or switch off tracking for a child it does not know is there.
The Act does not say how to find out. Checking every user's age means collecting more about adults, and the same Act limits collection to what a purpose needs. This article sets out the law as of October 2026, the tension, the main methods and a tiered approach by service. Verifying the parent is covered in Trayambic's blog on Rule 10, the scope of section 9 in its article on children's data in schools and ed-tech, and platform-specific issues in its gaming and social media impact studies.
The legal position
The Act. A child is anyone under 18 (s.2(f)). Before processing a child's data, a fiduciary needs verifiable parental consent (s.9(1)), and it may not track, behaviourally monitor or target advertising at children (s.9(3)). The Act never uses the words "age verification" and imposes no duty to check every user's age; the manner of consent is left to the Rules. Consent covers only data "necessary for such specified purpose" (s.6(1)), and data must be erased once the purpose is served (s.8(7)). Breaching the children's duties carries a penalty of up to ₹200 crore. No notification under s.9(5), which can lower the age for verifiably safe processing, has been issued.
The Rules. Rule 10 of the DPDP Rules, 2025 checks that the person consenting is an adult; it says nothing about checking the child, and two of its four illustrations begin with the child simply telling the platform she is one. It is the only rule that mentions age. Rule 12 and Part B of the Fourth Schedule then lift s.9(1) and (3) for listed purposes, including:
"For confirmation by the Data Fiduciary that the Data Principal is not a child and observance of due diligence under rule 10."
The condition is that processing "is restricted to the extent necessary for such confirmation or observance". Another item covers keeping information, services or advertisements likely to harm a child's well-being out of her reach. These provisions commence on 13 May 2027.
The IT Rules. The Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021 require user agreements to bar content "harmful to child" (r.3(1)(b)(iii)). Their Code of Ethics for online curated content requires access controls, including parental locks, for content rated U/A 13+ or higher, and "a reliable age verification mechanism" for A-rated content. There is no general duty on social media intermediaries to verify ages.
Online gaming. The Promotion and Regulation of Online Gaming Rules, 2026 define "user safety features" to include "age verification or age gating mechanisms, time restrictions, parental controls" (r.2(1)(i)). Applicants for determination or registration must state intended age groups and safety features (r.23), and the Online Gaming Authority of India may issue directions on user verification and user safety (r.6(4)). The Rules themselves do not make age verification mandatory for every game.
States. Karnataka's budget for 2026–27 reportedly announced a ban on social media for children under 16; we have found no bill or rule implementing it.
Analysis
A duty without a method
In our view s.9 applies to a child's data whether or not the fiduciary knew the user was a child: the Act contains no knowledge test. Section 33(2), however, makes the Data Protection Board weigh, among other factors, the nature and gravity of a breach and any action taken to mitigate it. A fiduciary that matched its age checks to its risk will be in a far better position than one that asked nothing. The Part B exemption suggests the Rules expect fiduciaries to check, and it spares them the parental-consent and monitoring rules while they do.
Minimisation cuts both ways
Over-collection and under-collection are both failures. A project-management tool that demands government ID from every user to catch a rare 17-year-old intern collects far more than any purpose needs. A teen-heavy game that relies on a date-of-birth box it knows is often false is not taking s.9 seriously.
Three rules resolve most cases, in our view:
- Collect the answer, not the evidence. Most services need to know only "under 18" or "18 or over". Store that and the method used; delete images and documents once the check is done (s.8(7)).
- Escalate on doubt. Start light and step up only when signals conflict, so the heavier checks fall on the few accounts that need them.
- Give adult checks their own ground. Part B lifts only s.9 duties. For an adult, a date-of-birth field fits s.7(a), data voluntarily provided for a specified purpose; a face scan should rest on consent, with another route on offer.
The four methods
| Method | What it collects | Assurance | DPDP points |
|---|---|---|---|
| Self-declaration | Date of birth or age band | Low | Ask neutrally, without signalling the cut-off; keep the band |
| Account-holder inference | Signals already held: KYC status, a linked parent account, content chosen, usage patterns | Medium | Part B covers this only for age confirmation; never reuse the signals for engagement or ads |
| Authorised-entity details or token, such as through DigiLocker | Date of birth, or less if the issuer offers it, from a verified record | High | Take the least data on offer, never a document copy; not everyone has one, so offer another route |
| Facial age estimation | A face image, briefly | Medium to high, weakest near 18 | Biometric processing; delete at once; use a buffer age |
Behavioural inference can look like the "behavioural monitoring" s.9(3) bans; in our view Part B permits it for age confirmation, to the extent necessary, but signals gathered to infer age must not feed recommendation or advertising models. Payment data is a poor proxy: RBI lets minors aged ten and above operate savings accounts independently.
Facial age estimation is biometric processing even though it identifies no one. Trayambic's article on biometric and facial recognition data sets out the safeguards. The 2011 rules on sensitive personal data under the Information Technology Act (the SPDI Rules) define biometrics by reference to authentication, so in our view estimation may fall outside their written-consent rule until they lapse in May 2027; we would treat it as biometric anyway. That means no stored image or template, liveness checks, accuracy testing across skin tones and ages, a processor contract barring the vendor from training on the images, and a buffer age above 18 with a second method for anyone below it.
What other jurisdictions ask
Two foreign laws set benchmarks, though neither applies in India. Under the UK's Online Safety Act 2023, a user-to-user service likely to be accessed by children must prevent them from encountering "primary priority content", the most harmful category, using "age verification or age estimation (or both)" that is "highly effective at correctly determining whether or not a particular user is a child" (s.12(3), (4) and (6)). Ofcom required these checks by 25 July 2025; its January 2025 statement lists facial age estimation, photo-ID matching, open banking and digital identity services among methods capable of being highly effective, and says self-declaration is not.
Australia's Online Safety Amendment (Social Media Minimum Age) Act 2024 requires age-restricted social media platforms to take "reasonable steps" to prevent users under 16 having accounts, from 10 December 2025, on pain of up to 30,000 penalty units (s.63D). Platforms may not insist on government ID or an accredited digital ID without offering a reasonable alternative (s.63DB), and must destroy information collected for the check once used (s.63F). Both ideas, proportion to risk and destruction after use, fit the DPDP Act's own necessity test.
Practical implications
| Tier | Typical services | Suggested assurance | Step up when |
|---|---|---|---|
| 1. Adult-facing, little child appeal | B2B SaaS, payroll, professional tools | Terms limiting use to adults; act on any report of a child | A user is reported or appears to be under 18 |
| 2. General audience | E-commerce, travel, fintech, general streaming | Neutral age question; KYC or account data already held | Child profiles or family plans are offered |
| 3. Likely to attract under-18s | Gaming, social, learning and creator apps | Age question plus inference; token or estimation on doubt | Declared age and signals conflict |
| 4. Adult-only or higher harm | A-rated content, dating, adult services | Token or estimation with a buffer before access | Always; self-declaration alone is not enough |
Worked example (figures illustrative). A quiz-battle app for maths and science has about six lakh users, mostly aged 13 to 19. Players pick a class from 8 to 12, compete on leaderboards, chat and buy power-ups; adult players see ads.
- Tier 3. Sign-up asks for birth month and year, with no ID.
- Under 18. The account stays pending until a parent is verified under Rule 10. No gameplay profile is built before then.
- Over 18, but doubtful. A user claiming to be 19 who picks Class 9 content is asked to confirm her age through DigiLocker or a facial estimate, at her choice. The estimate runs through a vendor that deletes the image on return and sends only a yes or no.
- Child mode. Under-18 accounts get nickname-only leaderboards, chat off by default, no ad SDKs and an adaptive engine limited to choosing the next question.
- Records. The app keeps the age band, method and date; no images or documents.
- Turning 18. The parent's access ends and the player is asked for her own consent before ads switch on.
- Gaming regulation. If the app applies for determination or registration, the age groups and safety features it states should match this design.
Checklist
| Check | Provision | What passing looks like |
|---|---|---|
| Tier assigned and reasoning recorded | s.9; s.33(2) | A short written note per product |
| Age question asked neutrally at sign-up | s.9(1); Fourth Schedule Part B | No hint of the cut-off; band stored |
| Escalation triggers defined | s.9(1); s.6(1) | Listed signals route to a token or estimate |
| Only the outcome kept | ss.6(1), 8(7) | Band, method, date; artefacts deleted |
| Age signals ring-fenced | s.9(3) | No reuse for recommendations or ads |
| Biometric safeguards if estimation used | s.8(5); Rule 6 | No stored images; vendor no-training clause; bias tested |
| Sector rules mapped | IT Rules Code of Ethics; Online Gaming Rules | A-rated content gated; gaming applications consistent |
Key takeaways
Indian law requires a fiduciary to treat children differently but leaves it to choose how to find them. The answer is proportion: light checks for low-risk services, layered checks where teenagers gather, and strong ones at adult-only doors, keeping the result and discarding the evidence.
- Neither the DPDP Act nor the DPDP Rules require a business to verify every user's age; Rule 10 verifies the parent, not the child.
- Part B of the Fourth Schedule lifts s.9(1) and (3) for confirming that a user is not a child, but only to the extent necessary.
- Data minimisation cuts both ways: match the method to the service's risk, escalate on doubt and keep only the outcome.
- Facial age estimation is biometric processing: no stored images, a buffer age and a vendor barred from training on the data.
- The IT Rules demand reliable age verification only for A-rated curated content; the Online Gaming Rules list age verification and parental controls as safety features without mandating them for every game.
Anonymisation and Pseudonymisation Under the DPDP Act
The DPDP Act never mentions anonymisation, so whether a dataset escapes it turns on one word in section 2(t), 'identifiable', and on who could do the identifying.
SDKs, Pixels and Trackers: Who Is Responsible Under the DPDP Act?
Every SDK in an app sends data to someone, and the DPDP Act holds the app answerable for what its code collects while making a vendor that uses the data for itself answerable too.
DPDP Act vs Singapore's PDPA: Taking Your Programme Into Asia
An Indian company with a DPDP programme already has most of what Singapore's PDPA asks for, but breach triage, transfers back to India, a DPO and Do Not Call checks are new work.
