Security, breaches and incident reporting

Security of processing

Article 32 requires technical and organisational measures appropriate to the risk, taking into account the state of the art, the costs of implementation, and the nature, scope, context and purposes of processing. Examples include pseudonymisation and encryption; the ability to ensure the ongoing confidentiality, integrity, availability and resilience of systems; the ability to restore access to data in a timely manner after an incident; and regular testing of how effective the measures are.

Personal data breaches

A personal data breach is a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. The controller must notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to individuals (Article 33). Where the breach is likely to result in a high risk, the individuals must also be told without undue delay (Article 34). Processors must notify the controller without undue delay. Every breach — notified or not — must be documented.

Parallel reporting regimes

One incident can start several clocks. Under NIS2, essential and important entities send an early warning of a significant incident within 24 hours, a notification within 72 hours and a final report within one month. DORA sets its own major ICT-related incident reporting for financial entities, and the Cyber Resilience Act requires manufacturers to report actively exploited vulnerabilities and severe incidents through ENISA’s single reporting platform, starting with an early warning within 24 hours. The DPO should make sure the incident plan maps every clock that applies, and who decides.