School Data Processing Agreement (Article 28 UK GDPR) — TEMPLATE
THIS IS A TEMPLATE, NOT A SIGNED CONTRACT. It is a starting skeleton for the written agreement required by Article 28(3) UK GDPR between a school (as controller) and us (as processor) before that school's pupils are provisioned onto physmat.org. A qualified solicitor must draft and finalise the binding version of this template before it is offered to, or signed with, any school. Every clause below is subject to legal review; the markers flag the points most in need of counsel's judgement, but the whole instrument requires sign-off. No school's pupils may be provisioned until a signed Article 28 DPA is in place for that school (per-school gate — see B9).
This Agreement is intended to be read alongside our Privacy Policy (which sets out the controller/processor split — see its §1) and our Safeguarding Statement. Where this Agreement and the Privacy Policy describe the same processing, the Privacy Policy is the public-facing notice and this Agreement is the contractual instrument between the parties.
This Agreement is offered for schools in the United Kingdom. It is not offered in the United States at this time.
0. How this template is used
When a school adopts physmat.org and provisions pupils, the school is the controller of those pupils' personal data and we are the school's processor — we handle pupil data only on the school's documented instructions, never for our own purposes. This Agreement records that relationship as Article 28(3) UK GDPR requires. It is signed once per school, before that school's first pupil is provisioned.
1. Parties
- The School (Controller):to be confirmed, to be confirmed, to be confirmed ("the School", "the Controller").
- The Processor (us):to be confirmed, a company registered in England and Wales (company number to be confirmed), registered office to be confirmed ("the Processor", "we", "us"). ICO registration number to be confirmed.
Contacts for this Agreement:
- School data protection contact: to be confirmed.
- Our data protection contact: mail@physmat.org / Data Protection Officer to be confirmed.
2. Subject-matter, duration, nature and purpose of the processing
| Article 28(3) element | This Agreement |
|---|---|
| Subject-matter | The Processor's provision of the physmat.org platform to the School: storage, search and serving of maths-practice problems; grading and progress tracking; class management; and (where the School enables it) the optional, entitlement-gated AI tutor and the opt-in adaptive practice picker, in respect of pupils the School provisions. |
| Duration | For the term of the School's use of the platform, until termination under §11, after which §12 (deletion or return) applies. |
| Nature of the processing | Collection, storage, organisation, retrieval, use, transmission to authorised users (teachers/the School), and erasure/anonymisation of the personal data listed in §3, by automated means on cloud infrastructure (sub-processors in §6). |
| Purpose | Solely to deliver the learning service to the School and its pupils on the School's documented instructions (§4) — not for any independent purpose of the Processor. |
3. Types of personal data and categories of data subjects
Categories of data subjects:
- Pupils (students the School provisions) — children.
- Teachers / school staff the School registers to manage classes.
Types of personal data (pupils):
- Identity / account: email, display name (the person's name), date of birth, year group, parent email (where present), school association, role, and the consent record (how the account was created and when) —.
- Learning activity: the pupil's submitted answers and practice activity, correctness, timings, attempt index —.
- AI-tutor content (only where the School enables the tutor and the pupil uses it): the full text of the pupil's tutor messages and the tutor's responses, plus per-turn token/cost/latency metadata, stored append-only —. What is sent to the AI model is pseudonymous — see §7.
- Consent / authorisation records: append-only consent audit (
consent_log) and cross-account read grants — - Technical/security data: sign-in identifiers held by our identity provider and viewer IP used for rate-limiting —
Types of personal data (teachers/staff): email, display name, role, school association, and the same technical/security data.
Payment data: where a school is the payer, we store only Stripe identifiers and plan/status fields (payer/plan/status, seat→pupil links). Card details are never collected or stored by us — and §5.
Special-category data: the platform is not designed to collect special-category data, and the adaptive picker is not driven by special-category data.
4. Processing only on documented instructions
1. The Processor shall process the pupil personal data only on the documented instructions of the School, including as to transfers, unless required to do otherwise by law (in which case the Processor shall inform the School first, unless the law prohibits this).
2. This Agreement, together with our Privacy Policy, the platform's documented configuration, and any written instruction the School gives through the platform's admin functions, constitute the School's documented instructions.
3. The Processor shall immediately inform the School if, in its opinion, an instruction infringes UK GDPR or other data protection law.
4. For school-provisioned pupils, the Processor acts ONLY as processor on the School's instructions and makes no own-purpose use of the pupil data (no advertising, no profiling for our own purposes, no sale, no training of models on pupil content).
5. Confidentiality and security
1. Confidentiality. The Processor shall ensure that persons authorised to process the pupil personal data are bound by an appropriate duty of confidentiality.
2. Security measures (Article 32). The Processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, taking into account that the data concerns children. At the level the inventory evidences, these include role-based access control, sign-in tokens held in session storage cleared on tab close, append-only immutability for tutor transcripts and consent/audit records, and isolated credential storage. A complete, current statement of security measures is to be confirmed; this Agreement must annex an accurate measures schedule before signature. Do not treat the examples above as a guaranteed or exhaustive security specification.
3. The parties acknowledge that no system is perfectly secure and that the measures will be reviewed and updated.
6. Sub-processors
1. The School authorises the Processor's use of the sub-processors listed below. The Processor shall not engage a new sub-processor without the School's prior general authorisation, and shall give the School at least 30 days' notice of any intended addition or replacement so the School can object.
2. The Processor shall impose on each sub-processor, by written contract, the same data-protection obligations as in this Agreement (flow-down), and remains fully liable to the School for each sub-processor's performance. A signed Article 28 DPA with every sub-processor is a launch condition — no school's pupils are provisioned until each sub-processor DPA is on file.
Current sub-processors:
| Sub-processor | Service | What it processes |
|---|---|---|
| AWS Cognito | Identity / sign-in | sub, email, group membership |
| AWS Bedrock | AI-tutor model inference | Pseudonymous tutor input only (see §7); code-default region us-east-1 profiles, prod runtime may be eu-west-2 per the fix |
| AWS RDS (PostgreSQL) | Primary database | All personal data listed in §3 |
| AWS ECS | Compute | Processing in transit; no data at rest |
| AWS S3 | Object storage | Platform assets / data operations |
| AWS CloudFront | Content delivery (CDN) | SPA assets; viewer IP used for rate-limiting |
| AWS Secrets Manager | Secrets storage | API keys / secrets |
| AWS SSM | Configuration | Tutor configuration |
| Stripe | Payments / subscriptions | Stripe identifiers and subscription lifecycle; card data held only by Stripe, never by us |
| Anthropic | AI-tutor model (alternative API path) | Same pseudonymous tutor payload as Bedrock; API key in Secrets Manager |
7. International transfers
1. The tutor sends to the AI model only pseudonymous input — age label, difficulty band, problem text, and hint level — and no name, email, parent email, school id, or account id. It does not transmit pupil identity to the model.
2. Transfer posture depends on the production runtime configuration, not the code default. The code default targets global.* model profiles in us-east-1, but the production runtime was configured to an eu-west-2-confined profile under the fix. Whether any restricted international transfer occurs must be verified against the live runtime configuration before any statement is relied upon. — do not assert "no restricted transfer" without confirming the runtime inference-profile ARN.
3. Where any transfer of pupil data outside the UK does occur, it shall be made only on the basis of an adequacy regulation, an IDTA / Addendum to the EU SCCs, or another lawful Article 44–49 mechanism, and only on the School's documented instructions.
8. Assistance to the School
Taking into account the nature of the processing, the Processor shall assist the School:
1. Data-subject rights — to respond to requests by pupils (or those acting for them) to exercise rights of access, rectification, erasure, restriction, portability, objection, and withdrawal of consent. The platform supports deletion via account deletion, which removes the pupil's answers and assignments and anonymises identifying fields (name, email, parent email, date of birth) while preserving an immutable consent/audit record and non-identifying statistical fields, and removes identity from the sign-in provider.
2. Security, breach notification, DPIAs and prior consultation — to help the School meet its Article 32–36 obligations, including by providing information the School needs for its DPIA.
3. Personal-data breach. The Processor shall notify the School without undue delay and in any event within 72 hours of becoming aware of a personal-data breach affecting the pupil data, with the information the School needs to meet its own notification duties.
9. Retention and the honest limit on automated deletion
1. Pupil account data is retained while the account is active; on account deletion the soft-delete + anonymisation in §8.1 applies.
2. Tutor conversations/sessions, access logs and quota aggregates are intended to be retained for 6 months and then deleted on a rolling basis. We are implementing the automated deletion that enforces this.
3. Backups are retained for to be confirmed and then expire. to be confirmed
10. Audits
The Processor shall make available to the School all information necessary to demonstrate compliance with Article 28, and allow for and contribute to audits, including inspections, conducted by the School or an auditor it mandates.
11. Term and termination
This Agreement runs for the term of the School's use of the platform and terminates on the earlier of the School ceasing to use the platform or termination of the underlying service terms.
12. Deletion or return of pupil data on termination
On termination, at the School's choice, the Processor shall delete or return all pupil personal data and delete existing copies, unless retention is required by law. Deletion follows the model in §8.1/§9 (anonymisation of identifying fields with an immutable consent/audit record preserved, and removal of identity from the sign-in provider).
13. Safeguarding interplay (KCSIE)
The School retains its statutory safeguarding duties, including under Keeping Children Safe in Education (KCSIE). Where the AI tutor is enabled, our commitment is that a pupil's disclosure of harm typed into the tutor will be routed to a responsible person and not silently dropped. We are building the in-system detection and automated escalation path — consistent with the Safeguarding Statement §4, which sets out how such matters are intended to be escalated and to whom.
14. General
1. Relationship with other terms. This Agreement governs the Article 28 processing relationship and is read with the service terms and the Privacy Policy; in case of conflict on data-protection matters concerning pupil data,.
2. Governing law: the law of England and Wales.
3. No legal advice / template status. This document is a template and does not itself constitute a binding agreement or legal advice. The binding version must be drafted and finalised by a qualified solicitor before signature.
15. Signatures
to be confirmed
- For the School (Controller): name / role / signature / date — to be confirmed.
- For the Processor (us): name / role / signature / date — to be confirmed.