Security

One school cannot reach another’s data

Every record carries the school and campus it belongs to, and those two predicates are injected by the data-access layer rather than written by hand in each query. A screen cannot forget to scope itself, because a screen never issues an unscoped query in the first place.

Sessions are bound to a single school. A token issued for one school is rejected against another, so a shared browser or a copied cookie does not become a route between customers.

Permissions narrow, never widen

• Roles are bound to the invitation, not chosen by the person accepting it. Nobody grants themselves privileges.
• Admins cannot create admins above themselves. A campus administrator can only invite within their own campus, and only at or below their own level.
• Administrators cannot reset each other’s passwords, so one admin account cannot be seized by a peer.
• Plan limits are enforced at the API, not by hiding menu items. A module your school does not have cannot be reached by calling the endpoint directly.

Credentials

• Passwords are hashed with PBKDF2 and never stored or logged in readable form.
• Time-based multi-factor authentication is supported at sign-in.
• Invitation and password-reset links last one hour and work once. A link found later in an inbox is already dead. Resending is the recovery path.
• An administrator-issued password reset forces the user to set their own password at next sign-in, so the administrator never durably knows a live credential. It is never written to a log, an audit row or an email.
• All traffic is HTTPS. The product domain sits on a TLD with HSTS preloaded into browsers, so the encryption is enforced by the browser before a request is made.

Sensitive pupil data is structurally separated

Medical conditions, allergies, medication and safeguarding notes are held apart from the main pupil record, shown only to roles the school has explicitly permitted, and excluded from published documents by design — a report card carries no medical and no financial information, and says so in its own footer.

That is a schema decision, not a display rule. There is no report-card template that could accidentally include it.

An audit log nobody can edit

Who changed what, when, and in which campus — retained for seven years, with no update or delete path in the code. A school administrator cannot shorten it or erase an entry. An audit trail the audited party can edit is not an audit trail.

Support access to a school’s account is recorded in it too.

Financial writes are serialised

Payments run through a single-threaded writer per campus, so concurrent requests cannot produce two receipts with the same number or double-post a payment.

• Receipt numbering is gapless; a voided receipt stays in sequence, marked void.
• Payments are reversed, never deleted — a compensating entry with a mandatory reason.
• Duplicate payments are detected before the ledger is written.

These are accounting-integrity properties, and they are the reason a school can hand the receipts register to an auditor.

Infrastructure

The service runs on Cloudflare — Workers for compute, D1 for the database with its primary region in Western Europe, and R2 for file storage. Transactional email is delivered through Postmark. The full list, including what data reaches each provider, is on the sub-processors page.

Cloudflare provides DDoS protection and edge TLS termination. We inherit their physical and network controls; we do not inherit application security, which is the part described above.

What we have not done

A security page that only lists strengths is marketing. These are the real gaps:

• No third-party audit or certification. No SOC 2, no ISO 27001, no independent penetration test.
• No formal incident response exercise. The notification commitment in the DPA is real, but it has not been rehearsed.
• No published uptime monitoring. See status.
• Single-sign-on and enterprise SAML are not yet live. MFA is available; SSO is not.
• Backup restores are not yet routinely tested. Backups exist through the database provider; a documented, rehearsed restore does not.

Reporting a vulnerability

Email ▲Security contact address — to be supplied. Give us reasonable time to fix an issue before disclosing it, stay within the bounds in the acceptable use policy, and we will acknowledge your report and keep you updated. Good-faith research within those bounds will not be treated as a breach of our terms.