Data Security, Breach Detection, and Incident Response
Security obligations are outcome-based: appropriate technical and organisational measures proportionate to risk. Know the pillars - confidentiality, integrity, availability, resilience - and typical controls: access control, encryption, pseudonymisation, logging, backups, and staff training. Security is a shared duty: processors must assist controllers.
A personal data breach is any security incident leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure, or access. Detection matters: monitoring, alerting, and clear reporting channels. Response follows a lifecycle: contain, assess, notify, remediate, learn. Notification to the regulator is typically required within 72 hours of awareness where risk to individuals exists; affected individuals must be informed where risk is high. Document all breaches, even those not notified.
Traps
- Confusing awareness with occurrence - the clock starts at awareness.
- Assuming encryption removes notification duties entirely; it may reduce risk but documentation is still needed.
- Forgetting processor-to-controller notification obligations.
- Treating a near-miss as irrelevant; it should feed lessons learned.
Rule of thumb
Use C-A-N-R: Contain the incident, Assess risk to individuals, Notify if thresholds are met within the deadline, Record everything.
Worked example: A laptop with encrypted customer data is stolen. Because encryption protects the data, risk to individuals may be low, so individual notification is likely unnecessary - but the incident is still logged and the regulator notified if residual risk is judged non-trivial.