Schools hold some of the most sensitive data any organisation handles: minors’ records, safeguarding notes, medical information, family financial circumstances, and in many cases immigration or custody details. The consequences of getting the handling wrong are not commercial. They land on children.
And yet the security conversation in most procurement processes consists of a vendor security page and a compliance logo, neither of which tells you much. I spent years in cybersecurity before building school software, and the questions that actually reveal how a system is built are rarely the ones on the form.
The most important one is where access control is enforced. Every product will tell you parents see only their own children. Ask where that rule lives. If it is enforced in the user interface — hiding buttons, filtering the list before rendering — then the rule exists in the client, and anyone who can construct a direct request to the underlying API can potentially bypass it. If it is enforced in the database, so that the query itself cannot return another family’s child regardless of what the application asks for, the guarantee is structural. This single distinction separates systems where a bug means a cosmetic glitch from systems where a bug means a data breach. Ask it directly, and be wary of an answer about "role-based permissions" that never mentions the database.
The second is what happens with a determined insider. Most breaches in schools are not sophisticated external attacks; they are an over-permissioned account, a shared login, or a departed member of staff whose access was never revoked. Ask how granular the roles are, whether administrative access can be scoped, whether every sensitive action is written to an audit trail, and whether that trail can be altered by the people it records. An audit log that administrators can edit is decoration.
The third is the subprocessor list — every third party that touches the data. Analytics, error monitoring, email delivery, SMS gateways, AI providers, backup storage. Each one is a place student data can end up. Ask for the list in writing, ask where each processes data geographically, and ask specifically what is sent to error monitoring, because that is the one that leaks by accident. A stack trace captured during a crash can contain a student’s name, and unless the vendor has deliberately configured scrubbing, it will sit in a monitoring dashboard indefinitely.
The fourth is AI-specific and increasingly the one that matters. If the product has AI features, ask three things: whether school data is used to train models, whether the provider retains prompts and for how long, and what stops the AI surfacing one school’s data to another. The third is the one that gets hand-waved. If the answer is that the model is instructed not to, that is not a control — it is a hope. The correct answer is that the AI operates under the same enforced permissions as the user, so the data is not retrievable in the first place.
The fifth is retention and deletion, which schools ask about least and need most. What happens to a student’s record after they leave? After the school leaves the platform? Can a specific record be deleted on request, and does the deletion propagate to backups, logs and analytics? "We keep backups for ninety days" is a real answer. Silence means nobody has thought about it, and the honest response to a future deletion request will be improvised.
The sixth is the boring operational one: how are credentials handled. Is multi-factor authentication available, and can it be enforced rather than merely offered? How is access revoked when someone leaves? Are there shared accounts anywhere in the recommended setup — a front-desk login, a shared teacher account for a lab? Every shared account is an audit trail that cannot identify who did something.
A note on compliance frameworks. GDPR, FERPA and their equivalents are floors, not guarantees, and a vendor can be technically compliant while being architecturally fragile. Compliance tells you certain documentation exists. It does not tell you whether the parent portal enforces isolation in the database or in the browser. Ask the architectural questions regardless of what certifications are on the page.
It is also worth being honest about the school’s own side of this. The most common student data exposure I encounter is not a vendor breach — it is a spreadsheet of student details emailed to a personal address, or a class WhatsApp group containing parents’ phone numbers visible to every other parent, or a shared drive with permissions nobody has reviewed since 2019. Vendor diligence matters, and it does not substitute for looking at how data moves inside your own building.
For transparency about our own architecture: Skoolia enforces tenant isolation with row-level security in Postgres, so every query is scoped to the organisation at the database layer rather than in the application; roles are enforced by the same mechanism; sensitive operations are written to an audit trail; multi-factor authentication is supported; and error monitoring is configured to scrub personal data before it leaves the application. Our security and compliance page sets out the detail, and I would rather you interrogate it than take it on trust.
Ask every vendor where the permission is enforced. The answer, and how readily it comes, tells you most of what you need to know.