Security incident

A security incident is formally distinguished from a security event: an event is any observable occurrence in a system, while an incident is an event, or series of events, that actually or potentially harms confidentiality, integrity or availability or breaches policy, and therefore demands a response. NIST SP 800-61 describes the incident response lifecycle in four phases - Preparation; Detection and Analysis; Containment, Eradication and Recovery; and Post-Incident Activity - run as a loop, with lessons feeding back into preparation. The 2025 revision (Rev. 3) reframes this around the NIST Cybersecurity Framework 2.0 functions (Govern, Identify, Protect, Detect, Respond, Recover). Triage assigns severity and category so that response is proportionate, typically driving an escalation path and, for serious cases, activation of a computer security incident response team (CSIRT) and crisis management.

The consequential part in practice is regulatory reporting, where distinct regimes with different triggers and clocks run in parallel. Under the GDPR, a personal-data breach must be notified to the supervisory authority (in Denmark, Datatilsynet) without undue delay and where feasible within 72 hours of becoming aware (Article 33), and affected individuals must be informed when the breach is likely to result in a high risk to their rights (Article 34); the 72-hour clock and its content requirements are precise. Under NIS2, essential and important entities must send an early warning within 24 hours of becoming aware of a significant incident, a fuller incident notification within 72 hours, and a final report within one month (Directive (EU) 2022/2555, Article 23). In Denmark these NIS2 duties took effect with the NIS2-loven in force from 1 July 2025, with significant-incident reporting handled via Virk.dk and the national CSIRT function. The EU Cyber Resilience Act adds a further product-focused duty for manufacturers to report actively exploited vulnerabilities and severe incidents, with those reporting obligations applying from 11 September 2026.

These regimes overlap but are not interchangeable: the same ransomware event at a Danish hospital can simultaneously be a GDPR personal-data breach, a NIS2 significant incident, each with its own authority, threshold and deadline, which is why incident-response plans pre-map obligations to a decision tree rather than deciding under pressure.

Common misconceptions cause real harm. "Becoming aware" starts the regulatory clock at the point of reasonable certainty that an incident has occurred, not when the full investigation is complete, so waiting for certainty about scope can breach the deadline; regulators expect an initial notification followed by updates. Encryption or a foiled attempt does not automatically remove reporting duties - a thwarted attack can still be a notifiable NIS2 incident, and a data breach affecting availability (such as ransomware) counts even if nothing was exfiltrated. Finally, an incident is not a threat: a threat is a possibility to be assessed in advance, whereas an incident is realised harm that triggers response and, often, statutory timelines.