NIS2 introduces a multi-stage incident reporting framework that is more demanding than NIS1. The regulation distinguishes between "significant incidents" that must be reported and minor incidents that do not. For significant incidents, there are three distinct reporting stages with specific deadlines — and the timelines are tight.
This article explains the NIS2 incident reporting requirements precisely.
What Is a "Significant Incident"?
Not every security event is a reportable NIS2 incident. The reporting obligation applies to significant incidents — those that:
- Have or could have significant impact on the provision of services
- Result in severe operational disruption or financial loss
- Have affected or are capable of affecting other natural or legal persons by causing considerable material or non-material damage
Indicators of a significant incident:
- Affects a large number of users of the service
- Involves a critical dependency (the service is used by other essential/important entities)
- Long duration of service disruption
- Geographic spread affecting multiple member states
- Causes or is likely to cause significant material damage
- Results from an intentional malicious attack
The ENISA and national authorities provide guidance on thresholds, but the core test is: would a disruption to this service have a meaningful impact on society, the economy, or individuals?
The Three-Stage Reporting Process
Stage 1: Early Warning — Within 24 Hours
Within 24 hours of becoming aware of a significant incident, you must submit an early warning to:
- Your national CSIRT (Computer Security Incident Response Team), and/or
- Your national NIS2 competent authority
The early warning is not a full report. It is a notification that a significant incident has occurred or is occurring. It should include:
- Whether the incident is suspected to be caused by an unlawful or malicious act
- Whether the incident has or is likely to have cross-border impact
The purpose of the early warning is to give national authorities rapid visibility so they can coordinate a response if needed.
Stage 2: Incident Notification — Within 72 Hours
Within 72 hours of becoming aware of the incident, submit a more detailed incident notification to the CSIRT or competent authority. This notification should include:
- An initial assessment of the incident's severity and impact
- The indicators of compromise (where available)
- Any immediate measures taken or proposed
This is analogous to the GDPR 72-hour breach notification, but note: NIS2 incident reporting is separate from GDPR breach notification. An incident that triggers both may require two separate notifications (to the NIS2 authority and to the data protection authority).
Stage 3: Final Report — Within One Month
Within one month of submitting the incident notification, submit a final report to the CSIRT or competent authority. The final report must include:
- A detailed description of the incident — what happened, when, how
- The type of threat or root cause
- Mitigating measures applied
- The cross-border impact of the incident, if applicable
For complex, ongoing incidents, an interim report may be requested by the authority before the final report is due.
Who Receives the Reports?
Reports go to your national CSIRT and/or national competent authority. In practice, most member states have designated a single point of contact for NIS2 reporting.
If an incident affects services in multiple member states, you should notify authorities in each affected member state — or use the coordination mechanism through your lead member state authority.
Notification of Affected Service Customers
Where a significant incident could adversely affect service users, the entity must notify them of the incident and of the measures they can take to mitigate adverse effects. This customer notification is separate from the authority notification and should happen promptly when impact on users is identified.
NIS2 vs GDPR Incident Reporting: Key Differences
| Aspect | NIS2 | GDPR |
|---|---|---|
| What triggers reporting | Significant incident to service | Personal data breach |
| Recipient | National CSIRT / competent authority | Supervisory DPA (e.g., ICO, CNIL) |
| Timeline — Stage 1 | 24 hours (early warning) | No equivalent |
| Timeline — Stage 2 | 72 hours (notification) | 72 hours (breach notification) |
| Timeline — Final | 1 month (final report) | Not required |
| Individual notification | Service users where impacted | Affected individuals for high-risk breaches |
An incident may trigger both. A cyberattack that compromises customer personal data and disrupts services requires:
- NIS2 early warning within 24 hours
- NIS2 incident notification within 72 hours
- GDPR breach notification within 72 hours (to the DPA)
- Customer notification under NIS2 (where services are affected)
- GDPR individual notification (if high-risk to individuals)
Building Your Incident Reporting Procedure
Your NIS2 incident response procedure must support the three-stage reporting timeline. Key elements:
Detection and triage:
- How incidents are detected and initially classified
- Criteria for "significant incident" determination
- Escalation path to the person authorised to make notification decisions
24-hour early warning capability:
- Who is responsible for submitting the early warning
- Contact details for the relevant CSIRT/competent authority
- Template for the early warning message
72-hour notification capability:
- Format and fields required for the notification
- Process for gathering impact assessment information quickly
30-day final report:
- Root cause analysis process
- Reporting template aligned with authority requirements