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 contact: hello@outleap.io. Privacy and data-rights contact: info@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
• Cohort visibility, at-risk flags, and progress/workflow metadata (milestones, submission state)
• Administrative audit events and school setup metadata

(Reference Studio and Opportunity Radar are coming September 2026. Reference workflow records and opportunity-discovery data are not part of current processing and should be added only if those workflows are activated by written agreement.)

2.2 Why this is processed

• Provide a structured drafting and feedback process for the school's active Outleap workflows
• Enable staff oversight for progress and intervention
• Support consistent, advisory 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
Feedback generation	Relevant student-provided content + 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	Advisory feedback published to student and visible to staff through normal product views; no automated safeguarding alert delivery, staff routing or review hold in the launch product
CV/application workspaces (where enabled)	Evidence + CV/application text/context	Outleap API + Firestore + AI services	Student-owned CV/application drafts, support and review states
References (Reference Studio, coming September 2026 — not currently processed unless activated by written agreement)	Evidence + reference context	Outleap API + Firestore + AI services	Reference drafting and finalisation outputs
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.