Security built for schools, not bolted on.
Where your school's data lives, how it's protected and who can see it. Everything your DPO and IT team need on one page — and links to the underlying documents in your DPA file.
Three questions every DPO asks
Where does our data live?
On DigitalOcean's London region. Your database, your encrypted backups and your AI processing all happen inside the UK and the EEA. We are an English company — Muon Works Ltd, registered in England and Wales — and our infrastructure follows.
How is it protected?
Encrypted in transit with modern TLS and in storage with full-disk encryption. Identifying fields are additionally encrypted at the application layer. Tenant isolation is enforced by Postgres row-level security, not by application logic alone.
Who can see it?
Only people you grant access to. Single sign-on with Microsoft, Google, Apple or magic-link email. Multi-factor authentication on every admin account. An IP-restricted admin panel that returns 404 to anyone outside the allowlist.
The specific things, in plain English
Each item is verifiable. If your IT team or DPO wants the underlying detail, ask and we'll send the documentation.
TLS 1.2+ in transit
Every connection is encrypted with modern TLS. HTTP Strict Transport Security with preload, X-Content-Type-Options, X-Frame-Options DENY and a strict Content Security Policy with nonces.
Encrypted at rest
Full-disk encryption on every database and storage volume. Identifying fields — names, email addresses, free-text PII — are additionally encrypted at the application layer with Fernet (AES-128-CBC + HMAC) so even a database read won't disclose plaintext.
Tenant isolation by row-level security
Every multi-tenant table in our PostgreSQL database is governed by row-level security policies. Force-RLS prevents queries from reaching another school's data even if application code mis-routes them. Tenant context is set per request and audited in CI.
Multi-factor authentication
TOTP MFA is available for all administrator accounts and required in production. Suspicious-sign-in detection and rate-limited login. Sessions are HttpOnly, SameSite=Lax and Secure.
Single sign-on
Microsoft Entra ID, Google Workspace for Education, Apple ID and email magic links. Use your school's existing identity provider; access is revoked the moment your IT team disables the user upstream.
Admin panel IP allowlist
The Django admin is gated by an IP allowlist middleware. In production an empty allowlist means the admin returns a 404 — there is no fallback to a sign-in form, no surface to brute-force.
Role-based access
Org membership (owner / admin) governs administrative access; user-group membership (teacher / parent / student) governs chatbot visibility. The two paths are enforced server-side on every request, not just in the UI.
Audit logs for every action
Every dashboard action and every chatbot conversation is logged with user, timestamp, IP and tenant. Safeguarding alerts include the full transcript so your DSL has a complete picture without leaving Ask.School.
Continuous security testing
Every commit is scanned by CodeQL, a secret scanner (Gitleaks), dependency review and weekly security workflows. A pre-push hook runs the same gates locally before code can be pushed to main.
Built around the rules schools already follow
Ask.School is a UK service for UK schools. The compliance posture is shaped by UK law and statutory guidance for education — not by adapting a generic SaaS framework after the fact.
We're registered with the Information Commissioner's Office. We maintain a Data Protection Impact Assessment for the platform and update it when material features change. Your school is the controller for student, parent and staff data; we are the processor. The Data Processing Agreement is published in full and is the same one we sign with every school.
UK GDPR & DPA 2018
Full alignment with the UK regime. Lawful bases, retention, subject rights and breach notification all documented in the DPA.
KCSIE 2024
Online safety, filtering and monitoring obligations under Part 1 and Annex D are mapped onto specific Ask.School controls and surfaced on the Safeguarding hub.
DfE Generative AI guidance
Filtering, monitoring, oversight and clear AI identification are built in. Schools deploying Ask.School can demonstrate the safeguards DfE guidance asks for.
AI Product Safety Standards
The UK government's safety standards for education AI — safety by design, content filtering, age-appropriate safeguards and activity logging — are met across every requirement.
If the worst happens
Backups are not a marketing claim. They're a recurring scheduled job, an encryption key, a verification run, and a written runbook.
Daily encrypted backups
Every day at 02:00 UTC a full database snapshot is taken, encrypted with age using keys we hold separately, and stored in our EU region object store. Encryption happens before the snapshot leaves the database host.
Weekly verification
Every Sunday a separate job downloads the latest backup, decrypts it, and validates that it restores cleanly. A failed verification pages on-call before the next backup runs.
30-day retention
Backups are retained for thirty days, which is our DPA commitment. Older backups are deleted automatically; we'll never sit on data we don't need.
Written runbook
Restore-from-backup is documented step-by-step in our Disaster Recovery runbook. It's dry-run tested and updated whenever the infrastructure or schema changes.
The lines we won't cross
We never train AI on your school's data.
Your documents, your students' messages and your staff's conversations are not used to train Ask.School or any model. OpenAI does not retain API content beyond the request — it's in their API terms and ours.
We never sell or share data for marketing.
Personal data is processed only to deliver the Service, support safeguarding, run billing and meet legal obligations. There is no advertising surface and no data-sharing partnership we could put one on.
We never silently change sub-processors.
When we add or replace a sub-processor we update the public list at least 30 days before they touch personal data and we email the DPO contact at every school. If you object, we'll work with you on a resolution.
Responsible disclosure
If you believe you've discovered a security issue in Ask.School, please email [email protected] with the details. We acknowledge reports within one working day, work with you on a fix, and we won't pursue good-faith research that follows this policy. Please don't test on real school data — get in touch and we'll set up a sandbox.
Data protection questions go to [email protected]. Procurement and DPA questions go to [email protected].
Hand this page to your DPO. We'll handle the rest.
Start a free trial, share access with your data protection lead, and ask anything. We'll send the DPA, DPIA, sub-processor list and security questionnaire on request.
UK-hosted · UK GDPR · KCSIE-aligned · Wonde partner