DPDP Children's Data Rules: How Indian Apps, EdTech and Online Businesses Must Build Age Verification and Parental Consent Before May 2027

Most compliance conversations about children's data in India begin with the wrong mental model. Teams assume the rules matter only if they run a "kids' app", and benchmark themselves against the American COPPA threshold of thirteen or the GDPR's thirteen-to-sixteen band. India's Digital Personal Data Protection Act, 2023 starts from a different place entirely. Under Section 2(f) of the Act, a "child" is an individual who has not completed the age of eighteen years. Every Indian user of your product who is sixteen or seventeen years old is a child in the eyes of this statute, whether or not anyone inside your company thinks of the product as a children's service.

The operational machinery that gives this definition its bite is found in Section 9 of the Act and in Rules 10 to 12 of the DPDP Rules, 2025, published in the Gazette on 13 November 2025. Under the commencement schedule in Rule 1, the substantive group of rules, Rules 3, 5 to 16, 22 and 23, comes into force eighteen months after publication, which places the children's-data obligations at 13 May 2027. From the date of this article, that is 231 days away. For the overall regime, the pillar guide is Data Privacy Compliance in India: The DPDP Act Framework. This article deals with the branch of the framework that product teams are currently least prepared for: age assurance, verifiable parental consent, the tracking and advertising prohibitions, and the carefully bounded exemptions in the Fourth Schedule.

India's Child Threshold Is 18, Not the Under-13 Internet Model

The Commercial Misconception

The internet's default compliance architecture was built around COPPA's under-13 rule, and later around GDPR Article 8, which sets the consent age at sixteen by default and lets member states lower it to thirteen. Products designed for those regimes typically carry a single design assumption: below the threshold, get parental consent; above it, treat the user as an adult. That assumption fails in India, because the DPDP threshold sits at eighteen and applies to all processing of a child's personal data, not merely to services "directed at children" in the COPPA sense.

The consequence is wider than EdTech. Gaming platforms, social and community features, e-commerce accounts, streaming services, health and fitness apps, newsletters, and any SaaS product that a seventeen-year-old can realistically sign up for are all within scope. A B2B tool does not become a children's product because a minor uses it, but it acquires children's-data obligations the moment its user base plausibly includes under-18s and it has no mechanism to know otherwise.

How India Compares

The comparison matters for one practical reason: a multinational platform cannot map its existing global consent workflow onto India and assume coverage. A product that treats a fifteen-year-old as a consenting user in Europe is processing a child's data without verifiable parental consent in India. The proposed EU KIDS Act, announced by the European Commission on 17 September 2026, shows the broader direction of travel: age-based access tiers and mandatory privacy-preserving age checks. India arrived at the same regulatory neighbourhood earlier and with a higher threshold, and the regimes should be read separately rather than conflated.

What Section 9 Actually Prohibits

Commentary on Section 9 frequently collapses it into a slogan: "children's data is banned." It is not. Verified against the Gazette text of the Act, Section 9 does three distinct things, and the distinctions control the compliance design:

1. Section 9(1): the consent gate. Before processing any personal data of a child, or of a person with disability who has a lawful guardian, the Data Fiduciary must obtain verifiable consent of the parent or lawful guardian, in the manner prescribed. This is a gate, not a prohibition: children's data can be processed, but only through the parental-consent architecture that Rule 10 supplies.
2. Section 9(2): the well-being standard. A Data Fiduciary must not undertake processing "likely to cause any detrimental effect on the well-being of a child." This is a substantive standard that applies regardless of consent, and it is deliberately broad. A consent form does not cure a product feature whose data practices harm children.
3. Section 9(3): the tracking and advertising prohibition. A Data Fiduciary must not undertake tracking or behavioural monitoring of children, or targeted advertising directed at children. Unlike the consent gate, this limb is not solved by parental consent; it is a flat prohibition, subject only to the prescribed exemptions.

Two further features of the section deserve attention. Section 9(4) is the hook under which the Fourth Schedule exemptions in Rule 12 operate, disapplying sub-sections (1) and (3) for specified classes of Data Fiduciaries and purposes. And Section 9(5) gives the Central Government a rarely discussed power: where a Data Fiduciary's processing of children's data is verifiably safe, the Government may notify an age above which that fiduciary is exempt from some or all of these obligations. No such notification exists at the date of this article, but it is the statutory route by which a platform with demonstrably safe architecture could one day seek calibrated relief.

The penalty exposure is specific: the Schedule to the Act prescribes a penalty of up to Rs. 200 crore for breach of the obligations in relation to children under Section 9, in addition to the general tiers of up to Rs. 250 crore for security-safeguard failures and Rs. 200 crore for breach-intimation failures.

Age Declaration, Age Assurance and Parental Verification Are Three Different Problems

This is the conceptual centre of the compliance problem, and the place where most implementations will fail. Businesses tend to treat "age gate" as a single feature. The statute and the Rules actually present three separate questions, each with its own design answer.

Run the distinction across ordinary product scenarios:

• An EdTech account. A fourteen-year-old registers for a test-preparation app. The date-of-birth field is the declaration. The platform's decision about whether to believe and act on it is the assurance question. Once the user is treated as a child, Rule 10 governs how the parent is verified before any processing begins.
• A gaming registration. A user declares an age of sixteen. The studio's analytics SDK, ad network and session-replay tooling all begin processing immediately. If the declaration is never acted upon, the platform is tracking and behaviourally monitoring a child within the meaning of Section 9(3) from the first session.
• An e-commerce account. A seventeen-year-old creates an account on a general marketplace. The platform is not "directed at children", but the DPDP Act does not use that concept. The account creation itself is processing of a child's personal data.
• A newsletter or community feature. Even low-risk collection, an email address for updates, is processing. The Fourth Schedule's narrow email-account exemption is examined below; it is much narrower than most teams assume.
• A seventeen-year-old on an adult-facing SaaS product. The hardest case, and the one that exposes the assurance gap: a product with no age signal at all cannot demonstrate that it knows whether Section 9 applies to any given user.

The design paradox is real: determining whether someone is a child requires processing data about them, which the Act restricts. The notified Rules address this directly, and it is one of the most overlooked provisions in the entire framework. Item 6 of Part B of the Fourth Schedule disapplies the Section 9(1) consent gate and the Section 9(3) prohibition for processing undertaken to confirm that a Data Principal is not a child, and to observe due diligence under Rule 10, restricted to the extent necessary for that confirmation. In other words, the Rules expressly create the legal room to build an age-check step, so long as the data collected for it is confined to that purpose.

Rule 10: How Verifiable Parental Consent Actually Works

The Statutory Standard

Rule 10(1) requires the Data Fiduciary to adopt appropriate technical and organisational measures to ensure that verifiable consent of the parent is obtained before processing any personal data of a child, and to observe due diligence in checking that the individual identifying herself as the parent is an adult who is identifiable if required in connection with compliance with any law in force in India. The due diligence proceeds by reference to one of two evidentiary routes:

An "authorised entity" is one entrusted by law or by the Central or State Government with issuing identity and age details or tokens, or a person appointed by such an entity. The Gazette illustration walks through four cases covering the two scenarios that matter in practice: the child initiates the account and declares the parent, or the parent opens the account for the child; and in each scenario, the parent is either an existing verified user or a new one. The compliance logic is identical across all four: before the child's data is processed, confirm that the platform holds or can verify reliable identity and age details establishing that the consenting individual is an identifiable adult.

Two Corrections to the Common Reading

Much of the existing commentary gets two points wrong, and both corrections matter commercially.

First, Rule 10 verifies the adult, not the relationship. The due diligence obligation is to check that the individual identifying herself as the parent is an identifiable adult. The Rule does not require the platform to independently prove the parent-child relationship through documentation. The parental status is asserted by the individual; the adulthood and identifiability are what the platform must verify. Designs that demand birth certificates or family documents to prove the relationship go beyond what the Rule prescribes, and create exactly the over-collection problem the next point addresses.

Second, the Rule does not prescribe Aadhaar collection from every parent. The token route exists precisely so that a parent can establish identity and age through an authorised entity, including a Digital Locker Service Provider, without handing raw identity documents to every app her child touches. A well-designed implementation minimises what the platform itself receives: the token confirms the attribute; the platform need not warehouse the underlying document. Collecting and storing full identity documents from millions of parents would convert a children's-safety measure into one of the largest identity-data concentration risks in the country, and the Rules point away from that outcome.

The Consent Itself Still Has to Be Valid

Verification of the parent solves only the "who" question. The consent obtained must still satisfy Section 6: free, specific, informed, unconditional and unambiguous, given by clear affirmative action, and as easy to withdraw as to give. Because the Data Principal of a child's data includes the parent acting on the child's behalf under Section 2(j), the rights architecture of the Act, access, correction, erasure, grievance, runs to the parent as well. A parental-consent record therefore needs to capture what was shown, what was agreed, when, by whom, and how it can be withdrawn, and it must be linked to the specific child account it covers.

The Overlooked Rule 12 Exemptions

Rule 12 is where the notified framework becomes genuinely nuanced, and it is the section most generic compliance content misses entirely. It disapplies Section 9(1) and Section 9(3), the consent gate and the tracking and advertising prohibition, for the classes of Data Fiduciaries in Part A of the Fourth Schedule and the purposes in Part B, in each case subject to strict conditions.

Part A: Classes of Data Fiduciaries

Part B: Purposes

Two legal points define how these exemptions should be read. First, they are purpose- and condition-specific derogations, not blanket exemptions. An educational institution may track and behaviourally monitor students for educational activities and safety; it acquires no licence to monetise student behavioural data, and Section 9(2)'s well-being standard is not disapplied by Rule 12 at all. Second, the exemptions answer practical design questions that product teams are already asking: the email-account item tells you how far a minimal sign-up can go, the age-confirmation item is the legal foundation of the age-assurance step discussed above, and the content-filtering item is what permits a platform to process data in order to keep harmful material away from children.

What Happens to Analytics, Ad-Tech and Product Personalisation

Section 9(3) is a product-architecture problem before it is a legal one, because the technologies it names are embedded in the standard growth stack. Map the typical pipeline against the prohibition:

The honest reading is that for users identified as children, the growth stack largely switches off: no behavioural advertising, no engagement profiling, no tracking beyond what the Fourth Schedule conditions allow. What remains lawful is contextual, non-behavioural operation of the service, and the Section 9(2) well-being standard still hovers over every feature decision.

There is also a vendor dimension. Analytics providers, advertising SDKs, cloud services and engagement platforms are Data Processors, and under Section 8(1) the Data Fiduciary remains responsible for processing undertaken on its behalf irrespective of any agreement to the contrary. A platform cannot cure a Section 9(3) problem by pointing at its ad network. The processor-liability architecture is analysed in detail in The Hidden Liability in Your Tech Stack: Why Your SaaS Vendors Expose You Under the DPDP Act; children's data is simply its sharpest application, because the underlying processing may be prohibited rather than merely regulated. The collection-surface side, registration forms, cookies and trackers, is covered in What Indian Websites Get Wrong About DPDP.

The May 2027 Product-Remediation Checklist

The obligations commence on 13 May 2027. Product remediation of this kind, touching sign-up flows, consent architecture, analytics configuration and vendor contracts, is a multi-quarter effort, and the sensible sequence is as follows:

The Bottom Line

India's children's-data regime is stricter than the internet's default settings in three ways that matter: the threshold is eighteen, not thirteen; the consent must be verifiable under a prescribed due-diligence standard, not merely clicked; and the tracking and targeted-advertising prohibition is not cured by consent at all. The Rules are more forgiving than the headlines suggest in exactly two places: the Fourth Schedule's purpose-bounded exemptions, and the express legal room to confirm that a user is not a child. Between now and 13 May 2027, the businesses that will be ready are the ones that treat age declaration, age assurance and parental verification as three separate engineering problems, build the Rule 10 workflow around identity-data minimisation rather than document collection, and switch the growth stack off for the users the statute protects. The penalty for a Section 9 failure runs to Rs. 200 crore per contravention; the cost of the architecture is a design exercise that can begin this quarter.

This article is published for general informational purposes and reflects the DPDP Act, 2023 and the DPDP Rules, 2025 as notified. It does not constitute legal advice on any specific set of facts.