# Data Protection Impact Assessment — Sample template for schools running Earn Your Stripes

> **Last reviewed: May 2026.** This template is published by **Earn Your Stripes** (stripesquest.com), operated by Stuart Ridout (sole trader, England), ICO registration ZC130961.

> **This is a starting-point template, not legal advice.** It is designed for adoption by a school's Data Protection Officer, headteacher, or DSL. Where the platform's facts are pre-filled, you can leave them as-is. Where it says **"School fills in"**, that's your homework. If your processing involves particularly sensitive cases — looked-after children, children with court-recorded protection orders, or witnesses to a court matter — you should commission a tailored DPIA from a qualified data protection practitioner and refer to the ICO's own DPIA template at https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/.

> **Who is the controller?** Your school is the data controller for pupil data processed through Earn Your Stripes. Earn Your Stripes is your data processor, acting under your instructions. This template is written from the school's perspective.

---

## Step 1 — Why we are doing a DPIA

A Data Protection Impact Assessment is a UK GDPR requirement for any processing likely to result in a high risk to the rights and freedoms of individuals. Running a character award scheme through Earn Your Stripes isn't high-risk on every dimension, but it does involve:

- **Children's data** — every pupil enrolled in the scheme is a child. Most are under 13.
- **Special-category-adjacent material** — photo and video evidence of identifiable pupils, occasionally in contexts that could infer religion, health, or other protected characteristics.
- **Innovative technology** — automated content moderation (Azure AI Content Safety) is applied to every uploaded photo and note.
- **Systematic monitoring** — every upload is automatically scored for safety before another user can see it.

Any one of those triggers an ICO recommendation to complete a DPIA before processing starts. The ICO's Age Appropriate Design Code (Children's Code) requires a DPIA for any service likely to be accessed by children.

---

## Step 2 — Describe the processing

### Pre-filled — keep as-is unless the platform changes

| Question | Answer |
|---|---|
| What is the platform? | Earn Your Stripes — a character award scheme for UK schools, ages 5–14. Includes two pathways: Tiger Stripes (Years 1–3) and Earn Your Stripes (Year 4 and up). Operated by Stuart Ridout, sole trader, England. ICO registration ZC130961. |
| What data is processed? | Pupil identity (first name and last initial, year group, form group); photo and video evidence of activities; written notes and captions; parent name and contact email (for under-13 mediation); staff identity for school accounts; third-party verifier name and email (single-use, for one submission); audit log records; payment metadata for any reward orders. |
| Whose data? | Pupils enrolled by your school (ages roughly 5–14), parents of under-13 pupils, school staff (form tutors, school admin, DSL, site owner), and external third-party verifiers (coaches, instructors, community leaders) named by a pupil's family for a single attestation. |
| Special category data? | Photo and video content may inadvertently reveal special category data — religious dress, disability, ethnicity. The platform does not knowingly elicit special category data; the lawful basis for any incidental special category data is UK GDPR Article 9(2)(g) (substantial public interest — safeguarding of children and individuals at risk). |
| How is it collected? | Directly from users via the Earn Your Stripes web app and PWA. Parents log evidence on behalf of under-13 pupils; pupils aged 13+ log their own. Parents and staff sign in via a passwordless email magic link (Microsoft 365 / Google Workspace SSO is on the roadmap). Third-party verifiers respond via a one-shot email link. |
| How is it used? | Stored against the pupil's record in the school's tenant; displayed to the pupil's parent, their form tutor, and (for flagged content) the school's DSL. Every photo and caption is scanned by Azure AI Content Safety for hate, sexual, violent and self-harm material before another user sees it. EXIF metadata is stripped on processing. |
| Who else processes it? | Three sub-processors: Microsoft Azure (UK South — storage, Cosmos DB, Blob, AI Content Safety), Resend (US — transactional email), Stripe (Ireland / US — payment processing for reward orders). |
| How long is it retained? | Default: until the pupil leaves the school plus 2 years. Schools can override this with a shorter retention period. Account-close requests are processed within 30 days. Residual copies in backups are purged within 30 days of deletion. Audit log records are retained beyond the data they reference. |
| International transfers? | Yes — Resend and Stripe are US-based. Transfers are protected by Standard Contractual Clauses and the UK International Data Transfer Addendum. Primary pupil data and evidence remain in Azure UK South. |

### School fills in

- **School name:** ____________________________________________
- **Person responsible for this DPIA:** ____________________________________________ *(often the DPO or headteacher)*
- **Their role:** ____________________________________________
- **Their contact email:** ____________________________________________
- **Year groups enrolled:** ____________________________________________
- **Approximate number of pupils:** ____________________________________________
- **Form groups using the scheme:** ____________________________________________
- **Date you started using the platform:** ____________________________________________

---

## Step 3 — Consultation

### Pre-filled

UK GDPR Article 35(9) recommends consulting "data subjects or their representatives" where appropriate. For a school-run character scheme, that means consulting parents, pupils, and the school's governance.

The platform consults with:

- Every parent of a participating under-13 pupil, via the magic-link sign-in flow at first use.
- Every parent and 13+ pupil at first sign-in, via the magic-link landing.
- School DSLs handling flag responses, via the audit panel.

### School fills in

- **Did you consult parents before enrolling pupils?** ☐ Yes  ☐ No. *If yes — how, when, and what was the response?* ____________________________________________
- **Did you consult pupils directly?** ☐ Yes  ☐ No. *If yes — how, when, and what was the response?* ____________________________________________
- **Are there any objections on file?** ____________________________________________
- **Did you consult your governing body / academy trust / governors?** ____________________________________________
- **Was the school DPO consulted?** ____________________________________________

---

## Step 4 — Necessity and proportionality

### Pre-filled

| Question | Platform's answer |
|---|---|
| Lawful basis for processing | The school relies on UK GDPR Article 6(1)(e) (public task — statutory educational function) for pupil processing. Parent and staff account processing relies on Article 6(1)(b) (contract) or 6(1)(e) (public task). Verifiable parental involvement governs evidence shared by a parent on behalf of an under-13. |
| Does the processing achieve the purpose? | A safeguarding-first, school-administered award scheme achieves the purpose better than the alternatives — shared spreadsheets, WhatsApp groups, paper folders, public social media — all of which fail on evidence safeguarding, audit, or data residency. |
| Is there a less-intrusive alternative? | None offering the same safeguards: tenant-scoped storage, automated content moderation, single-use third-party links, KCSIE-aligned operating model, UK data residency, and a 24-hour DSL escalation. |
| How is data minimised? | EXIF metadata and GPS coordinates are stripped on processing. Pupil names are shown as first name + last initial outside the school's own staff view. School admins see no evidence artefacts — only aggregate dashboards. Third-party verifiers see only the one submission they were invited to sign. |
| How is accuracy maintained? | Pupils, parents and staff can edit or delete their own records. Schools can correct pupil records via the admin surface. A correction request can also be raised to hello@stripesquest.com. |

### School fills in

- **Is there a school-specific reason the scheme is necessary?** *(e.g. "we have committed to delivering a structured character curriculum across KS2 and the lower half of KS3")* ____________________________________________
- **Have you considered not running the scheme at all?** *What would the trade-off be?* ____________________________________________

---

## Step 5 — Identify and assess risks

The risks below are the platform-level risks the platform considers in its own processor assessment. Add any school-specific risks to the bottom of the table.

### Pre-filled — platform risks

| # | Risk | Likely | Severe | Mitigations | Residual |
|---|---|---|---|---|---|
| 1 | Photos of pupils seen by people outside the school | Low | High | Tenant-scoped storage; per-school data isolation at the data layer; signed-URL delivery (short-lived, HTTPS-only); role-based access checks on every request; no cross-school code path. | Low |
| 2 | Inappropriate content uploaded (nudity, violence, hate, self-harm) | Medium | High | Azure AI Content Safety scan on every upload (image + text); severity ≥ 4 blocked outright; 2–3 routed to DSL manual-review queue before publication; fail-closed if moderation unavailable. | Low |
| 3 | Content used for AI training, advertising, or profiling | Low | Medium | No advertising or analytics SDKs; no AI-training clause in our terms; Microsoft contractually does not retain content for training. | Low |
| 4 | Account compromise via password reuse | Low | Medium | Magic-link sign-in for parents and staff — no password to reuse or leak; codes expire in 15 minutes with a 5-attempt lockout. Microsoft 365 / Google Workspace SSO with MFA is on the roadmap for staff and 13+ pupils. | Low |
| 5 | Re-identification of pupils via image metadata (EXIF, GPS) | Medium | Medium | Images are re-encoded on processing; EXIF (including GPS) is stripped before storage. | Low |
| 6 | Data breach at a sub-processor | Low | High | Sub-processors limited to three (Azure, Resend, Stripe); all bound by data processing agreements; UK / EU / US transfers covered by SCCs and the UK IDTA. | Low |
| 7 | Inappropriate disclosure between staff roles | Low | High | Object-level authorisation guards on every action; form teachers see only their form group; school admins see no evidence; the DSL sees only flagged items; tamper-evident audit log of every evidence view and DSL view-as session. | Low |
| 8 | Third-party verifier sees more than the one submission they were invited to | Low | Medium | Single-use signed JWT links with 14-day TTL; the JTI hash is stored against the submission and cleared on use; no account, no session beyond the link. | Low |
| 9 | A safeguarding flag is missed or delayed | Low | High | Any user can flag a submission; flags notify the form teacher and DSL immediately; 24-hour SLA timer; auto-escalation to the school site owner if the DSL has not acknowledged. | Low |
| 10 | Data retained longer than necessary | Low | Medium | Default retention is child-leaves-school + 2 years; schools can override to shorter; account-close = 30-day deletion SLA; backup tier ages out within 30 days of deletion. | Low |
| 11 | Pupils unable to exercise data subject rights | Low | Medium | Parents can request a full export of their child's record; in-app delete on every submission; in-app account close; one-month SLA on email requests. | Low |

### School fills in — your additional risks

| # | Risk | Likely | Severe | Mitigations | Residual |
|---|---|---|---|---|---|
| 12 |  |  |  |  |  |
| 13 |  |  |  |  |  |
| 14 |  |  |  |  |  |

*Examples worth thinking about:*

- A pupil whose parent has a court order restricting their image being shared.
- A looked-after child whose carer arrangements are non-standard.
- A pupil whose family has not yet engaged with the parent magic-link sign-in.
- A pupil moving form groups mid-year, and continuity of their evidence.

---

## Step 6 — Identify measures to reduce risk

### Pre-filled — the platform's standing controls

- Per-school tenant isolation at the data layer — no cross-school code path.
- Object-level authorisation guards on every parent and staff action; 48-case automated test suite.
- Azure AI Content Safety moderation on every image and text upload, fail-closed in production.
- EXIF / GPS metadata stripped from every image on processing.
- Magic-link sign-in for parents and staff (15-minute TTL, 5-attempt lockout). Microsoft 365 / Google Workspace SSO with MFA for staff and 13+ pupils is on the roadmap.
- Single-use signed JWT third-party attestation links (14-day TTL, single-use enforced via JTI hash).
- TLS in transit; private blob containers; signed-URL delivery only, HTTPS-only.
- Azure UK South data residency for pupil data and evidence. Transactional email (Resend, US) and payments (Stripe, US / Ireland) covered by Standard Contractual Clauses and the UK International Data Transfer Addendum.
- Tamper-evident audit log of every state-changing action (sign-ins, edits, approvals, sign-offs, uploads, exports) and every sensitive view (evidence access, DSL view-as). Entries are write-once at the application layer; storage-level immutability is on the roadmap.
- 24-hour DSL acknowledgement SLA, with auto-escalation to the school site owner.
- 30-day deletion SLA on account close; backup tier ages out within 30 days of deletion.

### School fills in — your additional measures

- ____________________________________________
- ____________________________________________
- ____________________________________________

*Examples worth considering:*

- A clear briefing for new form tutors before their first sign-off session.
- A pupil / parent objection register kept by the DSL.
- A schedule for the DSL to review the flagged-items queue (e.g. weekly).
- A photo policy for staff's own non-platform channels (camera roll, WhatsApp).
- A privacy notice for parents that references Earn Your Stripes alongside your other processors.

---

## Step 7 — Sign off

| Role | Name | Date | Signed |
|---|---|---|---|
| Person responsible for this DPIA |  |  |  |
| Headteacher / academy trust DPO |  |  |  |
| Designated Safeguarding Lead |  |  |  |
| Governor representative *(optional)* |  |  |  |

**Date of next review:** ____________________________________________

Recommended cadence: annually, or sooner if any of the following change — your school's roster or scheme rollout, the platform's sub-processors or material features (we'll email you), changes to your safeguarding policy, or following a reportable incident.

---

## Disclaimer

This template is provided by Earn Your Stripes as a convenience. It is not legal advice. If your processing involves particularly sensitive children's data — for example children with a court-recorded protection order, looked-after children, or children of public figures — you should consult a qualified data protection practitioner and refer to the ICO's own DPIA template at https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/.

*Questions or corrections: hello@stripesquest.com.*