DPDP Act and Children's Data in India: Verifiable Parental Consent, Tracking Bans and What EdTech Must Change

Under the Digital Personal Data Protection Act, 2023, a child is anyone who has not completed 18 years of age — Section 2(f) — and before processing a child’s personal data a business must obtain verifiable consent of a parent or lawful guardian under Section 9(1), while Section 9(2) and Section 9(3) prohibit — with only narrow, notified exceptions — processing likely to cause detrimental effect on a child’s well-being, tracking, behavioural monitoring and targeted advertising directed at children. Breach of these duties carries a penalty of up to two hundred crore rupees.

Why is children’s data the highest-risk DPDP obligation for most Kerala businesses?

Because the age threshold catches far more users than teams expect, and the prohibitions go to product design, not just paperwork. A business that thinks of its users as young adults — a learning app, a gaming platform, a social community, a health or counselling service — often discovers that a large share of its registered base is under 18. Under Section 9, every one of those users must be handled through parental consent, and every tracking and ad-targeting decision must be re-examined.

Kerala is not an edge case here. KSUM-backed edtech, healthtech and gaming startups in Kochi and Thiruvananthapuram, tuition centres and schools that run apps and CRMs, and consumer apps with nationwide reach all process children’s data. The startup exemption power in Section 17(3) does not extend to Section 9 at all; the relaxations are the classes and purposes prescribed under Section 9(4), set out in the Fourth Schedule to the Rules, and any age-based exemption the Central Government notifies under Section 9(5) for a fiduciary whose processing of children’s data is verifiably safe. The obligation applies in full from 14 May 2027 — the date the 18-month tranche of the DPDP Rules, 2025 (G.S.R. 846(E), 13 November 2025) commences, together with the Section 33 penalty regime. The Board’s powers and inquiry procedure are set by the Act itself (Sections 27 and 28) — content that treats May 2027 as distant is underestimating the engineering time an age-gating and consent redesign actually takes.

What does verifiable parental consent mean under Rule 10?

Section 9(1) states the principle. Rule 10 of the DPDP Rules, 2025 supplies the method, and its design is deliberately more demanding than a checkbox:

• What must be verified: that the person giving consent for the child’s data is actually the parent or lawful guardian, and that the child is indeed a child. The fiduciary must be able to demonstrate this verification if the Board asks.
• How verification is done: by relying on identity and age details the fiduciary already holds about the parent or guardian, or on details voluntarily provided and then verified — Rule 10 contemplates checking through means such as Digital Locker (under the IT Act framework) or a virtual token issued by an authorised entity. The token approach is designed so the fiduciary does not need to collect and store a parent’s full identity document where a tokenised confirmation suffices.
• Parallel for persons with disabilities: Rule 11 applies a similar verifiable-consent scheme where the Data Principal has a lawful guardian under the Rights of Persons with Disabilities Act framework.

What does not satisfy the rule: a self-declared I am 18 checkbox, a pre-ticked parental consent box, or an email link that anyone with access to the child’s email can click. The word verifiable in Section 9(1) was chosen to exclude exactly those patterns.

What is banned outright — and what falls in the narrow exemptions?

Two prohibitions in Section 9 apply in addition to the parental-consent requirement, and they apply even where parental consent for general processing has been obtained:

• Section 9(2) — no processing of personal data of a child that is likely to cause any detrimental effect on the well-being of the child. Detriment is not defined exhaustively in the Act and will be shaped by the Board and by sectoral guidance, but the plain meaning covers physical, mental and social well-being.
• Section 9(3) — no tracking or behavioural monitoring of children, and no targeted advertising directed at children. This is an absolute bar on the product patterns most consumer apps monetise: profiling for ad targeting, recommendation engines that track a child’s behaviour across sessions, and personalised ad delivery to children.

The Fourth Schedule, read with Rule 12, then carves out a small set of exempted classes of fiduciaries and purposes — Part A covers clinical establishments, mental health establishments and healthcare professionals (health services only), allied healthcare professionals, educational institutions (tracking/behavioural monitoring for educational activities or child safety only), crèche or child day-care carers, and transport engaged by such institutions; Part B covers purposes such as legal duties in the interests of the child, subsidies/benefits under Section 7(b), email-account creation, real-time location for safety, filtering detrimental content from children, and age-confirmation/Rule 10 due diligence — each purpose-bound and class-bound. The key point for most businesses: the exemption is purpose-bound and class-bound. An edtech that processes a child’s data to deliver a lesson may fall within the educational purpose in its teaching function, but that does not exempt the same company’s ad network from the Section 9(3) ban on targeted advertising to children on the same app. Each processing purpose must be tested separately.

What must a Kerala school, college, edtech or consumer app actually build?

The practical work is product and data-architecture work, not just a policy update. A realistic implementation sequence for a team starting in late 2026:

1. Map where children are. Identify every flow where an individual under 18 can be a Data Principal — registration, marketing lists, analytics, support tickets, payment flows. If age is not collected today, that is itself the gap — you cannot route children through parental consent if you do not know who they are.
2. Design age-gating. Build a verification step at registration or at the point data is first collected that determines age in a verifiable way. For mixed-age apps, this means a neutral age gate before any personal data beyond the gate itself is processed, with under-18 users diverted to the parental-consent flow rather than the standard onboarding.
3. Build the parental-consent flow under Rule 10. Implement the verification against identity details already held or against voluntarily provided details checked via Digital Locker or an authorised virtual token. Log the consent with the particulars Section 6(10) requires the fiduciary to be able to prove — who consented, when, on what notice, for what purposes.
4. Strip tracking and targeted ads for children. Audit every SDK, analytics event and ad call that fires for a child user. Disable behavioural monitoring and targeted advertising for children entirely unless the specific processing falls within a Fourth Schedule / Rule 12 exemption and has been documented as such with legal review.
5. Rewrite the notice for parents. The Section 5 notice — itemised, in clear language, available in English and the Eighth Schedule languages the parent chooses, including Malayalam — must precede the consent request. A privacy policy link does not satisfy Section 5.
6. Set retention and erasure. Section 8(7) requires erasure once consent is withdrawn or the specified purpose is no longer served, unless retention is required by law. For large e-commerce, gaming and social media intermediaries with thresholds in the Third Schedule, Rule 8 adds a three-year inactivity clock. Build the deletion job, not just the written retention schedule.
7. Train support. A parent who writes in to withdraw consent under Section 6(4) — withdrawing must be as easy as giving it — must have that withdrawal honoured and logged, and a child who contacts support must not be social-engineered around the gate.

How does this interact with other laws schools and apps already follow?

DPDP Section 9 sits on top of, not instead of, existing duties:

• IT Act and intermediary duties. A platform that hosts user-generated content is also subject to the IT (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021 as amended on 10 February 2026, which accelerates takedown for CSAM and non-consensual intimate imagery involving children to two hours on a complaint under Rule 3(2)(b) (previously twenty-four hours). DPDP verifiable consent and IT Act takedown are cumulative.
• Education-specific regulation. School and college data handling is also shaped by affiliation-board and state guidelines, but none of those displaces the DPDP requirement — a CBSE or Kerala state-board affiliation does not exempt an institution from being a Data Fiduciary for the digital personal data it processes.
• BSA evidence. Consent logs that prove verifiable parental consent was obtained will, if disputed, be electronic records that need a Section 63 BSA certificate (new 65B) to be admissible. Design the log with hash and dual-signature certification in mind from the start — see the electronic evidence guide.

Primary sources

• Digital Personal Data Protection Act, 2023 — India Code (Sections 2(f), 5, 6, 8, 9, 10, 33 and the Schedule)
• Digital Personal Data Protection Rules, 2025 (G.S.R. 846(E), 13 November 2025) — MeitY (Rules 3, 6, 7, 8, 10, 11, 12, 14, First, Third and Fourth Schedules)
• PIB backgrounder and press release on notification of the DPDP Rules (14 and 17 November 2025)
• IT (Intermediary Guidelines and Digital Media Ethics Code) Amendment Rules, 2026 (G.S.R. 120(E), 10 February 2026) — Gazette of India (Rules 3(1)(d), 3(2) — two-hour takedown for CSAM and non-consensual imagery)
• Bharatiya Sakshya Adhiniyam, 2023 — India Code (Section 63 on electronic evidence certificates)