NIS2
NIS2 Incident Reporting Timeline
Article 23 replaces vague 'notify without undue delay' language with a strict, multi-stage timeline. Once an entity becomes aware of a significant incident, three separate submissions are due — and the clock starts at awareness, not at containment or root-cause confirmation.
| Stage | Deadline | What you submit |
|---|---|---|
| Early warning | Within 24 hours | A brief notification stating whether the incident is suspected to be caused by unlawful or malicious acts, whether it could have cross-border impact, and — if known — the initial assessment. No analysis is expected at this point. |
| Incident notification | Within 72 hours | An update to the early warning with an assessment of severity and impact, indicators of compromise where available, and any correction of what was reported at 24 hours. |
| Final report | Within 1 month of the incident notification | A detailed description of the incident including its severity and impact, the type of threat or root cause, the mitigation measures applied and in progress, and any cross-border impact. If the incident is still ongoing at one month, you submit a progress report and the final report within one month of handling being completed. |
The CSIRT or competent authority responds to the early warning within 24 hours where possible, with feedback and — on request — technical guidance and advice on possible mitigation. Reporting is designed as a two-way channel, not only an obligation.
What counts as a significant incident
Article 23(3) defines an incident as significant if either of two conditions is met:
- it has caused, or is capable of causing, severe operational disruption of your services or financial loss to your organisation; or
- it has affected, or is capable of affecting, other natural or legal persons by causing considerable material or non-material damage.
Note the phrase "capable of causing". A contained intrusion that could have taken down a critical service can be reportable even when nothing ultimately failed. For DNS providers, cloud and data centre services, online marketplaces, search engines and social networking platforms, Commission Implementing Regulation (EU) 2024/2690 sets quantitative thresholds — for example service unavailability measured in hours or a defined share of users affected. Sector-specific national guidance fills in the rest, and this is precisely the judgement call worth deciding in advance rather than at 02:00 during an incident.
Practical tip
The 24-hour early warning is deliberately low-bar: a handful of fields, no root cause, no impact quantification. Speed matters far more than completeness at that stage, and an early warning can be corrected in the 72-hour notification without penalty. Teams that wait for a clear picture before the first submission are the ones that miss the deadline. Pre-fill the form fields you can, name the person authorised to submit it out of hours, and treat "are we sure it's significant?" as a reason to file, not to wait.