The school is the one on the hook
Under the DPDP framework, the entity that decides why and how personal data is processed is responsible for it. For student records, that's the school — not the vendor. "Our software provider handles data protection" is a description of an arrangement, not a transfer of liability.
Practically, this means a school cannot fully outsource the question. You can and should choose a vendor whose architecture makes compliance easier, but you remain the one who has to be able to answer what data you hold, why, where it lives, and who can see it.
Children's data is treated more strictly
The Act singles out the personal data of children for additional obligations, including verifiable parental consent and restrictions on tracking and targeted advertising directed at them. A school is, almost by definition, an organisation whose primary data subjects are children.
That has a concrete implication most schools miss: any third-party tool a teacher independently signs the class up for — a free quiz app, a video platform, a messaging group — is processing children's data on the school's behalf, usually with no agreement and no record. Informal tooling is where most of the real exposure sits, not in the ERP.
Data minimisation is the cheapest control you have
The simplest way to reduce risk is to hold less. Schools accumulate data by default: scanned Aadhaar copies collected "for admission", parent occupation and income fields nobody has queried in five years, photographs kept indefinitely.
Go through what your system collects and ask, field by field, what decision it informs. Anything that doesn't inform a decision is pure liability. This costs nothing and is the single highest-return hour you can spend on this.
Five questions to put to your software vendor
Where is the data physically stored? "The cloud" is not an answer. You want a region. India-resident storage removes an entire category of cross-border complication.
Is personal data encrypted at the field level, or only in transit? Nearly every vendor encrypts in transit — that's table stakes and tells you nothing. Field-level encryption of personal data at rest is a meaningfully different posture.
How is our school's data separated from other schools'? On shared infrastructure this is the question that matters most. "Every query filters by school ID" means one missing filter in one code path exposes everyone. A separate database schema per school, with row-level security on top, means isolation is enforced by the database rather than by every developer remembering.
Who at your company can read our students' data, and is that access logged? Ask for the actual answer, not a policy document.
How do we get our data out, and in what format? Ask before signing. A vendor who has never been asked will not have a good answer, and that itself is information.
Consent and erasure need to be a process, not a promise
Parents have rights to access and correction, and in defined circumstances erasure. If honouring one of those requests means someone manually searching six systems, you don't have a process — you have an intention.
Decide now who owns such a request, what the response time is, and how it's recorded. Doing this before the first request arrives is the difference between a routine task and a scramble.
Hold less data, know where it lives, and make sure isolation between schools is enforced by the database rather than by every developer remembering a filter. Those three things cover most of the real risk.