Trust and security

What protects your pupils’ data, and what is not yet certified

This page is written for the SENCO, the data protection officer and the IT lead who have to approve a new supplier. It describes what is in place today, in specific terms, and says plainly where we are not yet certified.

Last reviewed 10 October 2026

In place today

Technical and organisational measures

  • One database, hard walls between schools

    Data is held in PostgreSQL hosted by Supabase. Every table that holds school data has row-level security policies, so a query from one school can only ever return that school’s rows. The rule is enforced in the database, not only in the application, and is covered by automated tests.

  • Encrypted in transit and at rest

    All connections use TLS, with HTTP Strict Transport Security preloaded. Data at rest is encrypted by the hosting provider. Uploaded documents go straight to private storage using a one-time signed URL scoped to the school; they do not pass through our servers on the way in.

  • School sign-in (SSO), two-factor authentication and sign-in protection

    Staff can sign in with their school Google or Microsoft account, and a school can switch passwords off entirely so leavers lose access when their school account closes; this is enforced in the database, not just the sign-in page. Any user can also enable TOTP two-factor authentication, required at every sign-in once enabled and mandatory for our own administrators. Repeated failed sign-ins are slowed per account and per address, and passwords follow NCSC guidance on length rather than arbitrary character rules.

  • 30-minute idle time-out

    A signed, server-checked activity cookie ends the session after 30 minutes without activity, so a laptop left open in a staffroom signs itself out.

  • Audit log

    Actions in the account are written to an audit log with who, what and when, including exports, AI drafts and deletion requests. Every notification email is recorded, with a dedupe key so a reminder is never sent twice.

  • Pseudonymised AI processing, off by default

    AI drafting is blocked for each pupil until the school records consent. Before any content leaves the system, the pupil’s name, date of birth, school name and named adults are replaced with placeholders. Prompts and outputs are not used to train models.

  • Hardened application

    A strict content security policy, frame-ancestors denied, cross-origin request checks on every mutating API call, rate limits on public forms and expensive operations, and no pupil names in URLs, email subjects or logs.

  • Your data, exportable and deletable

    Account owners can export the school’s entire dataset as JSON at any time and request deletion of a pupil record or the whole account from the app. Deletion is verified, logged and carried out after a seven-day cooling-off period.

Said plainly

What we are not yet certified for

What this means for your approval process

The DfE’s data protection in schools guidance and its third-party supplier standards ask schools to assess suppliers’ security and contractual terms. We make that easy to do without a certificate: the data processing agreement covers every Article 28(3) term, the sub-processor list names each provider with its purpose, and we answer security questionnaires. If your trust requires Cyber Essentials before onboarding, tell us; it affects how quickly we prioritise it.

Reporting a security concern

If you believe you have found a vulnerability or have seen data you should not have, email privacy@sendiphany.co.uk with as much detail as you can. We acknowledge reports within one working day, do not take action against good-faith researchers, and tell affected schools without undue delay as the DPA requires.

Where things live

Hosting and data flows

The short version of what happens to a record.

  1. Application: served by Vercel. Pages and API routes run on their infrastructure; no pupil data is written to application logs.
  2. Database and files: PostgreSQL, authentication and private file storage on Supabase, with row-level security per school.
  3. Email: reminders, form links and notifications sent through Resend. Subjects never contain a pupil’s name.
  4. AI drafting: pseudonymised evidence sent to Anthropic’s API only for pupils with recorded consent; drafts return for the SENCO’s review.
  5. Payments: handled by Stripe. Card details never touch Sendiphany.

Regions for each provider are stated on the sub-processors page where we can confirm them, and marked for confirmation in your DPA where we cannot.