A school MIS holds the most sensitive records an institution keeps: safeguarding concerns, medical needs, bursary circumstances, family breakdown. The question is not whether a vendor intends to keep them separate. It is what happens when the vendor writes a bug.
Application code decides what to ask for. Underneath it, the database decides what it is allowed to answer. Both have to agree before a row is returned.
A school is not a filter applied to a shared list — it is the boundary the data model is built around. Pupils, staff, records and files all belong to exactly one school, and there is no query in the product that legitimately spans two.
Row-level security in Postgres restricts every table to the school making the request. The application connects under a role that cannot bypass those rules, so a mistake in application code cannot return another school’s rows — the database refuses before the query returns.
The default is closed. A table that has not been explicitly scoped to a school is invisible to the tenant connection rather than accidentally readable, so the failure mode of a mistake is an empty result and a loud error, not a silent disclosure.
Staff see what their role allows. Safeguarding records are restricted to the designated safeguarding team, SEND documents to the people supporting that pupil, and finance to the bursary. Being a teacher does not make you an administrator.
A guardian account resolves to the children linked to it and nothing else — not the class list, not other families, not the roll. Parents are invited by the school; there is no public sign-up that could attach someone to a pupil.
Documents, medical letters, EHCPs and pupil media are stored under a per-school prefix, and a request for a file outside the requesting school’s own prefix is refused rather than served.
The common design for multi-tenant software is a shared database where every query filters by customer. It works right up until one query forgets, and then it returns somebody else's data with no error and no alarm. Putting the boundary in the database means the filter is not the thing protecting you — it is the second of two things, and the one that fails safe is underneath.
Traffic is encrypted in transit with TLS. Backups and stored files are encrypted at rest.
Access to safeguarding, SEND and finance records is logged with the user, the record and the time.
The database is backed up on a regular schedule, with restores tested rather than assumed.
Available for staff accounts, and can be required for the roles that hold the most sensitive records.
Staff roles grant the narrowest access that lets someone do their job, and are set by the school, not by us.
If a breach affects your data you are told, with what happened and what we did — not a status page.
Procurement will want this in writing. Ask during a demo and we will send the data processing agreement, our sub-processor list and answers to your own security questionnaire before you commit to anything.