What to ask a vendor about your students' data

Behaviour records follow a child. A note entered in Year 2 can still be sitting in a system when that child is in Year 6, read by teachers who never met the child at seven years old and are forming a first impression from a record instead of a person. That persistence is normal and often useful — a pattern over years can matter for support planning — but it also means the question "where does this data live, and who controls it" deserves a real answer, not a line from a brochure.

This isn't a sales pitch for a particular product. It's a list of questions worth asking any vendor — including us — before behaviour data, messages, or other student records go into their system. For each one: why it matters, and what a good answer actually sounds like versus a red flag.

1. Where does our data physically live?

Why it matters. "In the cloud" tells you nothing. It could mean a server your trust controls, or it could mean one row among millions of students from hundreds of other schools, in a database you have no visibility into and no way to leave cleanly.

A good answer names a specific arrangement: your own infrastructure, a dedicated instance nobody else's data touches, or — if it's genuinely shared infrastructure — a clear, specific explanation of how your school's data is isolated from every other customer's. A red flag is a vendor who can't or won't describe the arrangement in concrete terms, or who answers a question about your data's location with a marketing paragraph about their infrastructure provider's general reputation.

2. Who, specifically, can read this data — and under what conditions?

Why it matters. Every vendor will say "your data is secure." That sentence is compatible with a support engineer being able to browse your students' records whenever they like, with no log of having done so.

A good answer distinguishes your staff's access (which should be scoped — a teacher sees their own class, not the whole school) from the vendor's own staff's access, and can tell you whether that second kind of access exists at all, and if it does, whether it's logged and auditable by you rather than only by them. A red flag is "our engineers have the access they need to support you," offered as a complete answer with no detail about scope, logging, or your ability to see when it happened.

3. Is the data encrypted at rest — and what does "encrypted" actually mean here?

Why it matters. "Encrypted at rest" is one of the most overloaded phrases in this industry. Whole-disk encryption is real, standard, and protects against exactly one thing: someone physically stealing the storage hardware. It does nothing once the database is running — anyone with ordinary database access sees plaintext.

A good answer distinguishes disk-level encryption from field-level encryption (specific sensitive columns encrypted by the application before they're written, so a database query alone can't read them) and tells you which one, if either, is actually in place. A red flag is "yes, it's encrypted," offered without any distinction, in response to this specific question.

4. If a laptop or backup with the database on it is lost or stolen, what does the thief actually get?

Why it matters. This is question 3 made concrete. The abstract answer and the practical answer are sometimes different things.

A good answer describes what's actually recoverable from a stolen disk or leaked backup in specific terms — ideally, "nothing usable, the sensitive fields are ciphertext and the key isn't stored with the data." A red flag is any hesitation, or an answer that quietly shifts to talking about network security instead of what happens once someone already has the file.

5. Is traffic encrypted between our browsers and your servers?

Why it matters. This is table stakes — HTTPS, not plain HTTP — but it's worth confirming rather than assuming, and worth asking whether it's enforced (a browser refuses to fall back to an unencrypted connection) or merely available.

A good answer is a confident yes with the specific mechanism (TLS, HSTS). A red flag is a vendor who hasn't heard of HSTS or treats the question as unusual.

6. If a parent asks us to delete their child's data, can we actually do it — and how long does "deleted" take?

Why it matters. Deleting a row from the live database is the easy part. The real question is backups, replicas, and every other copy the data made along the way. A vendor who can delete from the live system in five minutes but can't tell you what happens to last month's backup hasn't actually answered the question.

A good answer is specific about the mechanism — not just "we can delete it" but how, and what happens to backups and archives, and whether that process is something you can trigger and verify yourselves or something you have to request and trust happened. A red flag is "of course, just email support," with nothing about backups, timelines, or verification.

7. What's your data retention policy for a student who has left the school?

Why it matters. Data quietly accumulating for children no longer at the school is a common, boring, easily-overlooked risk — not a dramatic breach, just data outliving any legitimate reason to keep it.

A good answer states a concrete retention period and what happens at the end of it, automatically, without your school having to remember to ask. A red flag is "we retain it indefinitely unless you tell us otherwise" or no clear policy at all.

8. Is our school's data isolated from every other school's?

Why it matters. Shared infrastructure is not automatically unsafe, but it introduces a boundary — a line in software, not physics — that has to be correctly enforced by every query, forever, with no mistakes. A single bug in that boundary is a cross-school data leak.

A good answer either describes real physical or database-level isolation, or is honest and specific about how the shared-tenancy boundary is enforced and tested. A red flag is treating the question as irrelevant, or an answer that only addresses application-level access control (who can log in and see what) without addressing the underlying data storage.

9. What happens to our data if we want to leave, or if your company shuts down?

Why it matters. A multi-year commitment to a platform is also, quietly, a bet on that vendor's continued existence and continued willingness to hand your data back in a usable form.

A good answer describes a straightforward export in a standard, usable format, on a timeline you can rely on, with no punitive fees attached. A red flag is a contract silent on export, or an export process that turns out to be a support ticket that may or may not get answered.

10. Can you show us, not just tell us?

Why it matters. Every claim above is easy to say and harder to demonstrate. A vendor confident in their answers should be willing to show you the actual behaviour rather than just describe it.

A good answer is a live demonstration — a database query that shows ciphertext instead of a readable name, a support process you can watch happen, documentation that matches the product rather than a roadmap. A red flag is any version of "you'll have to take our word for it."

---

None of this is about finding a perfect vendor — there may not be one. It's about being able to tell the difference between a considered answer and a reassuring one, because with data like this, those aren't always the same thing.