Written for the person who has to answer this question to a parent. Everything below is a property of the software you can hold us to — and further down, plainly, the things we do not have.
Who holds your data, and who decides what happens to it
Your school decides what is collected about its pupils, who may see it, and when it is deleted. ClassHaven holds and handles that data on the school's instructions and only for the purposes the school sets — we are the school's supplier, not a party with its own interest in the data.
Each school's data is separate. There is no shared roster, no cross-school directory, and no pooling of pupil records.
We do not sell personal data, and we do not use pupil data for advertising.
No data is used to train any AI or machine-learning model — ours or anyone else's.
One school cannot see another school's data
This is enforced by the database, not by the application. Every table holding school or family data — 69 of them — has Postgres row-level security switched on and forced, with a restrictive isolation policy that no other rule can widen.
All access runs through a single chokepoint that pins the school on every statement. A query that skips it returns zero rows rather than everything — the failure mode is silence, not a leak.
More than six hundred database-level tests run against a real Postgres instance on every proposed change — connecting as the restricted application role, so the policies are genuinely exercised rather than merely present. A change cannot merge until they pass.
A build-time lint fails if anyone adds a table holding school data without isolation, so the protection cannot quietly erode as the product grows.
Row-level security only binds if the running application signs in to the database as a restricted role. That is a property of a deployment rather than of the code, so we check it rather than assume it: production was confirmed enforcing on 20 August 2026, the proof being behavioural — a query with no school context returns nothing.
Every staff account carries a second factor
Not just owners, and not just administrators. Owner, admin, staff and instructor accounts alike must enrol an authenticator app, and the staff portal stays out of reach until they do.
There is no per-role exemption, no recovery-code escape hatch, and no configuration switch to turn it off.
Resetting a password does not clear the authenticator, so a compromised mailbox on its own is not enough to reach a school's records.
Families are not forced into this — it applies to the people who can see many children's records, which is where the risk actually sits.
We cannot read what families and schools say to each other
When we help a school with a support session, that session is read-only at the database level — not a setting we promise to respect, but a property of the connection itself. Message bodies never reach us.
The text of a message is replaced with a placeholder before it leaves the database, so our support tools show that a conversation happened, never what was said.
The activity log records who messaged whom and when, and deliberately never stores the message text — closing the obvious side channel.
Support sessions expire after twenty minutes, and opening a child's profile or a family's message thread during one writes a row to an append-only log the operator cannot edit or delete.
Platform-level 'messages' means us talking to a school owner, or a prospective customer contacting us. It has never meant family conversations.
The school runs its own data requests — not us
If a parent asks a school for a copy of their child's data, or asks for it to be deleted, the school's owner or admin does it themselves from the pupil's record. No ticket to us, no waiting on our schedule.
Export produces a machine-readable file covering every record we hold that is linked to that pupil — their classes, attendance, assessments, exams, gradings, certificates, lesson notes, equipment loans, invoices and more. A build-time check fails if a new kind of pupil record is added without deciding whether it belongs in the export.
Erasure takes effect at once: the record and every guardian's access to it disappear from every view, and the action is written to the school's audit log.
Today this is staff-mediated by design — a parent asks the school, and the school acts. Direct self-service for guardians is not built yet.
What we deliberately do not collect
The cheapest way to protect sensitive data is not to hold it. Several categories were designed out of the product rather than secured within it.
No medical records, allergy information, or special educational needs data. Not stored anywhere, by an explicit product decision.
Birth year only, never a full date of birth — enough to place a child in the right class, less than an identity document needs.
Passwords are hashed, never stored in readable form. So are check-in PINs, invitations, connection codes and kiosk tokens.
Password-reset links are stored only as a hash, expire after an hour, and work exactly once.
Who else touches the data
A short list, and a shorter one of the things we deliberately do not use. Every entry here is a company that can, in the course of running the service, hold or transmit school data.
Neon — the database, hosted in the United States (AWS us-east-1).
Vercel — the application itself, pinned to the same US East region so data stays next to the database.
Resend — transactional email, such as an invitation or a password reset.
Sentry — error reports only. Personal information is stripped before an error leaves the server, there is no browser tracking, no performance tracing and no session recording.
Your browser's own push service, if a family turns on notifications.
No payment processor, no analytics vendor, no session-replay tool, and no AI or large-language-model service. The public site sets no advertising or tracking cookies; the cookies we do set are there to keep you signed in and to remember interface preferences.
How the connection itself is protected
The application ships with a strict set of browser-level protections, and they are covered by tests so they cannot be quietly dropped.
HTTPS is enforced for the site and every subdomain, and connections to the database are encrypted in transit.
A content-security policy is generated fresh for each request, so injected scripts do not run.
The site cannot be embedded in a frame by another page, browsers are told not to guess file types, and camera, microphone and location access are switched off outright.
Reporting a security problem
If you believe you have found a vulnerability, please report it privately rather than opening a public issue, and give us enough detail to reproduce it.
We aim to acknowledge a report within 7 days and give a status update within 14, on a best-effort basis.
Please do not publish exploit details before a fix ships, and please do not include real user data in a report.
What we don’t claim
Most vendor security pages list only what they have. If you are comparing us with a larger vendor, you would reasonably assume some of the following — and letting you assume it would be the same as claiming it.
We have no SOC 2 report. We are a small team and have not been through that audit.
We have not had a third-party penetration test.
We run no bug-bounty programme — see the disclosure policy above.
We hold no ISO 27001 certification.
Data is hosted in the United States. A dedicated EU-region option is designed but not yet available, so do not plan around it.
Guardians cannot yet export or delete their own data directly; requests go through the school.
We do not publish an uptime or recovery-time guarantee, because we are not yet in a position to stand behind one.
Ask us for the paperwork
We would rather send you a document we have checked than publish a template we haven’t. Tell us what your school needs and we will send it.
Our data-processing agreement, including the technical and organisational measures annex.
Our privacy policy and data-retention schedule.
A written answer to a security questionnaire, if your school or diocese requires one.
