Trust, safeguarding and privacy
Built for the trust schools and families place in us.
Safeguarding isn’t a feature on a list — it’s the design constraint that shapes every product decision. This page is the plain-English version. The detail is here too: how we protect young people, how we handle data, where it lives, and the documents your DPO will want to see.
How we protect young people
Identity, sign-in and the safeguarding flag.
The evidence pipeline
Moderation, EXIF strip, tenant scoping, audit.
Privacy and lawful basis
UK GDPR, Children’s Code, parents’ rights.
Data residency
Azure UK South. No US transfers without consent.
Access by role
Who sees what, and what they don’t.
Documents for schools
DPIA, data flow, sub-processors, certifications.
Our principles
Six commitments that drive every decision.
Under-13 as the default, not the edge case
Most of our users are under 13. Identity, consent and journeys are designed around that reality, not retrofitted.
Parent-mediated for under-13s
Children under 13 are not authentication subjects. Their record sits against a verified parent account.
Least-privilege by role
No cross-school visibility ever. Each role sees only what they need to do their job.
Single-use links for third parties
Coaches and instructors never hold an account. They sign off via a one-shot, short-lived link.
Evidence pipeline is separate from logging
Every photo passes through moderation, EXIF stripping and tenant scoping before it touches storage.
Tamper-evident audit trail
Every state-changing action — sign-ins, edits, approvals, sign-offs, uploads and exports — and every sensitive view (evidence access, DSL view-as) is recorded with actor and time. Entries are write-once at the application layer; storage-level immutability is on our roadmap.
How we protect young people
Designed around the under-13 reality.
The largest share of our users are children under 13. The identity model, sign-in journey and safeguarding flow are built for them from the start — not bolted onto an adult-shaped product.
- No standalone child accounts under 13 — there is no password for a child to share or lose
- Magic-link sign-in for parents and staff — single-use codes that expire in 15 minutes with a 5-attempt lockout
- Microsoft 365 / Google Workspace SSO with MFA for staff and 13+ pupils is on our roadmap
- Single-use third-party attestation links, expiring on use or after 14 days
- Any user can flag a submission; the DSL is notified instantly with a 24-hour SLA
- If the DSL hasn’t acknowledged a flag in 24 hours, it auto-escalates to the school site owner
The evidence pipeline
Every photo passes through four gates.
We treat photos and videos as the highest-sensitivity assets the platform handles. The pipeline is separate from the logging flow, so an unmoderated image can never reach storage.
Moderate
Server-side moderation via Azure AI Content Safety across Hate, Sexual, Violence and Self-harm categories. Severity ≥4 is blocked outright; 2–3 lands in a DSL manual-review queue. If moderation can’t reach the service, the upload fails closed to manual review — never an unscanned pass.
Strip
EXIF data — location, device metadata, embedded timestamps — is stripped before the image touches storage. Photos are resized to a sensible maximum edge.
Store
Storage is school-tenant scoped in Azure UK South. Access is via short-lived, HTTPS-only signed URLs that expire in minutes, not days.
Audit
A structured audit log entry is written on upload, view, share, edit and delete. Audit records are retained beyond the data they reference.
Privacy and lawful basis
Schools are the controller. We are the processor.
For pupil data, the school is the data controller — they decide the purpose and the means. We act as data processor under the school’s instructions. For operational accounts (school admins, billing contacts) we may be controller for limited admin data.
The lawful basis schools rely on for pupil processing is typically UK GDPR Article 6(1)(e) — public task, with special-category data avoided by design. We comply with the ICO Age Appropriate Design Code and align our safeguarding operating model to KCSIE.
- No advertising and no profiling — we do not sell or share data
- No tracking pixels, no cross-site analytics on child surfaces
- Subject-access and erasure requests fulfilled within statutory time
- Parents can request a full export of their child’s record
- Schools control retention overrides on top of the default
- Every export is signed, logged and watermarked
Data residency
Stays in the UK. Stays in one school.
Pupil data and evidence are stored and processed in Azure UK South — and so is transactional email, now delivered through Azure Communication Services. The only US-based sub-processor is Stripe for card payments, and that transfer is covered by the Standard Contractual Clauses and the UK International Data Transfer Addendum. Every record carries its school’s tenant identifier and our data layer refuses to read or write anything outside the calling school’s scope.
- Pupil data and evidence in Azure UK South
- Transactional email kept in the UK (Azure Communication Services)
- Only US sub-processor is Stripe (payments) — covered by SCCs + UK IDTA
- Per-school tenant scoping enforced at the data layer
- Default retention: child leaves school + 2 years
- School-level retention overrides supported
- Full sub-processor list at /trust/sub-processors
Access by role
Who sees what.
Every parent and teacher action funnels through an authorisation guard. Anyone trying to step outside their scope hits a refusal — no fallbacks, no exceptions.
| Role | Sees |
|---|---|
| Form teacher | Pupils in their own form group only |
| Parent | Their own child or children only |
| Student (13+) | Their own profile only |
| Third-party verifier | The single submission they were invited to sign — link expires on use or after 14 days |
| School admin | Aggregate dashboards and operational data — no access to evidence artefacts |
| DSL (safeguarding lead) | All flagged submissions; read-only access to the evidence on a flagged item |
| Site owner | Safeguarding escalation queue + same access as school admin |
Frameworks we build to
What we’re measured against.
UK GDPR + Data Protection Act 2018
The framework we build to. For pupil data the school is the data controller and we are the data processor, acting under the school’s instructions.
ICO Age Appropriate Design Code (Children’s Code)
We publish our self-assessment against all 15 standards of the Children’s Code.
Keeping Children Safe in Education (KCSIE)
Our safeguarding operating model — DSL view, 24-hour escalation, audit trail — aligns to KCSIE statutory guidance.
Documents for schools
Everything your DPO will ask for.
Sample DPIA
A school-fillable Data Protection Impact Assessment, pre-filled with the platform specifics.
Open the samplePrivacy notice
What we collect, why, where it lives, how long we keep it, and your rights — in plain English.
Read the noticeSub-processor list
Every sub-processor we use, what data they touch, and where it lives.
View the listData flow
How data moves between pupil device, our service, the school’s tenant and our sub-processors.
See the flowICO Children’s Code self-assessment
Our position against each of the 15 standards of the Age Appropriate Design Code.
Read the assessmentKCSIE alignment note
How our safeguarding model maps to Keeping Children Safe in Education.
Read the noteHave a question we haven’t answered?
Schools and parents: drop us a line. Safeguarding and privacy questions get a same-day response.
hello@stripesquest.com