DPDP for Schools and EdTech: Children’s Data and the Narrow Exemption

Under the DPDP Act, anyone below 18 is a child, and section 9 requires verifiable parental consent before you process their data. Schools get an exemption, but a narrow one: tracking and behavioural monitoring, and only for the institution’s educational activities or the safety of enrolled children. EdTech vendors are not institutions. They do not get it.

That gap is where most Indian education businesses are currently exposed. A school assumes the exemption covers everything it does with student data. A learning app assumes the school’s exemption flows down to it through the contract. Neither is right, and the two assumptions together leave a child’s data being processed with nobody holding a valid consent.

18, not 13

The first thing to get straight is the age. India set the bar at 18. If you have built your product around the COPPA line of 13, or the GDPR’s 13-to-16 range, your entire Class 11 and 12 cohort has just become a child population you are processing without parental consent.

For a K-12 school that changes little — everyone was already a minor. For a test-prep platform, a coding bootcamp aimed at teenagers, or a college-admissions service, it changes a great deal. Those are the businesses that need to look hardest at this.

What section 9 actually demands

Section 9 has three limbs, and they are commonly collapsed into one. They are not the same obligation:

• 9(1) — verifiable parental consent before processing a child’s personal data.
• 9(2) — no processing likely to have a detrimental effect on a child’s well-being.
• 9(3) — no tracking, no behavioural monitoring, and no targeted advertising directed at children.

Keep 9(2) separate in your head, because the Fourth Schedule exemptions never touch it. There is no class of organisation and no purpose that buys you the right to process a child’s data in a way likely to harm her well-being. If your growth loop depends on engagement mechanics that would not survive that sentence, the exemption question is academic.

The school exemption, in full

The Fourth Schedule lists classes of data fiduciary for whom 9(1) and 9(3) do not apply. The educational one reads, in substance: a data fiduciary who is an educational institution, where processing is restricted to tracking and behavioural monitoring for the educational activities of the institution, or in the interests of the safety of children enrolled with it.

Read what that does and does not buy you. It lifts the parental-consent requirement and the tracking prohibition for tracking and behavioural monitoring. It does not lift them for everything else a school does with student data. Publishing exam results to a public noticeboard, handing a class list to a photography vendor, sharing enrolment data with an education-loan partner, running a WhatsApp broadcast to parents promoting next year’s summer programme — none of that is tracking or behavioural monitoring, so none of it sits inside the exemption.

Two neighbouring classes in the same Schedule are worth knowing because schools routinely forget they are separate entities. Crèche and day-care carers are covered for tracking and behavioural monitoring in the interests of the safety of children in their care. And a transport provider engaged by a school is covered for tracking the real-time location of enrolled children during travel to and from the institution. That last one matters: the bus GPS is dealt with explicitly, and the exemption is bounded by the journey. A vendor that keeps the location history to build route-optimisation analytics has walked out of the bounded purpose.

Why EdTech does not inherit it

The exemption attaches to a class of fiduciary — an educational institution — not to an activity called education. A learning platform sold to schools is not an educational institution because its customers are. Nor does a data processing agreement transfer the exemption; a contract allocates responsibility between parties, it does not rewrite a Schedule.

So if you sell into schools, your position is roughly this. Where you act as a processor on the school’s instructions, the school’s lawful basis is what you are relying on, and your job is to stay inside the purpose it gave you. The moment you process for your own purposes — product analytics that profile a student, retargeting a parent who abandoned a checkout, a recommendation engine trained on behavioural data, a free tier monetised by advertising — you are a fiduciary for that processing, the exemption is not available to you, and 9(1) and 9(3) apply in full. We have written separately on when a processor becomes a fiduciary, and education platforms are one of the clearest cases.

What “verifiable” means in practice

A tickbox saying “I am a parent” is not verifiable parental consent. The Rules contemplate you checking against identity and age details you already reliably hold, or against details voluntarily provided through a virtual token issued by an entity authorised to do so — DigiLocker being the obvious route in India. Our note on Rule 10 and verifiable parental consent goes through the mechanisms.

The design problem this creates is worth stating plainly: you now need to know, reliably, whether a user is 18, before you can decide which consent flow to run. Age assurance becomes a gate in front of onboarding rather than a field in a profile form. Budget for it as a flow, not a checkbox.

And the consent notice itself has to be comprehensible to the parent reading it, which in Indian schooling means more than one language. The 22-language requirement is not a translation afterthought for a school serving a district where the parents’ first language is not the medium of instruction. Our privacy-notice template is a reasonable starting structure.

Where the real exposure sits

In our experience the consent flow is rarely the worst problem. These are:

• Admissions data that never leaves. Enquiry forms from applicants who never enrolled, sitting in a CRM for years. The child is not a student, so “educational activities of such institution” is doing no work for you, and there is no retention clock running. Start with a retention policy.
• Alumni and ex-students. The enrolment ended; the processing did not.
• Photographs and video. Annual-day footage, classroom CCTV, marketing creatives using identifiable students. Marketing use is not tracking, not behavioural monitoring, and not safety.
• WhatsApp groups run on teachers’ personal numbers. Parent and student data on devices the institution does not control, with no record of what is held or who left the group.
• Third-party tooling with its own analytics. Proctoring, attendance biometrics, school-bus apps, learning platforms — each one processing for its own purposes behind a contract nobody read.
• Breach readiness. Education is a frequently-hit sector and the reporting clock is short. See the breach notification rules.

A sane order to do this in

The obligations are phased rather than immediate — our DPDP Rules timeline tracks what lands when. That is enough runway to do it properly and not enough to ignore it, because age assurance and consent capture are product work, not policy work.

1. Map where data about under-18s actually lives. Include admissions, transport, the library system, the fee gateway and every WhatsApp group.
2. For each processing purpose, write down whether it is tracking or behavioural monitoring. If it is not, the school exemption is irrelevant and you need consent.
3. Separate what you do as an institution from what your vendors do for their own purposes. Then read those contracts.
4. Build age assurance before the consent flow. Everything downstream depends on knowing which branch to take.
5. Set retention periods per category and actually delete. Alumni and non-joiners first.
6. Give parents a working route to withdraw consent and to exercise a child’s rights — as easy to withdraw as it was to give.

One caution on reading any of this, including ours. The DPDP Rules are recent, the rule numbering in secondary commentary is inconsistent, and the Schedules are where the operative detail lives. Where a number matters to a decision you are about to make, check it against the notified Gazette text rather than a summary. This note is a practitioner’s reading to help you scope the work; it is not legal advice, and no platform or checklist can by itself make an organisation compliant.

Frequently asked questions

Is a 17-year-old a child under the DPDP Act?

Yes. The Act treats anyone who has not completed 18 years as a child. There is no intermediate teenage tier as there is under the GDPR, and the COPPA threshold of 13 is irrelevant in India. A platform serving Class 11 and 12 students is serving a child population in full.

Does a school need parental consent for ordinary attendance and exam records?

The Fourth Schedule exemption is written around tracking and behavioural monitoring for educational activities or the safety of enrolled children, so routine academic administration of enrolled students is the case it is designed for. It does not follow that every use of that record is covered — sharing it outside the institution, or using it for marketing, falls outside the exemption and needs its own basis.

Does the school’s exemption cover an edtech app the school buys?

No. The exemption attaches to the educational institution as a class of data fiduciary. A vendor is not an educational institution, and a data processing agreement cannot transfer a statutory exemption. Where the vendor processes strictly on the school’s instructions it relies on the school’s basis; where it processes for its own purposes it is a fiduciary and section 9 applies to it directly.

Can we show advertising to students?

Targeted advertising directed at children is prohibited by section 9(3), and the Fourth Schedule’s exemptions are confined to tracking and behavioural monitoring for educational or safety purposes — advertising is neither. Separately, section 9(2) prohibits processing likely to have a detrimental effect on a child’s well-being, and nothing in the Schedule exempts anyone from that.

What counts as verifiable parental consent?

More than a self-declaration tickbox. The mechanism contemplates verifying against identity and age details the fiduciary already reliably holds, or against details provided through a virtual token issued by an authorised entity, with DigiLocker the practical Indian route. The operational consequence is that you need age assurance before the consent step, not after it.

Does the exemption cover GPS tracking on school buses?

The Fourth Schedule deals with this explicitly through a separate class: a transport provider engaged by the institution, where processing is restricted to tracking the real-time location of enrolled children in the interests of their safety during travel to and from the institution. The purpose is bounded by the journey, so retaining location history for analytics or other products is outside it.