Data Protection Impact Assessment

Data Protection Impact Assessment (DPIA)

Cuevela safeguarding training platform

Document owner: Jordan Gatehouse (Founder) Version: 1.1 (draft for legal review) First issued: 2026-04-10 Last revised: 2026-08-11 Status: Draft — requires legal review before finalisation Review schedule: Before scaling beyond pilot; after any new external data flow; annually

Version history

| Version | Date | Change | |---|---|---| | 1.0 | 2026-04-10 | First issue. | | 1.1 | 2026-08-11 | Currency pass ahead of legal review: added job_family and the at-home completion position to the processing description (§1.2, §1.6); recorded which review triggers have fired since first issue (§7.2); added this version history and the sign-off block. |

1. Description of the processing

1.1 What is the platform?

A voice-first AI training platform for school safeguarding leads (Designated Safeguarding Leads — DSLs). Staff practise responding to simulated disclosures from an artificial child persona. The platform evaluates their conversational approach and follow-up safeguarding actions.

This is a training product. It is not a live safeguarding tool. No real children are involved. No real safeguarding decisions are made by the system.

1.2 What personal data is processed?

| Data category | Data subjects | Examples | Retention | |--------------|---------------|----------|-----------| | Account data | Staff members | Email, name, hashed password, MFA secret, role | Until account deletion | | Role context | Staff members | job_family — a coarse staff-role grouping (e.g. teaching, support, leadership) set by the school admin. Used to select role-appropriate scenarios and to group the annual update record. Not a job title, not free text, not used for any assessment decision. | Until account deletion | | Voice recordings | Staff members | Audio of trainee speaking during practice sessions | 14 days | | Transcripts | Staff members | Text transcriptions of trainee speech | 12 months | | Structured interaction traces | Staff members | Turn-by-turn records, evaluation scores, pathway progress | 12 months | | Assessment artefacts | Staff members | Generated session summaries, strengths/concerns | 12 months | | Written feedback | Staff members | Free-text problem reports / improvement requests | 12 months | | Training completion + competency record | Staff members | Minimised, deterministic snapshot: trainee name + email, scenario key/title/version, deterministic simulation outcome, session score/band, completion date (name + email are held so it functions as the school's evidence; on erasure they are pseudonymised — identifiers removed, completion facts retained). Score/band are held but are exported completion-only by default — released only on an explicit opt-in | 6 years, then secure deletion (delivery-tool model — the school retains the long-tail copy). Deletion is gated so the school's evidence is never destroyed before it holds a copy | | Security audit logs | Staff members, admins | Login events, session revocation, data erasure, IP addresses | 6 years, then personal fields redacted in place (Art 17(3)(e); Limitation Act 1980) | | Persona text | N/A (fictional) | AI-generated responses from simulated child | 12 months |

Voice classification (design exclusion): trainee voice is processed only as practice audio + speech-to-text on already-authenticated users. The platform does not perform speaker identification, voiceprint enrolment, voice authentication, or emotion/stress biometric analysis. Voice is therefore ordinary Article 6 personal data, not Article 9 special-category / biometric data. This exclusion is a deliberate design boundary; adding any such feature would reclassify the audio and require a DPIA revision.

1.3 Lawful basis

Contract — the subscribing school purchases the training service. Processing staff session data is necessary to deliver the contracted service.

1.4 Data controller and processor

A Data Processing Agreement is required between Gat3house Ltd and each subscribing school.

1.5 Data flows to third-party sub-processors

| Sub-processor | Purpose | Data sent | Data excluded | |--------------|---------|-----------|---------------| | DigitalOcean (LON1) | Infrastructure hosting | All platform data (encrypted) | N/A | | OpenAI (may change to Anthropic) | LLM persona generation | Scenario context, persona state, conversation turns | Evaluation results, pathway logic, post-actions, user IDs, emails, organisation IDs | | ElevenLabs | Text-to-speech | Persona response text only | Trainee data, identifiers, traces | | ElevenLabs Scribe v2 | Speech-to-text (server-side, where used) | Trainee audio | Metadata, identifiers, scenario context |

STT: Browser-only Web Speech API (client-side); ElevenLabs Scribe v2 for server-side voice work.

All external provider integrations are feature-flagged and can be disabled per tenant, falling back to deterministic-only mode with zero external data sharing.

1.6 Where staff complete training

Training is completed by school staff as part of their professional development. The platform is a public web application and does not restrict access to school networks or school-managed devices, so staff may complete a session at home or on a personal device.

Data-protection position:

The residual risk is the ordinary one of an authenticated web session on a device the school does not manage — an unattended logged-in browser. This is mitigated by mandatory MFA for all users, short access-token lifetime with refresh rotation, and server-side session revocation. It is recorded here rather than engineered away, because restricting the platform to school-managed devices would prevent the flexible completion the product exists to enable.

2. Necessity and proportionality

2.1 Is the processing necessary?

Yes. The platform requires:

2.2 Is it proportionate?

Yes. Mitigations include:

2.3 Could the purpose be achieved with less data?

The voice-first approach requires audio capture. Transcripts could theoretically be discarded after evaluation, but they are needed for the review workflow (supervisors review session quality). The 12-month retention period balances the school's need for training records against data minimisation.

3. Risk assessment

3.1 Risk: Staff member enters real safeguarding case data

| | | |---|---| | Likelihood | Medium — staff may instinctively reference real cases during practice | | Impact | High — real child data would be processed and potentially sent to third-party providers | | Mitigation | Terms of use prohibit real data entry. Platform displays "Training simulation — not for operational safeguarding use" disclaimer. Incident response playbook covers this scenario: immediate erasure via admin endpoint, provider notification if data was sent externally, school DPO notification. Designed mitigation (2026-07, roadmap #77): the real-vs-practice break-glass systematises this playbook as a product path — see 3.1.1. | | Residual risk | Medium — no technical control can fully prevent a trainee referencing real material, but the break-glass converts the uncontrolled variant of this event into a designed, minimised, short-retention path. |

3.1.1 Designed mitigation: real-vs-practice break-glass (roadmap #77)

Whole-staff rehearsal (50-200 staff per school) makes it statistically certain that training sessions will occasionally surface real material: a trainee's own experience of abuse, a live concern about a real child recognised mid-rehearsal, or deliberate use of the private session as a first place to say something aloud. The break-glass feature (docs/product/specs/break_glass.md, founder-decided 2026-07-27) handles this as follows, and each element is a data-protection control:

Premise note for §3.2-3.4: those ratings rest on session content being fictional. Break-glass introduces a bounded, designed path where real personal data may transiently exist; its short-retention hard-delete class and the mitigations above are what keep the §3.2-3.4 residual ratings valid. This subsection, the DPA annex, and the pilot-agreement clause were drafted together (Pilot-Legal pack item 11) for solicitor review alongside the C1 pack.

3.2 Risk: Unauthorised access to session data

| | | |---|---| | Likelihood | Low | | Impact | Medium — training data exposed (not live safeguarding data) | | Mitigation | MFA for admin users. Revocable server-side sessions with token rotation and replay detection. Rate-limited login (5/min). Organisation-scoped data isolation. Audit logging of all auth events. | | Residual risk | Low |

3.3 Risk: Third-party provider breach

| | | |---|---| | Likelihood | Low | | Impact | Medium — conversation data exposed, but persona text is fictional and trainee utterances are practice responses | | Mitigation | Business/enterprise tier DPAs with zero-retention clauses. Feature flags allow immediate disablement. Incident response playbook covers provider breach notification chain. | | Residual risk | Low |

3.4 Risk: LLM provider trains on session data

| | | |---|---| | Likelihood | Low (enterprise tiers typically exclude training) | | Impact | Low — conversation data is practice scenarios, not real disclosures | | Mitigation | Enterprise DPA with explicit no-training clause. API usage (not consumer chat) further reduces risk. Context sent is bounded and excludes identifiers. | | Residual risk | Low |

3.5 Risk: Data retained beyond necessity

| | | |---|---| | Likelihood | Low | | Impact | Low — excess retention of training data, not high-sensitivity data | | Mitigation | Automated daily retention-enforcement job (live in production) deletes each data class at its window: raw audio 14 days; transcripts, traces and feedback 12 months. The minimised completion record carries a 6-year expiry stamp; its automated deletion runs behind an export-before-delete safeguard (the school's evidence is never destroyed before it holds a copy) — the deletion step is the final piece of the retention chain. Deletion counts are audit-logged so enforcement is monitored (an inert/unenforced schedule would be worse than an honest longer period). Admin erasure endpoint hard-deletes a user's sessions, audio, generated outputs and feedback on request, and pseudonymises the durable completion record rather than deleting it (see §5 Erasure). | | Residual risk | Low |

3.6 Risk: Inadequate backup leads to data loss

| | | |---|---| | Likelihood | Low | | Impact | Medium — loss of training records and platform state | | Mitigation | Automated daily Postgres snapshots (14 kept locally) synced off-site in grandfather-father-son tiers (daily ~30 days, weekly ~10 weeks, monthly ~6 months), with a snapshot-freshness alert. Raw audio is intentionally not backed up (14-day, most-sensitive, substance survives in the transcript). Erased data ages out of backups within ~6 months, held "beyond use" per ICO guidance. Outstanding erasures are re-applied after any restore automatically: every erasure writes an out-of-band suppression tombstone, and the restore procedure replays them to re-erase any user the snapshot would otherwise resurrect. Backup + restore procedure tested. | | Residual risk | Low |

4. Technical and organisational measures

4.1 Authentication and access control

| Measure | Status | |---------|--------| | MFA (TOTP) for admin users | Implemented | | Revocable server-side sessions | Implemented | | Refresh token rotation with replay detection | Implemented | | Rate-limited login (5 attempts/minute) | Implemented | | Role-based access (STAFF, DSL, DEPUTY_DSL, ADMIN) | Implemented | | Organisation-scoped data isolation | Implemented | | Auth secret startup guard (blocks demo credentials) | Implemented |

4.2 Encryption

| Measure | Status | |---------|--------| | TLS in transit (Caddy automatic HTTPS, TLS 1.3) | Implemented | | S3 audio encryption at rest (SSE-KMS) | Implemented | | Database encryption at rest (DigitalOcean volume encryption) | Platform default | | Password hashing (PBKDF2-SHA256, 600k iterations) | Implemented | | Refresh tokens hashed before storage (SHA-256) | Implemented |

4.3 Data lifecycle

| Measure | Status | |---------|--------| | Retention by data class (14d audio, 12m traces) | Implemented | | Automated daily retention enforcement | Implemented | | S3 lifecycle policy (14-day expiry) | Configured | | Admin data erasure endpoint with audit logging | Implemented | | Erasure suppression (re-erase users resurrected by a DB restore) | Implemented | | Automated daily database backups (off-site GFS tiers: daily ~30d, weekly ~10w, monthly ~6m) | Implemented |

4.4 Audit and monitoring

| Measure | Status | |---------|--------| | Structured audit logging (11 event types, 13 call sites) | Implemented | | Training trace / security audit log separation | Implemented | | PII exclusion from audit detail (no passwords, tokens, emails) | Verified by tests | | IP address logging for security investigation | Implemented |

4.5 AI-specific controls

| Measure | Status | |---------|--------| | Deterministic safeguarding engine (source of truth) | Implemented | | LLM bounded to persona expression only | Implemented | | LLM cannot decide safeguarding outcomes | Enforced by architecture | | Feature-flagged LLM per tenant/environment | Implemented | | Deterministic fallback always available | Implemented | | Data minimisation in LLM prompts (identifiers excluded) | Verified — see data-flow map | | Output labelling ("Training simulation" disclaimer) | Implemented |

4.6 Incident response

| Measure | Status | |---------|--------| | Incident response playbook (pilot-scale) | Documented | | Real-data-entry specific procedure | Documented | | 72-hour ICO notification process | Documented | | Contact chain (founder → school DPO → ICO) | Documented |

5. Data subject rights

| Right | How it is fulfilled | |-------|-------------------| | Access | Admin can export a structured record of a user's data on request (the DSAR export includes the durable completion record). A trainee can also self-download their own training-record certificate. | | Erasure | Admin erasure endpoint deletes all user sessions, traces, audio, and outputs (and, for full erasure, pseudonymises the audit trail and deletes the account). The durable completion record is pseudonymised, not deleted — the direct identifiers (name, email) are removed and the completion facts retained as the school's anonymised evidence, since the school holds an independent retention basis for its training records. Logged in audit trail. Erasures are re-applied automatically after any database restore, so a restore cannot silently undo them. | | Rectification | Not applicable — training data is a factual record of the practice session | | Restriction | User account can be deactivated by admin, preventing further processing | | Portability | The completion record and session data are available as a structured export (JSON); the school's cohort record is available as a signed JSON/CSV bundle. | | Objection | Staff raise with their employer (the data controller). The school decides. |

6. Consultation

6.1 Has the ICO been consulted?

Not yet. Consultation is required if residual risks remain high after mitigations. The primary residual risk (staff entering real data) is mitigated by policy and procedural controls, which is proportionate for a training platform. If regulatory requirements change or the risk assessment is updated, ICO consultation should be reconsidered.

6.2 Have data subjects been informed?

Data subjects (staff members) are informed via:

7. Decision

7.1 Can the processing proceed?

Yes, subject to:

  1. DPAs signed with OpenAI and ElevenLabs before activating those integrations
  2. DPA signed with each subscribing school
  3. Terms of use finalised prohibiting real safeguarding data entry
  4. Closing the two pre-pilot audit logging gaps (MFA_FAILURE and LOGOUT events)
  5. Legal review of this DPIA before finalisation

7.2 Review triggers

This DPIA must be reviewed when:

Triggers fired since first issue (2026-04-10):

| Trigger | Event | Handled in | |---|---|---| | LLM provider changed | Persona model pinned and moved to a same-vendor chain | §1.5, §3.4 | | Server-side STT | Not activated — server-side STT was decommissioned and speech-to-text is browser-only. The trigger is closed rather than pending. | §1.2 | | New external data flow | An email/notification sub-processor is committed for go-live and not yet selected. This DPIA must be revised, and a data-flow-map entry added, before any school data flows through it. | Open — see §7.1 | | Near-miss | Backup gap identified and closed 2026-07-23; off-site backup verified. No personal data was lost or exposed. | §3.6 |

8. Sign-off

This DPIA is not final until signed below. The founder is the document owner; the data-protection solicitor engagement scheduled for ~20 August 2026 is the independent review named in §7.1 condition 5.

| Role | Name | Signature | Date | |---|---|---|---| | Document owner (Founder) | Jordan Gatehouse | | | | Independent legal review | | | |

Conditions accepted at sign-off (record any residual risk consciously accepted, and any §7.1 condition still open on the date of signature):

Appendix: Supporting documents