NIS2's incident reporting rules are short, and the deadlines in them are firm: 24 hours, 72 hours, one month. Teams tend to remember the numbers and forget what starts each clock, what each report must contain, and that the reports go to a national body under national law.
Getting this wrong has two forms. Some teams report nothing because they are still debating whether the incident is significant. Others report everything, burying the authority in noise and their own staff in paperwork.
This article covers Article 23 of Directive (EU) 2022/2555: what makes an incident significant, the reporting stages as the directive states them, who else needs to hear from you, and how to run the process so the deadlines are met without guesswork.
What makes an incident significant
Only significant incidents must be reported. Article 23(3) says an incident is significant if it:
Has caused or is capable of causing severe operational disruption of the services, or financial loss, for the entity concerned; or
Has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.
Two words do a lot of work here. "Capable" means an incident can be significant before the damage occurs. A ransomware infection contained before encryption may still qualify if it was capable of severe disruption. "Severe" and "considerable" are not defined in the directive, which is why national authorities and, for some entity types, EU rules add detail.
For certain digital providers, including cloud computing, data center, managed service and managed security service providers, a Commission implementing regulation specifies when an incident counts as significant. If you are one of those types, apply its criteria rather than your own reading of Article 23(3). For other entities, check whether your national authority has published guidance or thresholds.
Write your significance test down before you need it. A short decision record per incident, with the criteria considered and the answer, is the evidence that you assessed the incident rather than ignored it.
The reporting stages, as the directive states them
Article 23(4) sets out the stages. Each report goes to your CSIRT or, where applicable, your competent authority, depending on how your member state has organized this.
Early warning: within 24 hours
Without undue delay, and in any event within 24 hours of becoming aware of the significant incident, you submit an early warning. Where applicable, it indicates whether the incident is suspected of being caused by unlawful or malicious acts, or could have a cross-border impact.
The early warning is deliberately thin. It exists so the authority knows something is happening. Do not hold it back to gather detail you are not required to give yet.
Incident notification: within 72 hours
Without undue delay, and in any event within 72 hours of becoming aware of the significant incident, you submit an incident notification. Where applicable, it updates the early warning and gives an initial assessment of the incident, including its severity and impact, and indicators of compromise where available.
Intermediate report: on request
At the request of the CSIRT or competent authority, you provide an intermediate report on relevant status updates.
Final report: within one month of the notification
No later than one month after submitting the incident notification, you submit a final report. It includes:
A detailed description of the incident, including its severity and impact.
The type of threat or root cause that is likely to have triggered it.
Applied and ongoing mitigation measures.
Where applicable, the cross-border impact.
Progress report: if the incident is still running
If the incident is ongoing when the final report is due, you submit a progress report at that time, and a final report within one month of your handling of the incident.
Trust service providers have a shorter notification deadline for significant incidents affecting their trust services: the incident notification is due within 24 hours of becoming aware.
When the clock starts
The 24-hour and 72-hour deadlines run from becoming aware of the significant incident. That is not the same as the first alert, and it is not the same as the end of your investigation.
A practical reading is that awareness begins when you have reasonable grounds to conclude a significant incident has occurred. The earlier in your process that conclusion is possible, the earlier the clock starts. That argues for a quick significance decision, not a slow one. Delaying the decision to delay the clock is the pattern supervisors look for.
How your national law and authority interpret awareness is a point to confirm with counsel. Record the time you reached the conclusion and who reached it. That timestamp anchors every deadline that follows.
The final report deadline runs from a different anchor: the submission of the incident notification. Track both anchors in the incident record.
Who else needs to hear from you
Reporting to the authority is not the only duty in Article 23.
Recipients of your services. Where appropriate, entities notify the recipients of their services, without undue delay, of significant incidents likely to adversely affect the provision of those services.
Recipients facing a significant cyber threat. Where applicable, entities tell recipients potentially affected by a significant cyber threat about measures or remedies they can take in response, and, where appropriate, about the threat itself.
Other regimes. The same incident can trigger other duties. A personal data breach also engages the GDPR's 72-hour notification to the supervisory authority under Article 33, covered in GDPR breach notification and the 72-hour clock. The two run in parallel, to different authorities, on different tests. Financial entities under DORA follow DORA's reporting regime instead, described in DORA incident reporting.
The directive also sets duties for the authority. The CSIRT or competent authority provides a response to the entity without undue delay and, where possible, within 24 hours of receiving the early warning, including initial feedback and, on request, guidance or operational advice. The directive also states that notification alone does not subject the notifying entity to increased liability.
Running the process so deadlines are met
The deadlines are achievable when the decisions are made in advance. A workable sequence:
Name the decision maker. One role, with a deputy, decides whether an incident is significant. Both have authority to file an early warning without further sign-off.
Pre-register with the reporting channel. Know your CSIRT or authority's portal, form and contact details in every member state where you report. Test access before an incident.
Template each stage. Prepare early warning, notification and final report templates with the fields the directive and your national form require.
Timestamp the awareness decision and calculate the 24-hour, 72-hour and one-month deadlines on the spot.
Assign the customer communication owner for recipient notifications, with pre-approved wording for common scenarios.
Check parallel duties. Run the GDPR test, and any sector or contractual notification duties, in the same meeting.
Keep the evidence pack. Each report submitted, with its submission confirmation and time, the significance decision, and recipient notices.
Rehearse. Include the reporting steps in a tabletop exercise, with a clock running.
Incident handling is one of the Article 21 measures. Reporting is where that measure meets the authority, and it is judged on dates. The NIS2 framework page places Article 23 within the directive's structure.
How TrustLynce helps
TrustLynce's continuous monitoring routes control failures to their owners, which supports the detection and decision steps. Policy management versions your incident response and reporting procedures and tracks which staff have accepted them.