When digital learning are used in school contexts, the bar is different. It’s not just about features or engagement. It’s about duty of care, predictable behaviour under stress, and governance you can explain in plain language.

This checklist is a practical, platform-agnostic set of checks we use when designing and reviewing child-facing digital experiences, including AI-enabled tools. It focuses on what holds up in real classrooms and what stands up to scrutiny from schools, families, and procurement teams.

Who it’s for

• School leaders, teachers, and wellbeing teams
• School IT, privacy, security, and procurement
• EdTech product, design, and engineering teams
• Programme owners planning pilots or rollouts

What this covers

• Non-negotiables for child-safe design
• Privacy, data minimisation, and procurement realities
• High-risk topics and harmful edge cases (at a high level)
• Classroom delivery constraints (teacher time and interruptions)
• Incident readiness and communications

How to use it

Use this as a quick review:

• before a pilot or trial
• when evaluating a vendor or product
• during UX/design reviews
• during QA and pre-launch checks

It’s intentionally concise so it can be used in a meeting or printed for a workshop.

Non-negotiables

• Written consent pathways for any student data handling, including vendors and contractors

• Least privilege by default: collect the minimum, retain the minimum, restrict access

• Default to safety: when uncertain, slow down, escalate, or say “I don’t know”

• Always provide a human exit (teacher, parent, or support service)

• Log and review safety events, including near-misses

Privacy, data, and procurement

• Map data flows end-to-end: what data, where it goes, who can access it, and why

• Prefer pseudonymous identifiers for analytics, keep identifiers out by default

• Retention and deletion policy you can explain in one minute

• Validate vendor claims with evidence, not brochures

• Plain-language threat model: key risks and the mitigations you actually use

Content safety and edge cases

• Define what the experience must never do (secrecy, grooming cues, personal medical advice)

• Create a high-risk topic list with a safe response pattern for each

• Refusal and redirection should feel supportive, not punitive

• Safeguards against prompt injection and “creative workarounds”

• Interface language that does not invite oversharing

Classroom reality

• Minimal teacher clicks during lesson time

• Support interruptions and dropouts without punishing the student

• Avoid workflow tax: if it adds work, it will be abandoned

• Teacher-facing visibility: what happened, what next, why it matters

• Clear reset patterns: undo, restart, safe pause

Incident response

• Simple playbook: triage, containment, comms, follow-up, learning review

• Pre-written parent and school comms templates for common scenarios

• Escalation thresholds: when to notify leadership and guardians

• Run a tabletop exercise before any pilot

• Track fixes and learnings on a cadence

Red flags (quick scan)

• No clear explanation of data storage location and access controls

• Claims of “safe” without showing how safety is achieved

• Any design that encourages secrecy or private relationships

• No deletion process, no audit trail, no incident plan

• Overclaiming outcomes without evidence

These checks are designed to be client-safe and project-agnostic. Every school context is different, so treat this as a starting point and adapt it to your governance and duty of care requirements.

Note: This resource is general guidance and does not constitute legal advice.