Data breach prevention checklist (GDPR Art. 32 & 33/34)
A personal data breach is any security incident leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure, or access to personal data (Art. 4(12)). Under the GDPR, prevention is a duty (Art. 32) and response is on a strict clock (Arts. 33–34). The good news: most breaches are preventable with proportionate, documented controls — and detecting where PII lives is the first step. This checklist is for small teams that want defensible, not perfect, security.
1. The legal framework
- Art. 32 — security of processing: "appropriate technical and organisational measures" proportionate to risk, explicitly including pseudonymisation and encryption, confidentiality/integrity/availability/resilience, the ability to restore availability after an incident, and regular testing of effectiveness (GDPR.eu — Art. 32).
- Art. 33 — notify the supervisory authority without undue delay and, where feasible, within 72 hours if the breach is likely to risk individuals' rights; the processor notifies the controller without undue delay; document every breach even if not reported.
- Art. 34 — notify affected individuals without undue delay if the breach is likely to result in a high risk to them; not required where effective technical/organisational protection measures were already in place.
2. Preventive controls (the checklist)
| Control | Why it matters |
|---|---|
| Encryption in transit (TLS) and at rest | Renders intercepted or stolen data unusable; can remove the Art. 34 individual-notification duty |
| Pseudonymisation / tokenisation | Reduces identifiability of stored data (Art. 32) |
| Access control & least privilege | Limits who can reach personal data; MFA on all access |
| Logging & monitoring | Detects exfiltration and supports the 72-hour clock |
| Vendor DPAs (Art. 28) | Contracts limit secondary use by processors |
| Retention limits & deletion | Less data retained = smaller breach blast radius |
| Backups & restore tests | Availability after ransomware or loss |
| Staff training | Most breaches trace to human error or phishing |
| Documented incident-response plan | Decides containment, assessment, and notification fast |
3. Response workflow (Arts. 33–34)
- Detect & contain — isolate affected systems, revoke credentials, preserve logs.
- Assess risk — who, what data, likelihood and severity of harm (the Art. 34 high-risk test).
- Notify the SA within 72 hours if risk to rights is likely; late notices state reasons (Art. 33).
- Notify individuals if the risk is high and no effective protective measure applies (Art. 34).
- Document everything — facts, effects, remediation (Art. 33(5)), even for non-reported breaches.
- Review — feed lessons into your privacy risk assessment and GDPR compliance program.
4. Don't forget the cookie/consent surface
A consent or tracker misconfiguration is itself a leakage path: a non-essential script firing before consent, or a pixel sending PII to an undisclosed third party, can be a breach of Art. 5/6 as much as a database leak. Keep your cookie consent setup in the same security review.
Decision-support note. PrivScan can surface likely exposure points — undisclosed trackers, missing consent controls, and data-collection fields — that enlarge your breach blast radius, and returns a prioritized checklist. It is a scanner, not a security auditor, and does not satisfy Art. 32 on its own.