Incident reporting: the 24-hour, 72-hour and final reports
NIS2 requires essential and important entities to report "significant incidents" to their national competent authority or CSIRT according to a strict timeline. This involves an early warning within 24 hours, a formal incident notification within 72 hours, and a detailed final report following the resolution of the event.
What it means
The intent is to provide European authorities with real-time situational awareness to prevent systemic risks across member states. Not every security event must be reported; the obligation applies specifically to "significant incidents"—those that cause severe operational disruption or have a significant impact on other persons or entities.
In practice, this creates a tiered reporting requirement. The first report is a rapid alert to signal an ongoing issue; the second provides a technical assessment and initial indicators of compromise; the third serves as a post-mortem analysis to ensure lessons are learned and vulnerabilities closed.
How to meet it
- Define "significant incident" within your internal Incident Response Plan (IRP) based on thresholds such as downtime, data loss volume, or impact on critical services.
- Establish a direct communication channel and contact directory for the relevant national CSIRT or competent authority.
- Develop standardized reporting templates for each of the three stages to ensure all required information is captured under pressure.
- Implement an internal "triage" process that triggers the 24-hour clock immediately upon the discovery of a potentially significant incident.
- Train your Security Operations Center (SOC) and legal teams on the specific differences between the early warning, notification, and final report requirements.
- Integrate these reporting deadlines into your existing Incident Response Playbooks to ensure they are not overlooked during remediation efforts.
Evidence an auditor asks for
- The documented Incident Response Plan showing a defined workflow for NIS2 reporting timelines.
- A "Significant Incident" criteria document or matrix used to determine when a report is triggered.
- Logs of all security incidents, including those deemed *not* significant and the justification for that decision.
- Copies of submitted reports (or timestamps/acknowledgments) from previous incidents proving adherence to the 24h/72h windows.
- Training records confirming that staff responsible for reporting are aware of these specific deadlines.
Common pitfalls
- Over-reporting: Treating every minor alert as a "significant incident," leading to administrative burden and potential friction with regulators.
- Internal Bottlenecks: Requiring multiple layers of management approval before the 24-hour early warning is sent, causing the deadline to be missed.
- Lack of Detail in Final Reports: Providing a superficial summary instead of a root cause analysis and evidence of corrective actions.
- Confusion over "Awareness": Failing to define exactly when an organization is considered "aware" of an incident, leading to disputes over whether the 24-hour clock has started.