The DPDP Act and Student Data: What Schools Need to Know

A note before anything else: this is a practical summary written by a software team, not legal advice. The Digital Personal Data Protection Act, 2023 and its rules have real consequences for institutions, and decisions about compliance should be taken with a lawyer who knows your specific circumstances. What follows is intended to help you ask better questions, not to replace that.

With that said: a large number of software vendors selling to Indian schools still advertise GDPR compliance. GDPR is European law. If your students are in India, the regime that governs their personal data is the DPDP Act.

Does the DPDP Act apply to schools?

Two features of the Act land unusually hard on educational institutions.

The first is that most of the people whose data you hold are children. The Act treats data about anyone under eighteen with additional care, and requires verifiable parental consent for its processing. That is a materially different obligation from consent given by an adult on their own behalf.

The second is that behavioural tracking and targeted advertising directed at children are prohibited. For a school this mostly means being careful about what third-party analytics, advertising pixels and embedded tools you allow anywhere a student signs in.

Is the school or the software vendor responsible under DPDP?

This is the part most commonly misunderstood, and it is worth being precise about because it determines who is accountable when something goes wrong.

• The institution is generally the data fiduciary. You decide what student data is collected and why. Most obligations under the Act — consent, notice, retention, responding to requests — sit with you.
• The software vendor is generally a data processor, acting on your instructions. A vendor cannot take on your fiduciary duties by selling you a subscription.
• A vendor certificate is not compliance. It is one input into your compliance.

This matters when a vendor tells you their platform makes you compliant. No platform can do that, because the obligations are about your decisions — what you collect, why, how long you keep it and who you share it with. What a platform can do is make those decisions implementable and auditable.

Consent, and where schools get it wrong

The Act requires that notice be clear and that consent be specific to a purpose. The common failure in institutions is not the absence of consent but its shape: a single broad authorisation collected at admission, in English, covering everything the school might ever do.

A more defensible approach separates the purposes:

1. 1Data necessary to deliver education — enrolment, attendance, marks, fees. Usually the least contentious category.
2. 2Communication — how the institution contacts guardians, and through which channels.
3. 3Photographs and video, particularly for publication on a website or social media. This is where objections most often arise and where a blanket consent is weakest.
4. 4Sharing with third parties — a transport contractor, a photographer, an examination board, an analytics provider.

Consent should also be withdrawable, and withdrawal should be as easy as giving it. In practice that means someone at the institution needs to be able to act on a withdrawal request, which is an operational capability rather than a legal one.

How long can a school keep student data?

The Act expects personal data to be erased when the purpose it was collected for is complete, unless retention is required by another law. Institutions are structurally bad at this, because the default in education has always been to keep everything forever.

Practical questions to work through, ideally with your legal advisor:

• How long after a student leaves do you keep their full record, as opposed to the academic transcript you are obliged to retain?
• What happens to admission applications from candidates who never enrolled? These are often the largest pile of unnecessary personal data an institution holds.
• How long do you keep guardian contact details after the last child of that family leaves?
• What about photographs and video from events, some of which may be published?

Answering these produces a retention schedule, and a retention schedule is the artefact an inspection will actually ask for. It is also a genuine data-minimisation win: most institutions discover they are holding several years of applications from people who were never their students.

Breach notification

The Act requires notification of personal data breaches to the Data Protection Board and to affected individuals. The practical consequence for an institution is that you need to be able to answer three questions quickly.

1. 1What was accessed, and whose data was in it?
2. 2When did it happen, and when did we find out?
3. 3Who has it now, and what have we done about it?

None of these is answerable without an audit trail. This is the concrete reason to care whether your software logs administrative actions — not because logging is a compliance checkbox, but because on the worst day of the year it is the difference between a precise notification and a guess.

What to ask a vendor

Nine questions that establish whether a vendor has done the work or copied the claim.

1. 1Where is our data hosted, and does it leave India?
2. 2Which of your staff can read a student record, under what circumstances, and is that access logged?
3. 3Can we export our complete data ourselves, and can we have it permanently deleted on request?
4. 4What is logged — does the audit trail cover marks changed, fees waived and permissions granted?
5. 5Are there third-party components that receive student data? Analytics, messaging gateways, payment processors, model providers?
6. 6Is our data used to train anything, or to serve any other customer?
7. 7How is consent recorded in the system, and can it be withdrawn per purpose?
8. 8Can retention rules be configured, or does the system keep everything indefinitely?
9. 9What is your breach notification commitment to us, and in what timeframe?

A vendor that answers these specifically has thought about it. A vendor that responds with a compliance badge has not, and a vendor that answers with GDPR is answering a question about a different continent.

A reasonable starting sequence

For an institution beginning from paper processes and informal consent, roughly this order works:

1. 1Inventory what you hold and where — including the spreadsheets and the message groups, not just the software
2. 2Write down why each category is collected; delete what has no current purpose
3. 3Rebuild the admission consent form around separated purposes, in the languages your families actually read
4. 4Set a retention schedule and put a date in the calendar to act on it
5. 5Restrict access by role, so that a class teacher, an accountant and a principal genuinely see different things
6. 6Confirm the audit trail exists and that someone knows how to read it

The first two steps consistently deliver the most, and neither needs software. Most institutions are holding considerably more personal data than any current purpose justifies, and reducing that reduces both the obligation and the consequence of a breach.

Where CampusTrue stands

Our platform is built around the DPDP Act rather than GDPR, because our institutions and their students are in India. Access is role-based to the record level, administrative actions are written to an audit trail you can read back, records are protected in storage and in transit, and backups can be restored to a point in time.

What we cannot do — and no vendor can — is make an institution compliant. The consent you collect, the purposes you collect it for and how long you keep it are yours. What we try to do is make sure that when you decide those things, the system can actually implement them, and that you can show an inspector what happened and when.