Children's data under the DPDP Act: consent, bans and exemptions

Ask a product team what the DPDP Act says about children and you will often hear that processing the personal data of anyone under 18 is banned. That is not what the law says. The Act conditions such processing on verifiable parental consent, prohibits a short list of practices outright, and then lifts the consent and tracking duties for named classes and purposes under strict conditions. Here is the actual structure, provision by provision.

Eighteen is the line

Section 2(f) defines a child as "an individual who has not completed the age of eighteen years". There is no lower tier and no graduated age band in the definition. The definition is already in force: notification G.S.R. 843(E) brought section 2 into effect on publication, printed as 13 November 2025. The operative duties are not. Section 9 of the Act and Rules 10 and 12 sit in the 18 month commencement groups and commence on the computed date of 13 May 2027, interpretation until officially confirmed.

The 3 duties in section 9

Section 9(1) requires the Data Fiduciary, before processing any personal data of a child, to "obtain verifiable consent of the parent of such child or the lawful guardian, as the case may be", in the manner prescribed by the Rules. The Explanation folds guardian consent into the phrase "consent of the parent" wherever applicable. The same subsection also covers a person with disability who has a lawful guardian; Rule 11 sets that parallel verification track and this article stays with children.

Section 9(2) prohibits processing "likely to cause any detrimental effect on the well-being of a child". This duty is absolute within the children's data scheme: no consent, parental or otherwise, licenses it, and as we will see, none of the child specific exemption routes reaches it either.

Section 9(3) prohibits "tracking or behavioural monitoring of children or targeted advertising directed at children". Read that carefully: it is a prohibition, not a consent gate. A parent's verifiable consent under section 9(1) does not switch behavioural advertising back on for a child's account. Only the exemption routes below touch this duty.

Section 9(4) and 9(5) are the relief valves. Under subsection (4), prescribed classes and purposes escape subsections (1) and (3) subject to conditions, which Rule 12 and the Fourth Schedule now deliver. Under subsection (5), the Central Government may, for a fiduciary whose children's processing it is satisfied is "verifiably safe", notify an age above which some or all of those duties fall away. Both operate by notification, not by self declaration.

Rule 10: what verifiable consent actually requires

Rule 10 turns section 9(1) into machinery. The Data Fiduciary must adopt "appropriate technical and organisational measures" to ensure verifiable parental consent is obtained before processing, and must observe due diligence to check 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". The check runs by reference to exactly two classes of evidence the rule names:

1. "reliable details of identity and age of the individual available with the Data Fiduciary", meaning details you already hold, typically because the parent is a registered adult user; or
2. details of identity and age voluntarily provided by the individual, directly or "through a virtual token mapped to such details, which is issued by an authorised entity".

An authorised entity is one entrusted by law or by the Central or a State Government with issuing identity and age details or such tokens, or a person appointed or permitted by it, and the rule expressly includes details or tokens "made available and verified by a Digital Locker Service Provider" notified under the Information Technology Act, 2000. The rule defines an adult as an individual who has completed the age of eighteen years. That is the complete list of checks the rule names; it prescribes no specific document, vendor or verification technology beyond these classes, and it leaves the choice of appropriate technical and organisational measures open.

4 illustrations in the rule cross 2 situations, the child declaring a parent or the parent opening the account directly, with the parent in each either a registered user whose details the platform already holds or a stranger verified through an authorised entity's details or token. The verifiable consent deep dive walks all four cases one by one.

Rule 12 and the Fourth Schedule: the exemptions

Rule 12 disapplies section 9(1) and section 9(3), and only those 2, for the classes in Part A of the Fourth Schedule and the purposes in Part B, in each case subject to the conditions specified there. Nothing in Rule 12, the Fourth Schedule or a section 9(5) notification exempts section 9(2): even inside these exemptions, processing likely to cause a detrimental effect on a child's wellbeing stays prohibited. The Act's general exemptions in section 17 run on a separate track: section 17(1) can disapply Chapter II of the Act, section 9 included, in listed situations such as processing necessary for enforcing a legal right or claim, but that regime is not specific to children and sits outside this article.

Part A names 5 classes. Clinical establishments, mental health establishments and healthcare professionals are covered where processing is restricted to providing health services to the child "to the extent necessary for the protection of her health". Allied healthcare professionals are covered for supporting a recommended treatment and referral plan. Educational institutions are covered for tracking and behavioural monitoring restricted to their educational activities or the safety of enrolled children. Individuals entrusted with children in a crèche or child day care centre are covered for safety monitoring, and transport providers engaged by such institutions are covered for tracking location during travel to and from the institution, in the interests of safety.

Part B names 6 purposes: exercising legal powers and performing duties in the interests of a child under Indian law; providing subsidies, benefits, services, certificates, licences or permits under section 7(b) of the Act; creating a user account limited to communication by email; determining the real time location of a child in the interest of her safety; ensuring that any information, service or advertisement likely to cause a detrimental effect on a child's wellbeing is not accessible to her; and confirming that a Data Principal is not a child, together with the rule 10 due diligence itself.

Whether you fall within a class is a question about the Schedule's defined terms, not about how your product describes itself. The Note to the Schedule imports definitions from the Clinical Establishments (Registration and Regulation) Act, 2010, the Mental Healthcare Act, 2017 and the National Commission for Allied and Healthcare Professions Act, 2021, and defines an educational institution as an institution of learning that imparts education, including vocational education. Cite those definitions by the corrected letters rather than the printed ones: the Gazette prints 2 items lettered (a) in this Note, and corrigenda G.S.R. 892(E) relabels the list so it runs (a) to (g).

Each Part A entry carries its own condition, and the condition is what decides how far the entry reaches. For the education sector that distinction is the whole answer, so it has its own guide: DPDP for schools and edtech reads entry 3 against its condition column and sets out which school and edtech processing keeps the section 9(1) duty.

The practical read for product teams

• The ban is on practices, not on children. With verifiable parental consent you may process a child's data for your service. What you may not do, consent or no consent, is track children, monitor their behaviour or target advertising at them, unless a Schedule entry covers you and you stay within its condition.
• Checking age is itself lawful. Part B item 6 exempts processing done to confirm that a Data Principal is not a child and to observe rule 10 due diligence, so an age confirmation flow does not itself need parental consent before it can run.
• Build the parent flow on the 2 Rule 10 paths. Reuse the identity and age details of registered adult users where you reliably hold them, and support virtual tokens from authorised entities, Digital Locker included, for parents you do not know.
• Design nothing detrimental. Section 9(2) has no consent override, and no child specific exemption reaches it.
• Nothing here binds yet. The child duties commence on the computed date of 13 May 2027, interpretation until officially confirmed, while the definition of child already stands in force.

Run the children's data checker to see which of these duties and exemptions your context triggers. The official texts live at Section 9, Rule 10, Rule 12 and the Fourth Schedule.