Security & privacy
Security you can explain to a parent.
Schools hold some of the most sensitive data there is: children's. Schoolhouse is built so the safe thing is the default thing — and then tested, rather than merely promised.
How it's built
Nine things we do by default.
No checklists of buzzwords: each of these is how the product actually behaves.
Access is decided on the server
Every request is checked against the signed-in person's role and relationships — a parent sees their own children and nothing else; teachers see only what their role allows. Hiding things in the interface is never the control. That is why the rules hold for the web app, the phone apps and every integration.
Sessions you can see and end
Sign-in uses rotating refresh tokens with reuse detection: a stolen token that is replayed is noticed. People can see their signed-in devices and sign any of them out remotely. On phones, the token lives in the Keychain or Keystore — never in plain storage — with optional Face or fingerprint unlock. School administrators can review an audit log of sign-ins and account changes.
Uploads are checked by their contents
Files are typed by their bytes rather than trusting their names, capped at 5 MB, and SVGs — a common vector for script injection — are refused. Downloads are available only to the people in the conversation or the coursework they belong to.
ID cards that can be revoked
A card carries a signed code rather than a student's ID, so a lanyard is never a lasting key to a child's record. Printing new cards cancels the class's earlier ones, so a lost card simply stops working.
Documents can't carry code
Everything a person types into a certificate or ID card is escaped by the server before it reaches a printable page, so a name can never become code in a document that gets printed and handed to a child.
Payments that can't double up
Card details never touch the school's systems: paying opens your provider's own hosted checkout. Payment intents are idempotent, so a double-tap or a retry on a poor connection can never charge a family twice.
Notifications that respect people
Each person chooses their channels. Quiet hours hold non-urgent messages until morning instead of dropping them, and a delivery record shows what was sent, held or suppressed — and why. Emergency notices always get through.
A schema that is checked, not assumed
Versioned migrations own the database, and the API refuses to start against a schema it does not recognise. In production the server also refuses to start without real secrets, rather than falling back to development ones.
A contract for every response
Errors follow RFC 9457. Writes support idempotency keys and conflict detection. Response shapes are declared once and checked by the server, so drift between the server and the apps fails a test instead of reaching a phone.
Tested, not just asserted
Built to be checked.
A claim about security is only as good as the test behind it. Every release of Schoolhouse is held to these checks, and a failure stops the build.
- end-to-end checks
- 277
- unit tests over shared rules
- 32
- documented API operations
- 118
- screens accessibility-scanned
- 24
What’s still on our roadmap
We would rather tell you what isn’t built yet than have you find out later.
- Multi-factor sign-in and single sign-on (built to order for your identity provider)
- Row-level security in the database, as a second line of defence behind the server
- Object storage with malware scanning for uploaded files
- Audit-trail coverage beyond sign-ins and account changes — every grade edit, for example — with export
- Response contracts for every remaining API operation
Need one of these sooner? A custom engagement can prioritise them for your rollout.
Security questions
The questions IT teams actually ask.
Do you hold SOC 2 or ISO 27001 certification?
We don't claim certifications we don't hold. What we can show you today is how the product is built and tested, described on this page — and we'll gladly complete your security questionnaire or arrange a call with an engineer. Send a request through the contact page.
Where is our data stored?
In the region you choose. We can host in the cloud region your regulations require, or deploy to your own private cloud or on-premise servers as a custom arrangement.
Do you offer a data-processing agreement?
Yes. Data-processing agreements are available on request, and we can review your school's or your district's own template.
Is student data used for advertising or sold?
No. School data is used only to provide the service to that school.
How is the software tested?
Each release runs 277 end-to-end checks against a real database with response contracts enforced, 32 unit tests over the shared business rules, type-checks on the API, web app and phone app, automated accessibility scans across 24 screens for every role, and static analysis plus secret detection in continuous integration.
Have a security review to complete?
Send us your questionnaire or your district's requirements and we'll put you in touch with someone who can answer them properly.
Prefer email? aqbutt05@gmail.com