TutorPulse DPIA Template

1. Document control

Controller	[SCHOOL / MAT LEGAL NAME]	DPO	[NAME AND CONTACT]
Project owner	[NAME / ROLE]	DSL consulted	[NAME / DATE]
Assessment date	[DATE]	Next review	[DATE]
Decision	☐ Approved ☐ Approved with actions ☐ Not approved [DECISION DATE]

2. Why a DPIA is being completed

The project records identifiable sentiment from primary-age pupils and presents it to authorised school staff. Children are vulnerable data subjects; wellbeing selections may reveal or become health or safeguarding information; and the service uses cloud technology and pattern prompts. The school has therefore chosen to complete a DPIA before enabling the feature.

Scope: staff accounts, class rosters, attendance, daily wellbeing selections, “Need a chat” requests, suggested check-in signals, acknowledgements, browser offline storage, cloud hosting and authorised staff access.

3. Processing description and data flow

The school creates or imports a roster containing a pupil name or school-selected alias and stable internal identifier.
A pupil selects their name and one of six states: Bright, Calm, Okay, Tired, Worried or Need a chat.
The browser may temporarily queue a change locally if connectivity is unavailable, then synchronises it to the school/form tenant in Firestore.
Authorised staff view that day’s identifiable selections privately. “Need a chat” remains actionable until acknowledged; pattern prompts are suggestions based on recorded school check-ins.
The nightly process removes wellbeing check-ins after the school-selected 30- or 90-day period. Follow-up state is stored separately and must be governed by the school’s workflow.

AI boundary: pupil names, attendance and wellbeing records are not intentionally sent to Gemini. Gemini is used for general educational content and teacher-requested discussion prompts, not pupil profiling.

4. Data inventory

Data	People	Purpose	Access / disclosure	Proposed retention
Staff name, school email, user ID, role, security metadata	Staff	Authentication and access control	Authorised school admins; necessary TutorPulse/provider personnel	Account life plus contractual deletion/log periods
Pupil name/alias, stable ID, form, attendance	Pupils	Roster and classroom operation	Assigned staff and authorised administrators	[SCHOOL RETENTION PERIOD]
Mood, date/time, check-in prompts, acknowledgement state	Pupils	Pastoral awareness and follow-up	Assigned staff and authorised administrators; not intended for public display	☐ 30 days ☐ 90 days; follow-up state: [PERIOD]
Offline queued changes and cached classroom state	Pupils/staff	Resilience on school Wi-Fi	School-controlled browser profile and cloud service after sync	Until sync, application/browser clearing or expiry

5. Controller decisions and legal basis

Purpose	UK GDPR Article 6 basis	Article 9 / DPA 2018 condition if applicable
Roster and classroom administration	[DPO TO RECORD BASIS AND REASONING]	[NOT APPLICABLE OR CONDITION]
Wellbeing check-ins and follow-up	[DPO TO RECORD BASIS AND REASONING]	[DPO TO DECIDE AND DOCUMENT]

The school must update its pupil/parent and workforce privacy notices to explain what is collected, why, access, retention, rights and complaint routes. Consent should not be selected merely because the data concerns children; the DPO must determine the appropriate basis in the school’s circumstances.

6. Necessity, proportionality and consultation

Necessity: record why identifiable rather than anonymous check-ins are needed: [SCHOOL RATIONALE].
Data minimisation: no free-form pupil notes, dates of birth, addresses, parent contacts or medical records should be entered.
Accuracy: staff can verify roster identity and should treat a selection as a prompt for conversation, not a clinical fact.
Less intrusive alternatives considered: anonymous pulse checks, teacher observation, paper check-in, opt-in conversation card: [OUTCOME].
Consultation: DPO [DATE/ADVICE]; DSL [DATE/ADVICE]; IT/security [DATE/ADVICE]; pupils/parents or reason not consulted [DETAILS].

7. Risk assessment

Score likelihood and impact from 1 (low) to 5 (very high). Risk = likelihood × impact. The school should adopt its own risk thresholds.

Risk to people	Initial L×I	Controls / required treatment	Residual L×I	Owner / status
A pupil’s selection is observed by peers at the shared smartboard.	4×3=12	Supervised use; privacy-aware screen position; no public individual history; offer a discreet alternative; staff procedure.	[SCORE]	[OWNER/STATUS]
Unauthorised access through a shared, unlocked or compromised staff account.	3×5=15	Individual staff accounts, MFA where available, managed devices, screen lock, prompt sign-out, access reviews and incident monitoring.	[SCORE]	[OWNER/STATUS]
Cross-school or cross-form disclosure caused by incorrect permissions.	2×5=10	Tenant/form security rules, stable school claims, least privilege, emulator/production rules tests and periodic access testing.	[SCORE]	[OWNER/STATUS]
Staff over-interpret mood patterns or treat them as diagnosis/profiling.	3×4=12	Label signals as suggestions; no automated adverse decisions; staff training; verify through a supportive conversation and normal safeguarding process.	[SCORE]	[OWNER/STATUS]
A “Need a chat” request is missed or mistaken for an emergency channel.	3×5=15	Persistent authorised-staff workflow until acknowledgement; daily responsibility assigned; clear statement that normal DSL/emergency routes remain mandatory.	[SCORE]	[OWNER/STATUS]
Data is retained longer than pupils expect or the school needs.	3×4=12	Select 30/90-day period; nightly deletion; separately govern follow-up state; test deletion and document provider backup/log periods.	[SCORE]	[OWNER/STATUS]
Offline data remains on a lost or repurposed classroom device.	3×4=12	Managed encrypted devices/browser profiles, screen locks, restricted physical access, clear-on-exit/decommission procedure and minimal local data.	[SCORE]	[OWNER/STATUS]
Hosting location or international transfer safeguards are inaccurately represented.	3×5=15	Verify production Firestore/function regions and all subprocessors in writing; attach Article 28 terms, transfer mechanism and change process before onboarding.	[SCORE]	[OWNER/STATUS]
Wrong pupil association or inaccurate record causes inappropriate follow-up.	3×3=9	Stable IDs, roster checks, correction workflow, staff confirmation and no consequential automated decision.	[SCORE]	[OWNER/STATUS]
Pupil data is accidentally entered into an AI/content prompt.	2×4=8	AI functions are separated from wellbeing data; staff guidance prohibits personal data in content prompts; logging and code review.	[SCORE]	[OWNER/STATUS]

8. Actions required before approval

Action	Owner	Due date	Evidence / status
Confirm TutorPulse operator legal identity, address, privacy and security contacts.	[OWNER]	[DATE]	[OPEN]
Obtain written confirmation of production database/function locations and transfer safeguards.	[OWNER]	[DATE]	[OPEN]
Execute an Article 28 data processing agreement with subprocessor schedule, deletion/return and breach terms.	[OWNER]	[DATE]	[OPEN]
DPO records Article 6 basis, Article 9/DPA condition if required, and retention choice.	[OWNER]	[DATE]	[OPEN]
Update school privacy notices and staff/pupil operating guidance.	[OWNER]	[DATE]	[OPEN]
Test permissions, local-device clearing, retention deletion, correction/export and incident response.	[OWNER]	[DATE]	[OPEN]

9. DPO advice, decision and sign-off

If a high residual risk cannot be reduced, the controller must consider prior consultation with the ICO before processing begins.

DPO advice

[ADVICE, NAME, SIGNATURE, DATE]

Project owner response

[RESPONSE, NAME, SIGNATURE, DATE]

DSL approval

[NAME, SIGNATURE, DATE]

Controller / SIRO decision

[DECISION, NAME, SIGNATURE, DATE]

10. Review triggers and reference material

Review at least annually and before changes to data types, retention, AI use, hosting region, subprocessors, user access, pupil-facing presentation or safeguarding workflow. Reopen the DPIA after a serious incident, audit finding or material legal change.