Where your school's data actually lives

A school management platform holds the most sensitive dataset a school will ever assemble: names, ages, home addresses, guardian relationships, health notes, academic performance and payment history for hundreds of children. It deserves harder questions than it usually gets.

Here is the list we would want a school to put to us — and to everyone else they are evaluating.

1. Which country is the data stored in?

Not "the cloud". A country, and ideally a named region. This determines which laws apply, who can compel disclosure, and whether you are compliant with your own ministry's requirements. If a vendor cannot answer this in one sentence, that is your answer.

2. Can it be hosted on infrastructure we control?

Some schools are contractually or politically required to keep student data on their own servers. A platform that only exists as a shared multi-tenant service cannot meet that requirement, no matter how good it is. Ask early — it is an architecture question, not a pricing one.

3. What happens to the data if we leave?

Ask for the specifics: what formats, how quickly, at what cost, and how long the vendor retains a copy afterwards. "You can export to CSV" is not an exit plan if the export omits attachments, historic grades or the relationships between records.

4. Who inside the vendor can see student records?

Support engineers usually need some access to diagnose problems. The right answer is not "nobody" — it is that access is role-limited, logged, time-bound and auditable, and that you can be shown the log.

5. Is every action attributable?

If a grade changes, a fee is waived or a record is deleted, you should be able to see who did it and when. This protects the school far more than it protects the vendor. It is also the difference between "we think it was an error" and "we know exactly what happened".

6. How are parent accounts verified?

Parent portals are the softest attack surface in any school system, because they are the only accounts held by people the school does not control. Ask how a parent account is created, how the link to a child is established and verified, and what happens when a custody arrangement changes. That last one is not a hypothetical; it comes up in every school eventually.

7. What is the backup and restore story — tested when?

Everyone has backups. Far fewer have a documented, rehearsed restore. Ask when the last restore test was performed and what the measured recovery time was. A backup nobody has restored is a hypothesis.

8. Is the data model documented?

You do not need to read it, but its existence tells you something. A vendor who can hand over an entity model is a vendor whose system has a shape. One who cannot usually has a database that grew rather than one that was designed — and that will show up later as the reason a report cannot be produced.

9. What runs on someone else's servers?

Email delivery, SMS, video for live classes, payment processing, analytics — most platforms depend on third parties for at least some of these. That is normal and fine. What is not fine is finding out after signing that lesson recordings sit with a vendor you have never heard of, in a jurisdiction you did not choose.

---

None of these questions are hostile. A vendor who welcomes them is telling you something useful about how they have built the thing, and a vendor who deflects is telling you something even more useful.

For what it is worth: our own answers are on the security page, including the parts that are limitations rather than features.