Incident reporting

NIS2 Article 23(4) sets a staged model for significant incidents. An early warning goes to the CSIRT or competent authority without undue delay and in any event within 24 hours of becoming aware, indicating whether the incident is suspected to be caused by unlawful or malicious acts and whether it could have a cross-border impact. An incident notification follows within 72 hours, updating the early warning with an initial assessment of severity and impact and, where available, indicators of compromise. An intermediate report can be requested on the status of the incident, and a final report is due no later than one month after the incident notification, describing the incident, its severity and impact, the type of threat or root cause, the mitigation measures applied and any cross-border impact. If the incident is still ongoing at that point, a progress report is submitted instead and the final report follows within a month of handling it. In Denmark, reports under the NIS2 law are submitted via Virk.dk.

Other regimes run in parallel with different triggers and clocks. GDPR Article 33 requires notification of personal data breaches to the supervisory authority within 72 hours where feasible. DORA, applicable to financial entities since 17 January 2025, requires an initial notification of a major ICT-related incident within 4 hours of classifying it as major and no later than 24 hours after becoming aware of it, an intermediate report within 72 hours and a final report within one month. The Cyber Resilience Act's Article 14, applicable since 11 September 2026, requires manufacturers to report actively exploited vulnerabilities and severe incidents affecting their products through ENISA's single reporting platform, with a 24-hour early warning, a 72-hour notification and a final report. These obligations are cumulative, so one ransomware attack on a bank's customer platform may generate GDPR, DORA and possibly NIS2 reports to different recipients.

Operationally, reporting depends on three things decided in advance: who assesses whether a threshold is met, who is authorised to submit each report, and where the facts come from. The incident log, with timestamps of detection, awareness, classification and key actions, is the evidence for when each clock started. The staged design assumes that early reports are incomplete and later updated; waiting for a complete picture before reporting misses the deadline, whereas an early report that states its uncertainties is what the regime intends.

Internal reporting is the first link in the chain. Staff need a simple, well-known channel to report suspicious events, and service desks and suppliers need contractual deadlines for passing incidents on, since slow internal hand-offs eat into regulatory deadlines that are counted from the moment the organisation is deemed aware. Voluntary reporting of near misses and cyber threats is also possible under NIS2 Article 30.