This is the plan School Atlas follows when a personal data breach is suspected or confirmed. It is designed to meet Articles 33 (notify the ICO within 72 hours) and 34 (notify affected individuals without undue delay) of the UK GDPR. Published for transparency — the internal playbook contains additional operational detail.
1. Definition of a personal data breach
A personal data breach means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. This includes:
- Confidentiality breach (data seen by someone unauthorised).
- Integrity breach (data altered without authorisation).
- Availability breach (data lost or made permanently unavailable).
A ransomware event that encrypts personal data is an availability breach even if no data is exfiltrated.
2. Detection and reporting (internal)
- Any suspected breach — however minor — is reported immediately to security@schoolatlas.co.uk. Reporters include the team, sub-processors, and anyone external who spots something unusual.
- Automated detections come from Sentry (error spikes), Supabase audit logs (unexpected privilege use), Vercel logs (traffic anomalies), and Stripe (fraud and dispute signals).
- The report must describe what was observed, when, and any immediate action taken. It does not need to be right — just fast.
3. First 60 minutes — containment
- Stop the bleed. Revoke compromised credentials, disable affected keys, take affected routes offline if needed. No judgement call: a 5-minute outage now is better than a 48-hour exposure.
- Preserve evidence. Do not wipe logs. Snapshot relevant Supabase audit logs, Vercel deployment state, and Sentry events. Forensics first, cleanup second.
- Start the clock. The 72-hour Article 33 window begins at the moment the controller becomes aware of the breach. Record the awareness timestamp.
4. First 24 hours — assessment
- What data?Categories of personal data involved (email addresses only? payment identifiers? children's data?).
- Whose data? Approximate number of data subjects; groups affected (parents, children, institution users).
- What is the likely consequence? Risk to rights and freedoms — reputational harm, financial loss, discrimination, identity theft, safeguarding exposure.
- What did the attacker / accidental disclosure gain? A password-reset email seen briefly is different from a full dump of review text with associated accounts.
5. ICO notification — Article 33
If the breach is likely to result in a risk to the rights and freedoms of natural persons, we notify the ICO without undue delay and in any event within 72 hours of becoming aware. Notification via the ICO self-reporting portal includes:
- The nature of the breach, categories and approximate numbers of data subjects and records.
- Contact details for the controller. School Atlas is not required to appoint a DPO under UK GDPR Art. 37, so the controller’s privacy contact (privacy@schoolatlas.co.uk) is provided in place of a DPO contact.
- Likely consequences of the breach.
- Measures taken or proposed to address the breach and mitigate its effects.
Where it is not possible to provide the full information within 72 hours, a partial notification is sent on time and updated as facts become clearer. Failing to notify a reportable breach is itself an enforceable failure — when in doubt, notify.
6. Data-subject notification — Article 34
If the breach is likely to result in a high risk to rights and freedoms, we also notify affected individuals directly, without undue delay and in clear, plain language. The notification includes:
- A description of the nature of the breach.
- The controller’s privacy contact (privacy@schoolatlas.co.uk).
- The likely consequences.
- What we have done and what affected individuals can do themselves (reset passwords, watch for suspicious emails, contact the school where relevant).
Direct notification goes to the email address on the account. Where an account has been deleted, notification is sent to the last-known address unless that itself would add risk. Where direct notification would require disproportionate effort, a public notice is published on this site and circulated by press release.
7. Sub-processor breaches
Where a sub-processor (Supabase, Stripe, Resend, Anthropic, Sentry, Vercel, Trigger.dev, Upstash, Google Analytics) notifies us of a breach affecting our data:
- Their notification starts our awareness clock for Article 33.
- We assess the scope for our users specifically, not relying on the sub-processor's broader framing.
- We notify the ICO if triggered; we notify affected users if Article 34 triggers.
8. Incident log and post-mortem
Every suspected breach, reportable or not, is logged. Within 14 days of resolution, a written post-mortem captures: what happened, how we detected it, what we did, what we did well, what we would do differently, and any controls added to prevent recurrence. The log is reviewed in the annual compliance register update.
9. Contact
Report a suspected breach to security@schoolatlas.co.uk. For other data-protection correspondence, email privacy@schoolatlas.co.uk.