# Outleap DPIA Starter (School Template)

Status: Approved baseline template for school completion. This starter document does not replace legal or DPO advice.

## 1. Project Summary

- **Project:** Outleap rollout for first-school destinations workflow
- **School:** `[School name]`
- **School owner:** `[Name + role]`
- **Outleap supplier entity:** Outleap Limited (Company No. 14277395), 3rd Floor, 86-90 Paul Street, London, England, EC2A 4NE
- **ICO registration:** ZB393894
- **Supplier contact:** Jesse Merrigan (Director and named data protection contact, supported by Outleap's documented governance and review process). General/supplier, privacy and data-rights contact: hello@outleap.io
- **Start date:** `[YYYY-MM-DD]`
- **Review date:** `[YYYY-MM-DD]`

## 2. Processing Description

### 2.1 What is being processed

- Student profile and school account data (name, email, role, school linkage)
- Evidence entries and UCAS three-question statement drafts/submissions
- Feedback drafts, published feedback, and status history
- CV/application records where enabled for the school's rollout, including suggested wording stored with feedback on a cover letter or an application answer
- Cohort visibility, at-risk flags, and progress/workflow metadata (milestones, submission state)
- Administrative audit events and school setup metadata

### 2.2 Why this is processed

- Give students a structured way to write their own drafts and get feedback on them in the school's active Outleap workflows
- Enable staff oversight for progress and intervention
- Support consistent, advisory statement feedback that staff can see through normal product views while safeguarding escalation remains owned by the school's usual route

### 2.3 Who can access data

- Student role: own records
- Teacher and school admin roles: scoped records according to assignment and school scope
- Outleap admins: platform operations under contractual controls

## 3. Lawful Basis (School to complete)

- **Primary lawful basis:** `[Public task / Legitimate interests / Contract]`
- **Special category condition (if applicable):** `[Article 9 condition]`
- **Notes/justification:** `[School-specific rationale]`

## 4. Necessity and Proportionality

Document why this processing is required and proportionate.

- Why these data fields are required for stated outcomes: `[text]`
- Why less intrusive alternatives are insufficient: `[text]`
- How role scoping/minimisation is enforced in school practice: `[text]`

## 5. Data Flow Snapshot

| Stage | Data in | Processor/system | Data out |
| --- | --- | --- | --- |
| Authentication | Email + auth token | Firebase Auth | Role-scoped session |
| Evidence capture | Evidence entry text + metadata | Outleap API + Firestore | Saved evidence records |
| Draft workflow | Statement text + metadata | Outleap API + Firestore | Saved draft/submission state |
| AI feedback | The student's own writing + minimum workflow context | Approved AI service provider in the UK/EU | Structured feedback returned to the Outleap API |
| Feedback delivery | Generated feedback + workflow metadata | Outleap API + Firestore | Advisory feedback published to the student; statement feedback visible to staff through normal product views; feedback on a cover letter or an application answer can include suggested wording, stored with the feedback and not shown in the product views; no automated safeguarding alert delivery, staff routing or review hold in the service |
| AI drafting support, on the student's request (where enabled) | The student's own evidence, or the CV point they choose + minimum workflow context | Approved AI service provider in the UK/EU | A first CV built from the student's own evidence (where the school's CV setting allows it), stored when made; or a reworded CV point, returned to the student and stored only if they choose it |
| Evidence structuring | A note about something the student has done | Approved AI service provider in the UK/EU | A piece of evidence, returned to the student and stored only if they keep it |
| Page reading (where enabled) | A course page the student keeps, or an advert or link they paste | Approved AI service provider in the UK/EU | What it asks for: a course page's reading is stored when made; an advert's reading is stored only if the student keeps it |
| CV/application workspaces (where enabled) | Evidence + CV/application text/context | Outleap API + Firestore | Student-owned CV/application drafts, support and review states |
| Reporting | Progress + status data | Admin insights endpoints | School admin views |

## 6. Risk Assessment

Rate likelihood and impact for your school context.

| Risk | Likelihood | Impact | Controls | Residual risk |
| --- | --- | --- | --- | --- |
| Unauthorised access to student records | `[L/M/H]` | `[L/M/H]` | RBAC, school scoping, auth controls | `[L/M/H]` |
| Cross-school data visibility | `[L/M/H]` | `[L/M/H]` | SchoolId scoping checks, role middleware | `[L/M/H]` |
| Inappropriate handling of sensitive statement content | `[L/M/H]` | `[L/M/H]` | Staff visibility of feedback, school safeguarding process, Outleap operational support handoff if required | `[L/M/H]` |
| Unnecessary disclosure or retention by an external AI service | `[L/M/H]` | `[L/M/H]` | Minimum relevant workflow context; UK/EU provider routing; raw AI-output logging disabled; least-privilege runtime credentials; documented provider retention and contract terms | `[L/M/H]` |
| Retention beyond educational need | `[L/M/H]` | `[L/M/H]` | Retention schedule + deletion workflow | `[L/M/H]` |
| Overreliance on AI feedback | `[L/M/H]` | `[L/M/H]` | Feedback labelled as advisory, staff visibility, human judgement retained | `[L/M/H]` |

## 7. Mitigation Actions

- [ ] Confirm school role model and access governance.
- [ ] Agree retention windows by dataset and cycle.
- [ ] Confirm safeguarding escalation route for concerning content.
- [ ] Review and accept the current subprocessor list and data-flow description.
- [ ] Confirm approved AI subprocessors, UK/EU processing arrangements and provider retention terms.
- [ ] Document DSAR and breach communication contacts.
- [ ] Complete contract pack (DPA + policy references).

## 8. Data Residency and Transfers

- School confirms acceptance of documented residency statement in the supplier trust pack.
- School confirms that relevant processing can occur in supported EU regions
  and records the applicable UK adequacy basis or other appropriate safeguard.
- School confirms transfer safeguards are documented where any other non-UK processing occurs.
- School records any local policy constraints here: `[text]`.

## 9. Decision and Sign-Off

- **Residual risk level:** `[Low / Medium / High]`
- **DPO consultation required:** `[Yes / No]`
- **Approved by:** `[Name + role]`
- **Date:** `[YYYY-MM-DD]`

## 10. Review Cycle

- Reassess at least annually, or sooner if processing scope materially changes.
- Reassess after significant incidents, safeguarding events, or supplier architecture changes.