Trust and compliance
Student Data Security for Schools: A DPDP Act Readiness Checklist
Most school data risk is not a hacker. It is a shared password, an unrevoked account, and a spreadsheet on a personal laptop. The DPDP Act now expects schools to take that seriously. Here is a plain-language readiness checklist for any institution that holds children’s data — whatever software it runs.
Most school data risk is not a hacker
The stories that make the news are about hackers. The risk inside most schools is quieter. It is the front-desk computer that four people share and nobody logs out of. It is the WhatsApp group where someone posted the admission list, phone numbers and all. It is the spreadsheet of student addresses on a teacher’s personal laptop, and the account of a clerk who left in March and could still log in come July. None of these needs an attacker. Each one only needs an ordinary day to go slightly wrong.
The Digital Personal Data Protection Act, 2023 gives this quiet risk a legal frame. Schools hold enormous amounts of personal data about children — the category the law protects most carefully — and institutions are now expected to protect it deliberately, not incidentally. But here is the framing that matters more than any clause: readiness is not something you purchase. Software can enforce rules about who sees what. Only the institution can decide what those rules are. The deciding comes first, and it costs nothing.
This post is the practical checklist we wish every school office had on the wall. What the Act actually asks of a school, in plain words. What ‘verifiable parental consent’ means at the admission desk. What to fix internally that has nothing to do with software. And what to ask any vendor — including us — in writing. An IT head who never buys anything from anyone should still find it worth printing.
What the DPDP Act asks of a school, in plain words
Under the Act, an organisation that decides why and how personal data is used is called a ‘data fiduciary’ — the party responsible for that data. A school that collects admission forms, stores marks, and manages fee records digitally is, in almost every practical reading, a data fiduciary. The person the data is about is the ‘data principal’ — your student, their parent, your staff member. And because most students are children, their parents or guardians exercise those rights on their behalf. That one fact shapes everything else a school does with data.
The obligations, described in general terms, are recognisable good practice. Collect data for a clear, stated purpose, and tell people that purpose in plain language. Keep it accurate. Protect it with reasonable security safeguards. If a breach happens, inform the affected people and the Data Protection Board of India — the body the Act creates to hear complaints and impose penalties. Erase data once its purpose is served, unless another law requires you to keep it. And honour requests to access, correct, and erase. Penalties for getting this wrong can be substantial; the specifics are a conversation for your counsel, not for a blog.
One honest caveat, and one plain note. The caveat: the rules that operationalise the Act are being brought into force in stages, so some details — including exactly how parental consent must be verified — are still being settled. Where this post cannot be specific, that is why. The note: this is practical guidance from people who build school software, not legal advice, and following it does not by itself make a school compliant. Take your own counsel for compliance decisions. The direction of the law, though, is already clear enough to act on today.
‘Verifiable parental consent’ starts at the admission desk
For a child’s data, the Act requires the verifiable consent of a parent or lawful guardian before processing. ‘Verifiable’ is the working word. It means the school should be able to show, later, that an actual parent agreed to an actual, stated use of their child’s data. A dense paragraph at the bottom of the admission form, signed once and filed forever, is the old way. It tells a parent almost nothing and proves very little.
The Act also bars tracking, behavioural monitoring, and targeted advertising directed at children. That clause is aimed less at schools than at the apps schools adopt — which makes it a school’s question anyway. A free app that pays for itself with children’s attention is not free, and every learning app, quiz platform, or photo-sharing tool you hand to students should be able to answer what it does with their data. While the verification mechanics settle, here is what a school can put in place now.
- Rewrite the consent section of your admission form in plain language a parent can actually read — and in the languages your parents actually speak.
- Make consent purpose-specific. Running fees and attendance is one purpose. Publishing a child’s photograph on the website or social media is another. Sharing data with an external partner is a third. Ask separately.
- Record who consented, to what, and when — on paper or in software. Consent you cannot show afterwards is barely consent at all.
- Give parents a genuine way to say no to the optional purposes without it affecting the essential ones.
- Before adopting any app for students, ask the vendor in writing whether it tracks children’s behaviour or shows them advertising. If the answer is fuzzy, so is the app.
Decide who is allowed to see what — before any software can help
The most useful security idea for a school has no software in it: least privilege, which simply means each person sees only what their job needs. The software version is role-based access control, or RBAC — permissions assigned by role, such as class teacher or accountant, rather than person by person. But RBAC can only enforce decisions that already exist. If nobody has decided whether a class teacher may see a sibling’s fee status, no product on earth knows the answer.
So make the decisions visible. Take one page. List your roles down the side — principal, accountant, front office, class teacher, transport coordinator, counsellor. List the data types across the top — contact details, fees, marks, attendance, health records, photographs. Then tick who may see what, and argue about the ticks. Does the transport coordinator need every student’s full address, or only the students on their routes? Does a part-time counsellor need the whole database, or their own caseload? The argument is the governance. The page is your access map.
Then enforce the map with whatever you already run. Shared drives can be permission-restricted. ERP roles can be configured to match the page. Revisit it whenever someone changes roles, because access accumulates — people gain permissions with every new duty and lose none when duties end. An access map reviewed regularly will do more for student data protection than most product purchases, and it makes every future vendor conversation sharper, because you can ask them to model your map instead of their defaults.
Fix these before you talk to any vendor
Most school data incidents will never involve a hacker. They involve an account that should have been closed, a chat group that should never have held a marks list, and a spreadsheet that walked out of the building on a personal laptop. Everything in this list costs nothing but attention and a little firmness. Do these before you evaluate any software — partly because they matter more than any feature, and partly because doing them will change what you ask vendors for.
None of this needs a budget line. It needs an owner — usually whoever manages IT, with the principal’s visible backing, because the hardest part of every item below is social, not technical. Somebody has to tell a senior colleague that the shared login is over, and that the fee-defaulter list is leaving the staff WhatsApp group. That conversation goes far better as policy than as confrontation, which is exactly why it belongs in a checklist the whole school has seen.
- End shared logins. A computer four people use under one account means nobody is accountable for anything done on it. Give every staff member their own account, even on the front-desk machine — especially on the front-desk machine.
- Revoke access the day someone leaves. Keep a leaver checklist: email, school software, shared drives, WhatsApp groups, and the keys to the records cupboard. An ex-employee with a live account is your single most preventable risk.
- Get student data out of WhatsApp. Marks lists, fee-defaulter lists, medical notes, and admission spreadsheets do not belong in group chats, because a group chat forwards forever and remembers everything. Use it for coordination, not for records.
- Stop exports to personal devices and drives. A spreadsheet on a personal laptop leaves the institution with the laptop. If staff need data at home, the answer is controlled access to the system, not a copy.
- Lock the paper too. Admission files, transfer certificates, and health records in an unlocked cupboard are a data breach that requires no computer at all.
- Switch on the basics everywhere: screen locks, software updates, a different password for every system, and two-step sign-in — a second check at login, such as a code on a phone — wherever it is offered.
What to ask every software vendor, in writing
Under the Act, work done on your behalf remains your responsibility. Handing student data to a software vendor does not hand over accountability: the school remains the data fiduciary, answerable for what the vendor does with the data. So put your questions in writing and keep the answers, because written answers survive audits, procurement cycles, and vendor staff changes. A vendor’s willingness to answer in writing tells you as much as the answers do — and these questions work on any vendor, ours included.
Two of these deserve a definition first. A data processing agreement is the contract that spells out what a vendor may and may not do with data it handles for you — ours is published as the data processing addendum at squarecampus.com/data-processing-addendum/, and any serious vendor should offer an equivalent. And ‘standard formats’ means files your next system can read, such as CSV or PDF, so that leaving a vendor never means losing your records.
- Where is our data hosted — which country, which region? Vague answers about ‘the cloud’ are not answers.
- Who at your company can access our data, and is that access logged?
- Is data encrypted in transit and at rest — scrambled while travelling over the network and while stored?
- Do you sign a data processing agreement, and will you share it before we commit?
- If a breach affects our data, will you inform us, and how quickly?
- Do you use student data for advertising, or to train AI models, without our explicit consent?
- If the product has an AI assistant, does it answer within the same role permissions as everything else, and are its queries logged?
- When we leave, what do we get and what do you delete? Exports in standard formats and a written deletion commitment — or it is not an exit, it is a hostage situation.
Make it a habit: one short review every term
Data protection is not a certificate you obtain once; it is a habit the institution keeps. The good news is that the habit is small. One hour, once a term, with the principal, the administrative head, and whoever manages IT in the room — that is the entire machinery. Put it on the calendar the way you schedule exams, because like exams, it only works if it actually happens. The agenda barely changes from term to term, and that is the point.
The review is not an audit, and it needs no consultant. It is the school asking itself the same few questions every term and writing down the answers — because the written trail is itself evidence of seriousness if a board member, a regulator, or an anxious parent ever asks how the school looks after its data. Five items cover most of it.
- Map where student data lives this term — systems, shared drives, cupboards, and personal phones. The map is always longer than anyone expects.
- Read the account list against the staff list. Disable anyone who has left, and trim anyone whose role has changed. This one check retires more risk than any purchase.
- Look at what you are still storing whose purpose has ended, and decide deliberately: some records must be retained under other laws, and the rest should be erased on purpose, not kept by default.
- Rehearse the bad day. If data leaked tomorrow, who calls whom, who informs parents, and who informs the Data Protection Board? Ten minutes of rehearsal beats a panicked evening.
- Re-read your vendors’ written answers and confirm they are still true. Vendors change infrastructure, ownership, and policies; your file should not quietly go stale.
Where software helps — and where the work stays yours
Software’s honest role in all of this is enforcement. Once the institution has decided who may see what, a well-built system applies that decision every hour of every day without getting tired: role-based access, an audit trail recording who changed what and when, encryption in transit and at rest, and exports in standard formats so your data is never trapped. That is the standard we hold SquareCampus to. It is built as a School Operating System — a governed operating layer for the institution — and it is designed to support DPDP Act obligations. We do not claim a compliance certificate, because no software purchase can make that claim true on its own.
On infrastructure, we publish what we run and stop there: hosted on AWS Mumbai (ap-south-1) with a multi-AZ design and an India-first residency posture, with optional Microsoft Entra ID single sign-on from the Pro plan so staff sign in under your institution’s own policies, and SquareCampus-managed credentials in every plan. Our AI layer, AEGIS, answers questions inside the same role permissions as the rest of the platform, grounded in your own records, with every query landing on the audit trail — read-only in its first version, and deliberately not autonomous. The details live on the security page at squarecampus.com/security/ and the infrastructure page at squarecampus.com/infrastructure/, and we answer security questionnaires in writing.
Two closing honesties. First, a SquareCampus deployment is bounded by design: it coexists with the ERP, payment portal, or identity provider you already run, which stay authoritative for their domains — consolidating tools is a later choice, if you ever make it, never a precondition. Second, and more important: no vendor can decide your access map, empty your WhatsApp groups, or revoke your leavers’ accounts. That work is the institution’s, it is mostly free, and it is where student data protection is actually won. Print the checklist. Walk the campus with it. Do that much, and every software decision you make afterwards gets easier.
Bring us your hardest security questions
Read how SquareCampus approaches access control, auditability, and hosting posture — then send us your security questionnaire. We answer in writing, because written answers are the ones that count.