DPDP for schools and edtech: what the Fourth Schedule exemption really covers

Search for what the DPDP framework means for a school and the first answer you meet is usually a single cheerful line: education is exempt. It is in vendor decks, in webinar slides and in the summary paragraphs of half the compliance blogs covering the Rules. It is also the most expensive misreading available in this sector, because the exemption is real, it is printed exactly where those decks say it is, and it covers almost none of what a school actually does with children's data.

This article reads the education carve out against its own condition column, states what a school, a coaching institution, a creche, a school transport contractor and an edtech company each get from it, separates that from the duties the framework leaves untouched, and then takes on the question the text is quietest about: how anyone is supposed to work out that a user is a child in the first place. Every claim is cited to the Gazette text of the Act and of the Rules as corrected.

The exemption in 1 paragraph

Rule 12 of the DPDP Rules 2025 disapplies section 9(1) and section 9(3) of the Act, and nothing else, for the classes listed in Part A of the Fourth Schedule and the purposes listed in Part B, in each case "subject to such conditions as are specified in the said Part". Entry 3 of Part A names "A Data Fiduciary who is an educational institution". Its condition, printed in the next column, reads:

"Processing is restricted to tracking and behavioural monitoring — (a) for the educational activities of such institution; or (b) in the interests of safety of children enrolled with such institution."

Entry 3, Part A, Fourth Schedule to the DPDP Rules 2025, Gazette page 37.

Read the 2 halves together and the shape is clear. What the entry hands an educational institution is permission to do what section 9(3) otherwise forbids outright, tracking and behavioural monitoring, in 2 defined settings, without collecting verifiable parental consent for it. What it does not hand anyone is a general release from the children's data regime.

Which section 9 duties actually survive for a school

Section 9 carries 4 distinct commands across its 3 operative subsections. Rule 12 names 2 subsections. The Fourth Schedule condition then narrows even those. Set the commands against the entry one at a time, because the answer is different for each.

The last row is the one worth slowing down for, because it is where the drafting rewards a careful reader. Rule 12 disapplies the whole of section 9(3), advertising limb included. But it does so only "subject to such conditions as are specified in the said Part", and the condition in entry 3 is that "Processing is restricted to tracking and behavioural monitoring". Targeted advertising is neither of those things, so advertising processing never satisfies the condition, and the disapplication never arrives to cover it. The exemption is wide enough on its face to reach the advertising ban and is closed off by its own condition before it gets there. That chain is this site's reading of how the 2 texts fit together, not a proposition either one prints.

So the honest 1 line summary for an educational institution: entry 3 buys relief from 2 of the 4 commands, and only for the narrow band of processing the condition describes.

What the school actually does, row by row

The condition column is the whole game. Set your real processing against it.

2 of those rows deserve a pause. A school that installs an attendance and CCTV stack has arranged the single part of its estate the exemption was written for. A school that runs an admissions office, which is every school, has not moved its largest children's data holding out of section 9(1) at all.

The reading behind this table is that the words "subject to such conditions" make the disapplication conditional on the processing being the processing described, so the exemption travels with the activity rather than with the institution. That is this site's reading, not printed text. A second reading is available on which an institution stepping outside the condition loses the entry entirely rather than losing it for that activity. The 2 readings differ about the fate of the exempt tracking, and agree completely about the admissions file: on both of them, verifiable parental consent under section 9(1) applies to it.

The 3 things the Fourth Schedule does not touch

Section 9(2) survives the children's exemptions. The prohibition on processing "likely to cause any detrimental effect on the well-being of a child" is not named in section 9(4), not named in section 9(5), and not named in Rule 12. No class in Part A, no purpose in Part B and no parental consent switches it off. The only exemption in the Act that can reach it, on a check of the Act and the Rules made on 24 August 2026, is section 17, which disapplies the provisions of Chapter II, section 9 included, in the situations listed in section 17(1) and under the notifications section 17(2) and section 17(5) allow; separately, section 3(c) puts personal or domestic processing and certain publicly available personal data outside the Act altogether, which is not an exemption from section 9(2) but a case where the Act never applies. None of those is a children's provision or an education relief, and they are covered in the section 17 exemptions guide. A school running an engagement optimised app, a coaching platform running streak mechanics on 15 year olds and an edtech running push notification loops are all measured against section 9(2) with no children's carve out available.

Section 4 survives too. Rule 12 reaches into section 9. It does not name section 4, which permits processing only for a lawful purpose and only on consent or a certain legitimate use. So an educational institution inside entry 3 still needs a ground for the processing; what it stops needing is the specific verifiable parental consent machinery of section 9(1) and Rule 10 for that activity. And because section 2(j) says that where the Data Principal is a child the expression includes the parents or lawful guardian, the ordinary consent route for a child's data runs through the parent regardless. The exemption removes a verification burden, not the need for a lawful basis.

Targeted advertising has no route through the Fourth Schedule. Section 9(3) bans 3 things: tracking, behavioural monitoring and targeted advertising directed at children. Rule 12 names section 9(3) whole, so on its face the disapplication covers the advertising limb too, but it operates only subject to the Part A condition, and entry 3's condition restricts the processing to "tracking and behavioural monitoring". Advertising processing therefore never satisfies the condition and never attracts the disapplication, as the table above sets out. The words targeted advertising do not appear in the condition, and they appear nowhere in Part A or Part B as something a Data Fiduciary is permitted to do. The only other relief the Act contemplates for the section 9(3) ban is a notification under section 9(5) fixing an age above which a named Data Fiduciary is exempt from the section 9(1) and 9(3) duties, and no such notification is recorded on this site's source register as at 24 August 2026. Part B item 5 points the other way: the exempt purpose there is ensuring that an advertisement likely to cause a detrimental effect on a child's wellbeing is not accessible to her. An advertising funded free product aimed at school students has no path through the Fourth Schedule.

The hard part: deciding the user is a child at all

Every duty in section 9 switches on a fact you may not have. Section 2(f) makes a child "an individual who has not completed the age of eighteen years", which is a clean binary with no bands and no grace zone, and the whole of section 9 sits behind it. Establishing which side of the line a user falls on is the first engineering problem in the sector, and it is the problem the text says least about.

A school barely has it. Enrolment produces a date of birth, a guardian record and a class cohort, so the age of every student is a known field in the student information system. The exposure is narrower and more specific: alumni who are still under 18, siblings whose details arrive on an admission form, prospective students in an enquiry database, and children photographed at an event who were never enrolled anywhere. Those populations sit outside the neat enrolment record and are where a school will actually be wrong about age.

A consumer edtech product has it acutely. Self declared dates of birth are trivially false, a shared family device defeats account level inference, and a free revision app aimed at board exam students is aimed by construction at a population that is mostly under 18.

What the framework actually says about checking. Less than most summaries suggest, and it is worth being exact:

• No provision expressly commands an age check. Neither the Act nor the Rules, checked on 24 August 2026, contains a duty to verify age, an age assurance standard, or a permitted method. The nearest thing is the Rule 10(1) duty to adopt appropriate technical and organisational measures to ensure verifiable parental consent is obtained before a child's data is processed, which on this site's reading presupposes some view of who is a child. What the Rules do is clear the check out of the way: Part B item 6 exempts processing "For confirmation by the Data Fiduciary that the Data Principal is not a child and observance of due diligence under rule 10", restricted to what is necessary for that confirmation. That resolves a genuine circularity, since establishing whether a user is a child is itself processing that would otherwise need the consent you cannot yet know you need. It permits the check. It does not design it or require it.
• Rule 10's due diligence is about the parent, not the child. This is the most commonly inverted point in the sector. The rule requires measures ensuring parental consent is obtained, and due diligence "for checking that the individual identifying herself as the parent is an adult who is identifiable if required in connection with compliance with any law for the time being in force in India". The object of the verification is the adult. Nothing in Rule 10 tells you how to establish the age of the child whose data started the whole enquiry.
• The evidence classes are 2, and closed on their face. Either "reliable details of identity and age of the individual available with the Data Fiduciary", meaning details you already hold because the parent is a known adult user, or "details of identity and age, voluntarily provided" by her directly or "through a virtual token mapped to such details, which is issued by an authorised entity". Rule 10(2)(b) brings a Digital Locker service provider inside the second path, and Rule 10(2)(a) fixes adult at an individual who has completed the age of eighteen years.
• The 4 illustrations vary 2 things only. Who starts the flow, a child declaring a parent or a parent opening the account, and whether that parent is already your registered user. Every case resolves to the same 2 evidence paths, which is a useful signal that the rule intends those paths to be exhaustive.

What the text does not prescribe, verified on 24 August 2026. No document is named. No vendor, standard or certification is named. There is no level of assurance, no confidence threshold, no permitted or forbidden age estimation technique, no rule about self declaration, no duty to re verify at intervals, no stated consequence if a user lies about her age, and no record keeping duty for the verification you performed. Rule 10(1) hands the whole question to "appropriate technical and organisational measures" and leaves appropriate undefined. That is a real gap, and the honest position is that a design cannot yet be measured against anything more specific than the 2 evidence paths and the word appropriate.

Guardians run on a different track. Rule 2(1)(d) defines verifiable consent as "a consent as specified in rule 10 or 11", so there are 2 machineries, not 1. Where the Data Principal is a person with disability who has a lawful guardian, Rule 11 applies instead, and its due diligence is legal rather than documentary in the Rule 10 sense: verify "that such guardian is appointed by a court of law, or by a designated authority or by a local level committee, under the law applicable to guardianship". For an institution running inclusive education or a disability support programme, that is a second and quite different verification flow, resting on appointment orders rather than on identity and age details. The verifiable consent guide walks both.

Is your edtech an educational institution?

Everything in entry 3 hangs on 2 words. The Note to the Fourth Schedule supplies the only definition either text contains:

"“educational institution” shall mean and include an institution of learning that imparts education, including vocational education;"

Item (d) of the Note to the Fourth Schedule, Gazette page 38, corrected lettering.

Notice what the definition does not do. It imports nothing from another statute, unlike the neighbouring items that borrow from the Clinical Establishments Act, the Mental Healthcare Act and the National Commission for Allied and Healthcare Professions Act. It names no registration, recognition, affiliation or board approval requirement. It rests entirely on the phrase "institution of learning that imparts education".

A school, a college, a university, a coaching institution and a vocational training centre answer that description on its ordinary meaning. A direct to learner app selling recorded lessons, an assessment engine, a proctoring service, a school management system and a parent communication app are all less obvious, and neither the Act nor the Rules supply a test. This is an honest unknown, and it is the unknown that matters most commercially, because it decides whether an edtech company holds entry 3 or holds nothing.

There is a second structure worth getting right before anyone reaches that question. Where a school procures an edtech product and decides itself what data is collected and why, the school is likely the Data Fiduciary and the vendor is processing on its behalf, which puts the vendor in the Data Processor position under section 2(k) and puts a section 8(2) contract between them. In that arrangement the vendor does not need entry 3, because the section 9 duties sit with the school, and section 8(1) makes the school responsible for the vendor's processing "irrespective of any agreement to the contrary". Where an edtech sells directly to learners and their parents and sets its own purposes, it is a Data Fiduciary in its own right and the entry 3 question becomes unavoidable. Many edtech companies in India run both models at once, on different products, and the answer differs product by product. The Data Fiduciary and Data Processor guide works through that split, and the processor contract requirements cover the section 8(2) contract.

The 3 Part A classes an education organisation might sit in

Part A prints 5 classes. Entries 1 and 2 are healthcare. The remaining 3 are the education sector's whole allocation, and each carries a different condition, so which entry you can point to decides what you are allowed to do.

2 features of that table are easy to miss. Every one of the 3 conditions is a tracking or location condition: nowhere in Part A is an education organisation given relief for collecting, storing or sharing a child's records. And the classes are drawn by who you are, while the conditions are drawn by what you do, so an organisation can be squarely inside a class and still outside the exemption for the processing in front of it.

Buses, creches and the entries that name someone else

Part A entry 5 covers "A Data Fiduciary who is engaged by an educational institution, crèche or child care centre for transport of children enrolled with such institution, crèche or centre", restricted to tracking location in the interests of safety during travel to and from the institution. The words "engaged by" describe a contracted transport provider. A school that owns and runs its own buses is not engaged by anyone; if it is exempt for bus location tracking, it is exempt through entry 3 as an educational institution tracking in the interests of the safety of enrolled children, and only while that description holds. That is a reading of the 2 entries side by side rather than printed text, and it changes nothing operationally except which entry a school should be able to point to.

Part A entry 4, on creches and child day care centres, is drafted around "A Data Fiduciary who is an individual in whose care infants and children in a crèche or child day care centre are entrusted". It is the only entry in Part A framed around an individual. Whether a company operating a chain of day care centres reads onto that wording is not settled by the text, and the cautious planning assumption for a corporate operator is that it does not, with entry 3 available only if the centre is also an institution of learning that imparts education.

The Part B purposes an education product will actually use

Part A is about who you are. Part B is about what you are doing, so it is open to any Data Fiduciary that meets the condition, edtech included, whether or not it is an institution of learning.

Items 1 and 2 are the other 2, and they rarely reach a private provider: item 1 covers the exercise of a power, function or duty in the interests of a child under Indian law, and item 2 covers providing or issuing a subsidy, benefit, service, certificate, licence or permit under law or policy or using public funds, in the interests of a child, under clause (b) of section 7 of the Act. A government school administering a statutory scholarship may well be inside item 2. A private school billing its own tuition is a much harder fit, because clause (b) of section 7, to which item 2 is expressly tied, is available only "for the State and any of its instrumentalities", and because Rule 5(2), which construes the words "under law or policy or using public funds", opens "In this rule and the Second Schedule" and so does not by its terms reach the Fourth Schedule. Whether a particular school is an instrumentality of the State is a question these texts do not answer.

Item 3 is the one that reshapes a real project. Handing every student a school email address, and nothing more, sits inside the item. Handing every student an account that carries email plus documents plus classroom plus video sits outside it, because the printed condition is that the use of the account is limited to communication by email. That is a procurement decision, made once, that decides whether the school owes verifiable parental consent across its entire student identity estate.

What applies to a school no matter what

The children's provisions are a layer on top of the general framework, and the general framework does not care that you are a school. Everything in this list commences with the rest of the framework rather than earlier, as the next section but one sets out.

• Notice and consent. Section 5 requires a notice with the personal data, the purposes, the manner of exercising rights and the manner of complaining to the Board, accompanying or preceding every consent request. See what a privacy notice must contain and the 22 language requirement, which matters more in education than in most sectors.
• Security safeguards. Section 8(5) and Rule 6 apply to a school's student information system exactly as they apply to a bank, and the cap in entry 1 of the Schedule, an amount that may extend to Rs 250 crore, is the largest in the Act. See Rule 6 security safeguards.
• Breach intimation. Section 8(6) and Rule 7 apply, and a school laptop lost with a class list on it can be a personal data breach within the section 2(u) definition. See breach reporting under Rule 7.
• Erasure. Section 8(7)(a) requires erasure on withdrawal of consent or when the specified purpose is no longer served, unless a law requires retention. The Third Schedule inactivity timers do not reach education: that Schedule names an "e-commerce entity", an "online gaming intermediary" and a "social media intermediary" and no education class. That removes a prescribed clock, not the duty. See Rule 8 retention.
• A published contact. Section 8(9) and Rule 9 require the business contact information of the Data Protection Officer, if applicable, or a person able to answer processing questions, published on the website or app and repeated in every rights response. See who must appoint a Data Protection Officer.
• Rights. Sections 11 to 14 give access, correction, erasure, grievance redressal and nomination rights, and for a child Data Principal section 2(j) routes them through the parent or lawful guardian.
• Staff data. Teacher, administrator and applicant data is adult personal data processed by the same Data Fiduciary, with none of the section 9 layer and all of the rest. See DPDP for HR teams.
• Paper is not a shelter for long. Section 3(a) applies the Act to personal data collected in digital form or "in non-digital form and digitised subsequently". A paper admission form that is scanned into the school server, or typed into a spreadsheet, is inside the Act from that moment.

The number attached to getting children wrong

Entry 3 of the Schedule to the Act reads:

"Breach in observance of additional obligations in relation to children under section 9."

The Schedule to the DPDP Act 2023, Gazette page 21. Penalty: may extend to two hundred crore rupees.

The entry names section 9 as a whole, so it reaches the verifiable consent duty in subsection (1), the wellbeing prohibition in subsection (2) and the tracking and advertising ban in subsection (3) alike. Rs 200 crore is matched only by the entry 2 cap for failing to intimate a personal data breach and exceeded only by the Rs 250 crore security safeguards cap, and it sits above the Rs 150 crore cap for the additional obligations of a notified Significant Data Fiduciary. On the face of the Schedule, mishandling children's data is placed above being a large fiduciary that misses its extra duties. Section 33(1) makes the amount a maximum determined by the Board after an inquiry rather than a fixed fine; the factors the Board must weigh sit in section 33(2).

None of this is in force yet

Notification G.S.R. 843(E) names sections 7 to 10 and sections 11 to 17 in the group commencing 18 months after publication, and Rule 1(4) puts Rules 3, 5 to 16, 22 and 23, which covers Rules 10 and 12, in the matching 18 month group. Section 9, Rule 10, Rule 12 and the Fourth Schedule therefore arrive together, on the computed date 13 May 2027, which is interpretation until officially confirmed because the official texts state a period of eighteen months from publication rather than a calendar date. The definition of a child in section 2(f) is already in force, from 13 November 2025, along with the rest of section 2. The full sequence is on the timeline, and what is actually in force today sets out the position across the whole framework.

That gap is the useful part. An education sector Data Fiduciary planning now is planning against a text that will not change under it, with the Rules already notified rather than in draft.

What an edtech product actually has to build

Translated into the 5 things that show up as tickets. The middle column is the text; the right column is where teams get it wrong.

Nothing in that table is specific to children except the first 3 rows. That is the shape of the sector's problem: an education product carries the ordinary Data Fiduciary build plus a verification layer, and the exemption everyone quotes touches only a slice of the middle.

What to prepare, in order

These are recommendations rather than requirements, and nothing below is owed until commencement.

1. Map processing, not systems. Because every Fourth Schedule condition is written per processing, the unit that matters is the activity: attendance, CCTV, admissions, fees, health, photographs, transport, communications, analytics. An institution that has never listed them cannot show which side of a condition any of them fell on.
2. Decide, in writing, what you intend to rely on entry 3 for. It should be a short list, and everything not on it needs the parental consent route.
3. Design the parental consent flow for the long list, not the short one. Rule 10 gives 2 evidence paths: reliable identity and age details of the parent that you already hold, or identity and age details the parent voluntarily provides, either directly or through a virtual token issued by an authorised entity, Digital Locker included. The verifiable consent walkthrough covers the 4 illustrated cases.
4. Check the account question before your next procurement. Part B item 3 protects an email only account and nothing wider, so the scope of a student identity is a compliance decision as much as an IT one.
5. Audit the product against section 9(2) separately. No children's exemption in Rule 12 or the Fourth Schedule reaches it, and engagement mechanics are where an education product is most likely to meet it.
6. Settle the fiduciary and processor split with every vendor. Section 8(1) leaves the school answerable for processing carried out on its behalf whatever the contract says, and section 8(2) requires a valid contract before a processor may be involved at all.

Run the children's data checker against your own context, then build the rest of the obligation set with the company compliance plan, which carries the general Data Fiduciary duties this article only lists. The general scheme for children, outside the education sector, is in children's data under the DPDP Act, and the sector overview sits at DPDP for education and edtech. The official texts are at Section 9, Rule 10, Rule 11, Rule 12 and the Fourth Schedule.