DPDP for EdTech & Learning Platforms, Explained

At a glance

EdTech is the sector where the DPDP Act’s strictest regime — children’s data — sits at the centre of the product. For users under 18, you need verifiable parental consent before processing, and you cannot track their behaviour or target advertising at them. The scoped exemptions the Rules give schools and clinics belong to institutions, not commercial platforms — a learning app shouldn’t assume it qualifies. Since engagement mechanics, recommendations and ad-funded models all run on exactly what’s restricted, DPDP for edtech is a product question before it’s a compliance one.

Educational resource only. This explains how India’s Digital Personal Data Protection Act, 2023 (DPDP Act) applies to edtech and learning platforms; it is not formal legal advice.

The situation

Every edtech metric points at a minor: the learner profiles, the watch-time graphs, the streaks, the parent’s phone number collected as the lead. The industry grew up optimising engagement the way consumer apps do — recommendations, nudges, retargeting — and the DPDP Act draws its hardest line through exactly that playbook when the user is under 18. This isn’t a sector where privacy is a back-office function; the Act reaches into how the product itself is allowed to work, which is why edtech teams need product and legal reading the same page.

Does DPDP apply differently to edtech?

Same fiduciary duties as everyone, plus the children’s-data regime on top — and for most platforms, children are the user base, not the edge case. A learning platform deciding why and how learner data is used is a Data Fiduciary in full: notice, lawful basis, security, breach reporting, retention limits, vendor accountability. What changes the game is Section 9: for any user below 18 — India’s line, higher than the 13 many global platforms are built around — processing requires verifiable consent from a parent or guardian, and behavioural tracking and targeted advertising directed at children are off-limits. Add the scale factor: platforms processing large volumes of minors’ data are prime candidates for Significant Data Fiduciary notification, with audits, impact assessments and a resident data protection officer (DPO) attached.

The student data a platform actually holds

Learning data is behavioural data — the product generates it continuously, about minors.

• Identity and enrolment — the child’s name, age, class, school; the parent’s contacts and payment details; often location.
• Learning records — courses, scores, progress, strengths and weaknesses: an academic profile that follows the child.
• Behavioural exhaust — session times, watch patterns, attention signals, streaks and quiz attempts: exactly the layer engagement engines feed on, and exactly what the tracking restrictions reach.
• Communication trails — doubt-solving chats, teacher interactions, sometimes recorded classes with children’s faces and voices.
• The lead pipeline — demo bookings, counselling-call notes, parents’ financial capacity assessments: the sales layer, holding family data before any enrolment exists.

The obligation that actually bites: the children’s-data regime

Three interlocking rules — parental consent that’s verifiable, no behavioural tracking, no targeted ads — and each lands on a core edtech mechanic.

1. Verifiable parental consent, before processing. A checkbox saying “I am over 18” or “I am the parent” isn’t verification. The Rules expect you to establish that the consenting adult is an identifiable adult — using identity or age details already held, or verified through mechanisms like a DigiLocker-backed token. That’s an onboarding flow to build, not a line to add.
2. No behavioural tracking of children. The recommendation engine, the attention analytics, the engagement scoring — applied to under-18 users, this is restricted territory. Learning-progress tracking that serves the educational function the parent consented to is a different thing from behavioural profiling that serves the platform; the design work is keeping those genuinely separate.
3. No targeted advertising at children. Ad-funded models and remarketing built on children’s usage are directly off-limits — and “the account is the parent’s” doesn’t launder targeting that reaches the child.
4. The age question is unavoidable. A platform that doesn’t know which users are minors can’t apply any of this — and in a product marketed to students, assuming adulthood isn’t a defensible default.

Where the institutional exemptions do and don’t reach

The Rules carve scoped relief for schools and similar institutions — commercial platforms are not on that list. The Rules exempt certain classes of fiduciaries — educational institutions, clinical establishments, crèches, child-transport providers — from parts of the children’s-data regime, for defined purposes like educational activities and safety monitoring, under necessity and minimisation conditions. Two consequences for edtech:

• Don’t borrow the school’s exemption. A commercial learning app is not an educational institution in that sense; building on the assumption that the carve-out covers you is building on sand. Where you serve schools (B2B), the school may have relief for its own processing — while you, as its platform, still carry your own role and duties under your contract with it.
• B2B and B2C are different postures. Serving a school as its processor puts the institution’s decisions (and its exemption, where it applies) in front; selling subscriptions to parents makes you the fiduciary with the full children’s regime. Platforms doing both need both models, not a blur.

Beyond children: the ordinary machinery still runs — granular consent for purposes beyond the service (marketing to parents needs its own opt-in), retention schedules for learners who leave, and the lead pipeline’s data (collected before any contract) resting on notice and consent like any marketing operation.

Common mistakes edtech platforms make

Consumer-app habits applied to minors.

• The self-declared checkbox — “I confirm I am the parent” treated as verifiable consent; it verifies nothing.
• One engagement engine for everyone — recommendations and behavioural nudges running identically on a 14-year-old and a 40-year-old because the system never asks.
• Remarketing on demo data — children’s trial usage feeding ad audiences and counselling-call pressure on parents.
• The counselling hard-sell file — family financial assessments and call notes held forever, without notice, from families who never enrolled.
• Recorded classes as content — children’s faces, voices and names in recordings reused for marketing without specific consent.
• Global defaults — age 13 thresholds, ad SDKs (software development kits) and tracking pixels inherited from international builds, unexamined against India’s under-18 line.

Building enrolment and onboarding compliantly

Verify the parent, split the purposes, and wall the engagement machinery off from minors. Onboarding starts by establishing who’s an adult: a verifiable parental-consent step for every under-18 learner, built on identity mechanisms rather than checkboxes. The consent itself splits purposes — the learning service; progress reports to the parent; marketing to the parent as its own declinable opt-in; nothing targeted at the child. Product-side, under-18 profiles run with behavioural tracking and ad systems off by design — a flag enforced in code, not policy. And the lead pipeline gets the ordinary discipline: notice on the demo form, deletion when the family says no. The consent-mechanics patterns — granular asks, no pre-ticks — are the same ones the consent-design guides on this site walk through; edtech just applies them with a parent in the loop.

FAQ