Data Protection Impact Assessment
Pack for schools · Version 1.1 · 10 September 2026
What changed in version 1.1. Schools on an organisation plan can now give pupils their own sign-in, so that work can be set to a class and handed back to the pupil who did it. That adds a username, a hashed password and a record of what each pupil was set to what we process, and it means the pupil pages now set one strictly necessary session cookie. Sections 2, 6 and 7 have been rewritten accordingly, and risks 10 to 12 are new. Nothing changed for schools that do not use pupil accounts: without them the service behaves exactly as it did in version 1.0.
Article 35 puts the DPIA duty on the controller – for student information, that is your school. This pack answers, in advance, every question in one that is about our service rather than about yours. Copy it into your own template and check our answers against how your staff actually intend to use the service.
Sections we have completed: 1, 2, 4, 5, 6 and 7 – the nature of the processing, necessity and proportionality, the risks arising from our service and the measures we take against them.
Sections only you can complete: 3 (who you consulted), 8 (risks arising from how your school uses it) and 9 (sign-off). We have left prompts in each.
Download this pack for Word to fill in and adapt, or work from the page below.
1. Why a DPIA is needed
On the ICO’s criteria, this processing is likely to require a DPIA. Two of the ICO’s screening criteria apply:
- Vulnerable data subjects. The people whose information is processed are children.
- Innovative technology. Student answers are marked by a large language model.
Neither the volume nor the sensitivity is at the extreme end – the service holds a first name and a piece of schoolwork, not health, safeguarding or biometric data – but two criteria is the usual threshold, and children plus AI is a combination the ICO expects to see assessed. We would recommend completing one even if your own screening came out marginal.
2. Describing the processing
Nature
Teachers use BA Productivity to generate teaching material, to set quizzes and lessons, and to mark student work. Student information enters the service in five ways: a student types a name and answers into a quiz link; a pupil types a name and works through a lesson; a teacher builds a class roster; a teacher types, pastes or photographs student answers for marking; or – on an organisation plan only – a teacher creates pupil sign-ins, and the pupil signs in and does the work as themselves.
Pupil sign-ins are optional and organisation-only. They exist because a school that wants work set to a named class and marks handed back to the pupil who did it cannot get there by asking children to type their names, which is a guess a person then has to resolve. A school that does not want pupil accounts does not have them, and every other route into the service is unchanged: no account is needed to answer a quiz link or a lesson code, and that remains the only way in outside an organisation.
We are the processor and your school is the controller. The written contract required by Article 28 is our Data Processing Terms, which take effect when your staff accept our Terms & Conditions.
Scope
| Personal data processed | The name a student types or a teacher enters; quiz answers; drawn answers saved as images;
lesson answers; answer text typed, pasted or uploaded for marking; the marks and written
feedback produced; the time of each submission or attempt.
Where a school uses pupil sign-ins: a generated username (built from the pupil’s name, e.g. a.clarke-4k2); a password, stored only as a bcrypt hash
and never in readable form; the pupil’s display name; the time they last signed in;
which class or classes they are in; and, for each piece of work set to them, whether they have
opened it, handed it in, and what they scored. |
| Not processed | No date of birth, no contact details, no address, no photograph of a child’s face, no
health, SEN or safeguarding information, no biometric data. Photographs of handwritten work are
transcribed and then discarded – the image is not stored.
Pupil sign-ins hold no email address, and that is a design decision rather than an omission: most pupils have no school address, an account with one is an account that can be contacted and recovered by email, and neither is something this feature needs. It follows that we never contact a pupil, and that a forgotten password is reset by the teacher in the room rather than by a link sent to a child. |
| Special category data | None required. Our terms instruct teachers not to enter it. See risk 3 below. |
| Volume | Determined by your own use – typically one row per student per quiz, lesson or marked answer. |
| Retention | Held while the teacher keeps the quiz, lesson, marking set or roster entry. Deleted immediately
when they delete it, and deleted with the account when an account is closed. Backups are kept
two days, so a deletion clears backups within 48 hours.
Pupil sign-ins last as long as the school keeps them. Deleting a class deletes the sign-ins of the pupils who were only in that class; closing the school’s account deletes every pupil sign-in in it. Work already handed in is deliberately kept when a sign-in is deleted, so that deleting a leaver’s login does not erase the class’s record of a term’s marking – if you need the work gone too, delete the work. |
| Geography | Stored at rest only in the UK or EEA. Marking and transcription are processed in the United States. Nothing student-related goes to our generation provider in China. |
Context
The children are pupils at your school; the relationship is an educational one, and they would reasonably expect their work to be marked and their teacher to see it. They would not expect it to be used to build a profile of them, to advertise to them, or to train an AI model – and none of those happens. Children have limited ability to exercise their own rights here, which is why requests come to you as controller and why we have kept what we hold to the minimum that makes the feature work.
The student-facing pages are deliberately the plainest part of the service: no analytics, no advertising pixel, no tracking of any kind, and nothing to configure. Where a school uses pupil sign-ins, those pages set one cookie – the session that keeps a pupil signed in while they work – and nothing else. Quiz links and lesson codes still set no cookie at all.
Purposes
To provide the service to the teacher: marking work, showing a class’s results, and keeping the record the teacher chose to keep. We do not use student information for our own purposes, do not sell it, do not profile students, and do not train any model on it.
3. Consultation – for your school to complete
Article 35(9) asks you to seek the views of data subjects or their representatives where appropriate. Schools typically record here:
- Discussion with the staff who will use the service, and what they said about workload and marking quality.
- Your DPO’s advice, which Article 35(2) requires you to seek.
- Whether you informed parents, and how – usually a line in the school privacy notice covering educational technology rather than a separate notice.
- Any pupil voice or governor input, if that is your practice.
We cannot complete this section. If it would help, we are willing to join a call with your DPO.
4. Necessity and proportionality
Lawful basis
The lawful basis is yours to determine, and for a maintained school it is normally Article 6(1)(e), the performance of a task carried out in the public interest – the provision of education. Academies and independent schools more often rely on Article 6(1)(e) or 6(1)(f) depending on their constitution. We do not rely on consent from children for this processing, and we do not ask you to obtain it.
Is the processing necessary to achieve the purpose?
Marking and feedback are core educational activities. The question the DPIA should record is whether doing them this way is proportionate. The relevant points on our side:
- Minimisation by design. The service asks a student for a name and an answer, nothing more. It has no field for a date of birth, a class list identifier, or contact details.
- Names are not sent for marking. What leaves our systems is the question and the answer. The link between an answer and a named student stays in our database, so the AI provider receives work it cannot attribute to a child.
- Photographs are not retained. An uploaded image is transcribed, the teacher is shown the text to correct, and the image is discarded rather than stored.
- No profiling and no secondary use. Student information is used only to produce the marks and show the teacher the results.
- Pseudonymity is available. Nothing in the service requires a real name. A school that wants to reduce the risk further can ask pupils to enter initials or a candidate number, and the features still work; the roster is what maps them back, and it stays with the teacher.
International transfers
Answers are marked in the United States by CoreWeave, or Baseten as fallback, reached through OpenRouter. Photographs of handwritten work are transcribed by Anthropic, contracted through its Irish entity. Each transfer is covered by the EU Standard Contractual Clauses together with the UK International Data Transfer Addendum. Every marking request is restricted to a fixed list of assessed providers and carries a setting that excludes any provider that stores or trains on what it receives, so the set of companies that can see a marked answer is fixed by us in advance rather than chosen at the moment of the request. Full detail is in section 5 of our Privacy Policy.
Data subject rights
Rights requests come to you as controller. A teacher can satisfy most of them directly: deleting a quiz, lesson, marking set or roster entry deletes the student information in it immediately. If a request reaches us we pass it to you rather than answering it ourselves. Our assistance duty is at section 8 of the Data Processing Terms.
Where pupil sign-ins are in use, erasure of a single pupil is not yet a one-click action in the interface: deleting a class deletes the sign-ins of the pupils only in that class, and a single pupil’s account and work can be erased on request to [email protected], which we action within the statutory month. We are building the self-service equivalent; until it ships, treat that address as the route for a pupil erasure request.
5. Automated decision-making and marking accuracy
DPOs ask about Article 22 here, so we will answer it directly.
There is no decision based solely on automated processing. The service produces suggested marks and written feedback. A teacher sees them, can change them, and remains the person who decides what a piece of work is worth and what goes in a report. The marks are an input to a professional judgment, not a substitute for one. On that basis Article 22 is not engaged, and no explicit consent or Article 22(2) condition is needed.
That conclusion depends on your staff actually working that way. If a school were to pass AI-generated marks into a report or a setting decision without a teacher reviewing them, the position would change and Article 22 would need revisiting. We would recommend recording in section 8 that teacher review is expected practice.
Accuracy. Language models can mark inconsistently, and can misread handwriting. The mitigations built in: transcriptions are shown to the teacher to correct before anything is marked; marking runs against the mark scheme the teacher supplies rather than the model’s own opinion of the question; and every mark is editable. Article 5(1)(d) accuracy is best served here by the teacher review step, which is why it is not optional in the interface.
6. Children’s Code conformance
The Age Appropriate Design Code under section 123 of the Data Protection Act 2018 applies to services likely to be accessed by children. Our student-facing pages were built to it. Against the standards most often asked about:
- Data minimisation. A name and an answer. Where a school uses pupil sign-ins, a username, a hashed password and the record of what that pupil was set – and nothing beyond it. No email address, no date of birth, no year group held against the child, no device information.
- Default settings. Nothing to configure – the private option is the only option.
- Profiling. Off entirely. No student profile is built, and there is no cross-session tracking of a child.
- Nudge techniques. None. There are no streaks, no rewards, no notifications and no mechanism designed to extend engagement.
- Cookies and tracking. The student quiz and lesson pages set no cookies at all. The pupil sign-in pages set one strictly necessary session cookie, which is what keeps a child signed in between pages and is deleted when they sign out; it is not used to track anyone and carries nothing but the session. No student page loads analytics or our advertising pixel, and that is enforced in the code rather than by configuration.
- Third-party sharing. Only the marking providers described above, under contract, with no training and no retention, and without the student’s name.
- Detrimental use. Student information is not used for marketing, and never to the child’s detriment.
- Transparency. Because we never speak to students directly, age-appropriate explanation has to come from the school. We are happy to supply plain-language wording you can put in front of pupils. If you issue pupil sign-ins, this is worth doing at the point you hand out the passwords: a child should be told what their teacher can see, which is their work, their marks and when they signed in.
- Children’s own accounts. Where they exist, a pupil sign-in gives a child access to their own work and nothing else – there is no way to reach another pupil’s work, no messaging, no profile, no friends, no public presence and nothing shared with anyone but their teachers. A mark stays hidden from the pupil until their teacher hands it back.
7. Risks and measures
Risk ratings assume the measures described are in place. “Residual” is our assessment of what remains; your DPO may rate them differently for your context.
| Risk | Measures | Residual |
|---|---|---|
| 1. Children’s work is processed by AI providers outside the UK | SCCs plus UK IDTA for every transfer. Providers fixed in advance by an allowlist, with storage and training contractually excluded and enforced per request. Names never sent with answers. Nothing stored at rest outside the UK or EEA. | Low |
| 2. An answer identifies its author even without a name | Free-text work can be self-identifying (“my brother James…”). Providers do not retain what they receive and cannot link it to a pupil record. Teachers are asked to keep entries to the work itself. | Low–medium |
| 3. A teacher enters SEN, health or safeguarding information | The service never asks for it. Our Terms and Privacy Policy instruct against it in terms. No feature requires it. Nothing currently prevents it technically, so this depends on staff practice – worth covering in your staff guidance. | Medium |
| 4. A pupil opens another pupil’s answers | Each attempt is bound to the browser that began it by a secret issued at the time. Typing someone else’s name on another device starts a fresh attempt rather than opening theirs. Lesson answer keys are never sent to the pupil’s browser. | Low |
| 5. Student work is kept longer than needed | Teachers can delete at any time, and deletion is immediate and complete. There is no automatic maximum retention, so the effective period is set by your own retention policy and staff habits. | Medium |
| 6. Student information is exposed through sharing features | Marketplace and organisation library publishing is opt-in per item and intended for teaching material. Both the Terms and the Privacy Policy warn never to publish anything containing student information. Copies already taken persist if a listing is withdrawn. | Low, if staff are briefed |
| 7. AI marks are wrong or inconsistent | Teacher review before and after: transcriptions are corrected by the teacher, marking runs against the teacher’s own mark scheme, and every mark is editable. Not solely automated – see section 5. | Low, with teacher review |
| 8. Personal data breach | Encryption in transit, bcrypt password hashing, rate-limited authentication, per-attempt secrets, sanitised input, access limited to those who need it, monitoring that excludes student work. We notify you within 24 hours of becoming aware. | Low |
| 9. Supplier failure or exit | Work can be exported at any time. On termination we delete student information, or return it first if you ask within 30 days. | Low |
| 10. A pupil signs in as another pupil
Only where pupil sign-ins are used |
Passwords are stored as bcrypt hashes and never shown again after they are handed out. The starter password is treated as public from the moment it is printed: a pupil must choose their own the first time they sign in, and the printed one stops working then. Sign-in attempts are rate limited, and a wrong username costs the same time as a wrong password so the form cannot be used to find out which children have accounts. The real exposure is a shared password or a slip left on a desk, which is a classroom control rather than a technical one – see section 8. | Low–medium, depending on how slips are handled |
| 11. A signed-in pupil is left signed in on a shared device
Only where pupil sign-ins are used |
The session is a cookie in that browser, and signing out ends it. One device holds one session: a teacher signing in signs the pupil out and a pupil signing in signs the teacher out, so a classroom laptop cannot be holding both. We cannot end a session nobody signs out of, so a shared-device routine belongs in your own staff guidance. | Medium on shared devices, low on one-to-one devices |
| 12. A pupil sees a mark before the teacher has checked it
Only where pupil sign-ins are used |
Marks are held back by default and become visible to the pupil only when the teacher hands them back. Until then the pupil is told the work is marked but not yet returned, and the mark cannot be reached by any other route – requesting one’s own unreleased script answers as though it does not exist. | Low |
8. Risks arising from your own use – for your school to complete
These depend on how your staff use the service, so only you can assess them. The ones we would put in front of a DPO:
- Whether staff will be told to keep entries to a name and the work – and never SEN, safeguarding or medical context (risk 3 above).
- Whether pupils will enter full names, or initials or candidate numbers instead.
- How long marked work should be kept, and who is responsible for deleting it (risk 5 above).
- That AI-suggested marks are reviewed by a teacher before they reach a report or a setting decision (section 5 above).
- How this is described in your pupil and parent privacy notices.
- What happens to a teacher’s account, and the student work in it, when they leave.
If you issue pupil sign-ins, add these:
- How password slips are handed out, and that they are collected back or destroyed rather than left in trays (risk 10 above).
- Whether pupils are told to sign out on shared devices, and whose job it is to check (risk 11).
- What a pupil is told about what their teacher can see – their work, their marks, and when they last signed in.
- Who at your school may create and delete pupil sign-ins, and what happens to a pupil’s login and work when they leave the school or move class.
- Whether display names will be full names or something less identifying; the sign-in shows the pupil whatever name your staff enter.
9. Outcome and sign-off – for your school to complete
| Measures approved by | |
| Residual risks approved by | |
| DPO advice provided | |
| DPO advice accepted or overruled | |
| Consultation responses reviewed by | |
| Prior consultation with the ICO required? | Not expected – no high residual risk is identified above. Required only if you conclude otherwise. |
| This DPIA will be reviewed by |
Questions on anything here: [email protected]. We will also complete your own supplier security questionnaire if you would rather work from that.