What a school owes the families whose data it holds

A school holds names, addresses, photographs, phone numbers, medical notes, fee histories and academic records for hundreds of children. It is among the most sensitive datasets any small institution handles, and it is usually protected by a shared password on a computer in the front office.

India's Digital Personal Data Protection Act makes some of this explicit, and children's data carries additional obligations under it. But most of what follows is not really about compliance. It is about not being the school in the news.

This is a practical summary, not legal advice — for the specifics of your obligations, take proper advice.

The parts that cost nothing

**Individual accounts.** Every staff member has their own login. Nobody shares. This is the single highest-value change available and it costs nothing, because it is the only way any of the following works.

**Access by role.** The transport coordinator does not need medical notes. The accounts clerk does not need disciplinary records. Restrict by what the job requires, not by seniority.

**Remove access on the day someone leaves.** Make it part of the exit process, alongside collecting keys. Former staff with live accounts is the most common finding in any review.

**An audit trail.** Who viewed and who changed each record. It has to be designed in rather than added later, so ask for it when the system is being built. Its value is not catching wrongdoing so much as being able to answer a question when a parent asks one.

The parts that need a decision

**How long do you keep it?** A student leaves. Ten years later, why do you still have their medical notes and their sibling's phone number? Decide a retention period per record type, write it down, and act on it. Data you have deleted cannot leak.

**Where does it live?** If it is in a cloud service, know which one and in which country. If it is on a computer in the office, know what happens when that computer is stolen.

**Who else has it?** Every vendor — the ERP supplier, the SMS gateway, the photographer, the results portal — is holding your students' data. Each should have a written agreement covering what they may do with it, how long they keep it, and what happens when the contract ends.

**Consent for photographs.** Institutions publish student photographs constantly. Whether you have a defensible record of permission for each is worth checking before, not after, a parent objects.

The parts that need money, but not much

**Encryption in transit.** HTTPS on anything that touches student data. An SSL certificate is free.

**Backups, tested.** Regular, stored somewhere other than the same building, and restored once so you know it works.

**Password rules that do not backfire.** Long passwords, changed rarely, beat complex passwords changed monthly — the second policy produces sticky notes on monitors.

**Two-factor authentication on administrator accounts**, at minimum. Free on almost every platform.

**Patching.** Whoever maintains your systems should be applying updates. If nobody is, that is the gap.

When something goes wrong

Have a written plan before you need it, because the first hours matter and nobody thinks clearly in them.

1. **Contain it.** Disable the account, take the system off the network, stop the loss before investigating it.
2. **Establish what was actually exposed**, and for whom. Guessing publicly is worse than saying you are still establishing the facts.
3. **Notify.** Understand your obligations to the Data Protection Board and to affected families before you need them, and meet them.
4. **Tell parents plainly.** What happened, what was exposed, what you are doing. Institutions that communicate early and honestly recover; the ones that minimise it do not.
5. **Record what you changed** so it does not recur.

Questions to ask your software vendor

1. Does every user have their own account, and can access be restricted by role?
2. Is there an audit log of who viewed and changed records, and can I see it myself?
3. Where is the data hosted, and who else can access it?
4. What happens to our data if we end the contract — export format, deletion, timeline?
5. Who applies security updates, and how often?

A vendor who answers these clearly and in writing is telling you something useful about how the system was built. A vendor who finds the questions surprising is telling you something too.