Children's Data in Schools and Ed-Tech Under the DPDP Act
The DPDP Act treats everyone under 18 as a child, and the Rules exempt schools from its strictest limits only for teaching and safety. Ed-tech platforms, coaching centres and foreign campuses need to work out which side of that line they are on.
- CATEGORY
- Article · Ed-tech
- POSITION AS OF
- October 2026
- READING TIME
- 7 min read
- TAGS
- Ed-tech, Children's data, Parental consent, Schools, DPDP Act
Introduction
Few organisations hold as much children's data as a school. It knows each child's age, address, parents, health conditions, marks and behaviour, and increasingly where the school bus is at any minute. An ed-tech app may also know when a child logs in, how long each video holds their attention and which topics they avoid.
Section 9 of the Digital Personal Data Protection Act, 2023 (the DPDP Act) governs all of this. It applies to every child, defined in section 2(f) as anyone under 18, which brings most Class 11 and 12 students and some first-year undergraduates within the rules. The real question for the sector is not what section 9 says, but who is allowed to step outside it, and for what. Section 9 and the related Rules commence on 13 May 2027.
The legal position
Section 9 places three duties on a data fiduciary (the organisation that decides how data is used). Rule 12 and the Fourth Schedule to the DPDP Rules, 2025 then exempt certain classes of fiduciary from two of them, each for a limited purpose. The result for education looks like this:
| Duty under section 9 | Education bodies that can be exempt | Limited to |
|---|---|---|
| Verifiable parental consent before processing (s.9(1)) | Educational institutions; crèches and day-care centres; transport providers for children | Teaching activities or children's safety; location tracking during travel, for safety |
| No tracking or behavioural monitoring (s.9(3)) | The same classes | The same purposes |
| No targeted advertising directed at children (s.9(3)) | None | |
| No processing likely to harm a child's well-being (s.9(2)) | None |
A second part of the Fourth Schedule exempts certain purposes for any fiduciary, including verifying that a user is not a child and blocking content harmful to children.
Parental consent. Rule 10 requires the fiduciary to check that the person consenting is an identifiable adult. It may rely on identity and age details it already holds reliably, or on details or a "virtual token" issued by an authorised entity, and the Rules' illustrations name DigiLocker as one route. Aadhaar is not mandated, and no single method is prescribed.
A recent correction. The DPDP (Removal of Difficulties) Order, 2026, issued on 5 October 2026, corrected section 9(1) so that it clearly refers to the data "of a child or of a person with disability".
Penalty. Breach of section 9 carries a penalty of up to ₹200 crore under the Schedule to the Act.
Analysis
Who is an "educational institution"?
The Fourth Schedule defines an educational institution as an institution of learning that imparts education, including vocational education. Schools, colleges and training institutes fit easily. Ed-tech businesses usually fall into one of three models, and the exemption works differently for each.
- School-licensed tools. The school chooses the platform and decides how it is used; the vendor runs it on the school's instructions. The vendor is a data processor, and the school's exemption covers the monitoring the school directs for teaching or safety.
- Free tools that students join themselves. A homework app recommended by a teacher but signed up for by the student directly is the app's own service. The app is a fiduciary, and the school's exemption does not travel with it.
- Direct-to-parent platforms. A subscription service sold to families is plainly a fiduciary. Whether an app is an "institution of learning" is untested, and a cautious business should assume it is not.
For the second and third models, the safe course is verifiable parental consent for all under-18 users and no behavioural monitoring.
Where everyday features become monitoring
The Act does not define "tracking" or "behavioural monitoring". Features that ed-tech products treat as routine may fall within the words: "focus scores" built from tab-switching during lessons, face-detection checks that a student is looking at the screen, late-night activity reports sent to parents, and models that predict which student is likely to drop out. For a school using them for teaching or safety, the exemption may apply. For a platform without the exemption, section 9(3) is a prohibition, so parental consent does not cure it.
Upselling is the clearest case. Using a 15-year-old's learning patterns to promote a paid course is targeted advertising directed at a child, and nothing in the Schedule exempts it.
The rule nobody is exempt from
Section 9(2) bars any processing "likely to cause any detrimental effect on the well-being of a child". It applies to schools as much as to apps, and no exemption touches it. The Act does not define well-being, but some practices plainly carry risk. Publishing ranked marks lists with names, sharing disciplinary records in parent WhatsApp groups, and leaderboards that expose weaker students all qualify. So do engagement features designed to keep children on a screen late at night. Schools and platforms should run a short well-being check on any new feature that uses children's data and record the outcome. That record is the best evidence of good faith if a complaint reaches the Board.
Older students and coaching centres
Section 9(5) lets the government lower the age for data fiduciaries that process children's data in a verifiably safe manner, but no such notification has been issued as of October 2026.
Coaching centres face a separate rule. The Ministry of Education's Guidelines for Regulation of Coaching Centres, 2024 prohibit enrolling students below 16 or before the secondary school examination, and bar publishing assessment results. Every coaching centre student under 18 is still a child under the DPDP Act.
Government systems: APAAR
Schools also feed government databases, most visibly APAAR, the national academic ID generated through the UDISE+ system. The Ministry's own brochure asks schools to obtain physical parental consent. On 20 July 2026, in Abhishek Baxi v. Union of India (W.P.(C) 832/2026), the Supreme Court directed that processing for APAAR must comply with the DPDP Act and that the data must not be shared with private parties except as the law permits. Schools should keep consent records for APAAR separately and should not treat enrolment as consent.
Foreign university campuses
The UGC (Setting up and Operation of Campuses of Foreign Higher Educational Institutions in India) Regulations, 2023 do not deal with student data. The DPDP Act fills that gap. A campus in India processes data in India and is fully covered under section 3(a). Sharing records with the parent university abroad is a cross-border transfer. Section 16 restricts transfers only to countries the government notifies, and none had been notified as of October 2026. Where the parent university runs admissions from abroad, its processing is covered by section 3(b) when it is connected with offering education to applicants in India.
Many first-year students on these campuses will be 17, so section 9 applies to them as well.
Practical implications
A worked example. A private K–12 school uses a cloud learning platform, CCTV cameras and GPS on its buses, and an app through which parents pay fees.
- It sorts its processing. Bus tracking and CCTV for safety fall within the Fourth Schedule exemption. Classroom analytics fall within it only if used for teaching. Fee reminders and photographs posted on social media do not.
- It treats the platform vendor as a processor. Its contract confines the vendor to running the service for the school, and forbids building learner profiles for the vendor's own products or contacting families directly.
- It sets up consent where needed. For activities outside the exemption, such as publicity photographs or third-party contests, it collects verifiable parental consent through its existing parent-portal accounts, which already hold verified identities.
- It sets retention periods. It keeps CCTV footage only for the period its affiliating board requires. It deletes bus location trails after a short, documented period.
| Question | If yes |
|---|---|
| Are any users under 18? | Section 9 applies; plan verifiable parental consent (Rule 10) |
| Are you an educational institution, crèche or child transport provider? | Use the Fourth Schedule exemption, limited to teaching or safety |
| Do you sell directly to parents or students? | Assume no exemption; no behavioural monitoring of children |
| Do you personalise offers or adverts? | Stop for under-18 users; section 9(3) is a ban |
| Do you share records abroad? | Check s.16 notifications and any sector rules |
| Do you feed APAAR or UDISE+? | Keep separate consent records; offer a refusal option |
Key takeaways
Section 9 is the DPDP Act's strictest provision, and education is where it bites hardest. Schools have a workable exemption for teaching and safety, but ed-tech platforms selling directly to families should plan on the assumption that they have none. Targeted advertising to under-18s is prohibited outright. The Supreme Court's APAAR order shows that courts expect even government-mandated school data flows to meet the Act's standards.
- Everyone under 18 is a child under the DPDP Act, including most senior secondary and some first-year college students.
- Section 9 requires verifiable parental consent and bans tracking, behavioural monitoring and targeted advertising directed at children.
- Schools, crèches and child transport providers are exempt from parental consent and monitoring rules only for teaching or safety; no one is exempt from the advertising ban.
- Direct-to-consumer ed-tech platforms should assume the institutional exemption does not cover them.
Anonymisation and Pseudonymisation Under the DPDP Act
The DPDP Act never mentions anonymisation, so whether a dataset escapes it turns on one word in section 2(t), 'identifiable', and on who could do the identifying.
SDKs, Pixels and Trackers: Who Is Responsible Under the DPDP Act?
Every SDK in an app sends data to someone, and the DPDP Act holds the app answerable for what its code collects while making a vendor that uses the data for itself answerable too.
DPDP Act vs Singapore's PDPA: Taking Your Programme Into Asia
An Indian company with a DPDP programme already has most of what Singapore's PDPA asks for, but breach triage, transfers back to India, a DPO and Do Not Call checks are new work.
