When the University of Copenhagen disclosed a breach affecting 525,000 individuals three days after detection, it highlighted a critical issue: the gap between discovering an incident and executing a compliant response is where liability accumulates. This checklist outlines the actions required in the first 72 hours after detecting a breach involving personal data at a higher education institution.
What This Checklist Covers
This checklist guides you from detection through initial notification to the Supervisory Authority. It assumes you've confirmed unauthorized access to personal data and focuses on GDPR Article 33 and Article 34 obligations. Use it to manage the immediate aftermath, not long-term remediation.
The Copenhagen incident, involving national identity numbers, contact details, and physical access codes, underscores why speed matters. The university detected the attack on October 20 but didn't issue a public notification until October 23. That three-day window is your entire compliance runway under GDPR's 72-hour notification requirement.
Prerequisites
Before starting this checklist, confirm:
- You have the authority to make containment decisions without waiting for committee approval.
- Your incident response team includes legal counsel, IT security, and communications.
- You have direct contact details for your Supervisory Authority.
- Your breach register is accessible, and you can document actions in real time.
- You can identify the lawful basis for each affected processing activity.
If you're missing any of these, your 72-hour clock is already ticking while you're still assembling the right team.
Breach Response Checklist
1. Document the detection timestamp
Record when you first became aware of unauthorized access, not when you confirmed its scope. This timestamp sets your 72-hour deadline under Article 33(1).
2. Activate containment immediately
Isolate affected systems without waiting to understand the full scope. The Copenhagen breach spread to administrative systems after initial detection. Act quickly.
3. Identify the categories of personal data at risk
Specify data types, not generic categories. For example, detail whether "contact information" includes home addresses or work emails. Different data types carry different risks.
4. Assess the likelihood and severity of risk to individuals
Apply Article 34(1)'s "likely to result in a high risk" test. Consider if the data could enable identity fraud or targeted phishing. The presence of national identity numbers and access codes likely triggers a high-risk threshold.
5. Notify your Supervisory Authority within 72 hours
Submit your notification with available information, even if your investigation isn't complete. Article 33(4) allows phased reporting. Include the nature of the breach, affected categories, likely consequences, and measures taken or proposed.
6. Determine whether direct notification to individuals is required
If you've met the high-risk threshold, Article 34(1) requires direct notification unless specific exemptions apply, such as encryption or disproportionate effort.
7. Reset compromised credentials immediately
If your breach involves authentication credentials, reset them quickly. Attackers move faster than your investigation.
8. Prepare your public statement in advance
Draft your external communication now. Include what happened, what data was affected, what actions you're taking, and what individuals should do.
9. Document your decision timeline in the breach register
Record not just what happened, but when you learned it and what you decided at each stage. This documentation is crucial for any investigation.
10. Identify the root cause category
Determine whether the breach was due to a test environment with production data, missing access control, or another issue. Your remediation plan depends on identifying the control gap.
Common Mistakes
Waiting for forensic analysis before notifying. Article 33 requires timely notification with available information, not certainty.
Treating test environments as out of scope. If it contains personal data, it's in scope. The Copenhagen breach shows why this assumption is dangerous.
Assuming encryption exempts you from notification. Article 34(3)(a) applies only if the data is genuinely unintelligible to the attacker.
Notifying your Supervisory Authority but not individuals. These are separate requirements. Article 33 is mandatory for most breaches; Article 34 depends on risk.
Next Steps
After your initial 72-hour response:
- File your supplementary report to your Supervisory Authority with complete scope details (Article 33(4)).
- Conduct a formal post-incident review within 30 days.
- Update your Technical and Organisational Measures based on the root cause.
- Review data in non-production environments and implement data sanitization procedures.
- Test your breach response plan with a tabletop exercise that includes the 72-hour constraint.
The Copenhagen breach affected 525,000 people because a test environment contained production data. Your next breach will exploit whatever gap you're not monitoring. This checklist helps you manage the immediate crisis. Preventing the next one requires addressing the systemic issues it exposes.
