Digital Trust · DPDP for EdTech

DPDP for edtech: most of your users are children. The Act treats that differently.

For founders, product heads, CTOs and compliance leads at learning platforms, test-prep apps, LMS providers and school-management systems. DPDP’s rules for children — verifiable parental consent, no behavioural tracking, no targeted advertising — apply to the core of your product, not the edges. Your school customers are also asking for evidence.

Verifiable parental consentNo tracking or targeted adsSchools as customers & fiduciariesLearning analyticsAI tutors
Where this starts

What edtech teams usually discover in week one.

The privacy policy exists. The gaps are operational: what was collected under which consent, who it went to, and whether anyone can prove it. If three or more of these apply, a scoped gap assessment is the right first step.

Regulators & rule-sets in play
Data Protection BoardSchool boards & affiliation bodies (contractual expectations)CERT-In

Sound familiar?

  • Students sign up themselves with a date of birth field nobody validates, and parents are never asked.
  • Engagement analytics, nudges and streaks are tuned on children’s behaviour with no stated purpose in the notice.
  • Ad networks or growth SDKs are embedded in apps used by children.
  • Schools hand you student rosters under a one-page order form with no data-processing terms.
  • AI tutors store every conversation, including what children say about themselves, indefinitely.
  • Parents asking what data you hold on their child are routed to a generic support inbox.
Personal data in scope

The data a EdTech organisation actually holds.

A DPDP programme starts with an honest inventory. These are the categories we typically find across edtech systems — each needs a purpose, a basis, an owner and a retention period.

  • Student identity, class and school
  • Learning progress, scores and attempts
  • Voice, video and chat with AI tutors
  • Parent contact and payment details
  • Device and usage data
  • Teacher accounts and content
School classroom with a teacher and students, most of whom are minors whose data education platforms process
How the Act applies

DPDP obligations, translated for EdTech.

The Act is sector-neutral. Its impact is not. These are the obligations that carry the most weight for your workflows.

01

Verifiable parental consent

Processing a child’s personal data requires verifiable consent from a parent or lawful guardian. Sign-up flows must establish age and obtain that consent before processing begins.

02

No tracking, behavioural monitoring or targeted advertising directed at children

Engagement optimisation and growth tooling must be reviewed against this rule, not assumed to be “product analytics”.

03

Notice a parent can understand

What you collect from the child, why, who receives it (school, tutors, vendors), how long you keep it and how to withdraw.

04

Role clarity with schools

When a school licenses your platform, the school is often the fiduciary and you the processor; direct-to-consumer you are the fiduciary. Contracts and notices must reflect which.

05

Privacy by design for AI features

AI tutors and voice features collect rich personal data. Minimise, define retention for conversations, exclude children’s data from model training unless clearly consented and safe.

We keep legal specifics general on this page. Section-level analysis, penalty exposure and interpretation are worked through with your counsel during the engagement.

The hard part

Growth mechanics versus the children’s-data rules.

Most edtech products were built on engagement analytics, personalised nudges and re-marketing. Under DPDP, behavioural monitoring and targeted advertising directed at children are not permitted, and personalisation must be justified as serving the learning purpose. The resolution is a feature-by-feature review, not a policy update.

How we resolve it

  • Inventory of every analytics, attribution, ad and messaging SDK, and the data it collects about children.
  • Removal or reconfiguration of tracking that does not serve the learning purpose; documented justification for what remains.
  • Age and parental-consent gating at sign-up, with consent versioning and easy withdrawal.
  • Retention rules for learning data, AI conversations and voice recordings, with deletion on withdrawal or account closure.
In your workflows

Where consent, notice and rights actually show up.

Sign-up & consent

Age determination; verifiable parental consent path; layered notice for parents; consent log versioned against the notice.

Learning & AI tutors

Purpose statements for personalisation; conversation retention limits; training-data exclusion rules; AI systems registered with governance status.

Schools & institutions

Data-processing terms in school contracts; roster handling; role documentation (fiduciary vs processor) per deployment.

Parents & rights

Parent-facing rights portal for access, correction and erasure; withdrawal that stops processing across app, analytics and vendors.

Want to know which of these is your biggest gap? The free assessment takes about ten minutes and scores seven compliance areas.

Run the Gap Assessment
Typical starting points

Three ways EdTech clients begin.

Scoped, time-boxed and designed to produce evidence early — so the board and the regulator see progress inside the first month.

First engagements

  • SDK and tracking inventory with a children’s-data review of every feature in two weeks
  • Parental-consent and age-gating redesign with a versioned consent log
  • School data-processing terms and a parent rights workflow evidenced in Avisha Trust
How the programme runs

From gap assessment to continuous readiness.

1

Week 1–2 · Gap assessment

Data inventory, consent and notice review, vendor and rights-process review, breach readiness. Prioritised findings.

2

Week 3–6 · Remediation sprint

Notice and consent redesign, retention-vs-erasure matrix, vendor contract terms, breach playbook — highest-risk gaps first.

3

Week 7–12 · Operations

Rights-request workflow, consent logging and evidence store live in Avisha Trust; teams trained; first evidence pack produced.

4

Ongoing · Monitoring

Quarterly reviews, vendor re-assessment, AI-usage tracking and readiness reporting to the board.

Built for the Indian regulatory stack

We reconcile DPDP with the sector rules that already bind you, instead of importing a foreign template.

Security and compliance from one team

“Reasonable security safeguards” are tested by the people who run VAPT and incident response, not only described in policy.

Evidence, continuously

Avisha Trust captures consent, rights requests and attestations so the answer to “show me” is an export, not a project.

FAQ

DPDP for EdTech: questions we hear most

Design it as part of onboarding rather than a legal interruption: a parent step with a low-friction verification method appropriate to the risk, a short notice written for parents, and consent recorded against that notice. We have built this for Study24by7 and apply the same patterns.
Aggregate, non-identifying analytics used to improve the product is generally defensible. Individual-level behavioural profiling used to drive nudges, retention campaigns or advertising to a child is what the Act targets. We classify each analytics use accordingly.
Usually the school decides the purpose and you process on its behalf — making you the processor — but many platforms also collect data directly from parents and students, where you are the fiduciary. Most edtech companies are both, and their contracts and notices need to say so.
Only with a clear, consented purpose and strong safeguards, and in many cases the safer decision is to exclude children’s data from training entirely. We define retention and training rules per feature and register the AI system in your governance inventory.
Related sectors

DPDP looks different next door.

Start with your sector’s pressure point.

Request a scoped EdTech DPDP assessment, or run the free gap assessment first.