NIS2 incident reporting step by step. Six steps and three deadlines

Reporting an incident under NIS2 is a three-stage procedure with hard deadlines: an early warning within 24 hours, the notification itself within 72 hours, and a final report within one month. All of them run from the moment the incident is detected, not from when it ends or when the cause is established.

Below are six steps, control questions for each, and the list of things that must be ready before anything happens.

Who does this apply to, and when does the clock start?

The reporting duty comes from Article 23 of the NIS2 directive and covers essential and important entities as defined by the national act implementing it. The clock starts at detection, so the first 24 hours usually run out while the team is still working out what actually happened. That is why the procedure is prepared in advance - we covered the wider picture in the article on KSC self-identification, where the register entry opens a twelve-month window for implementing the duties.

Step 1: Classification - is this incident significant?

Not every event goes to the CSIRT. Under the definition applied in Article 23 NIS2, a significant incident is one that causes or is capable of causing severe operational disruption of the service or a serious interruption to it, or that causes considerable material or non-material damage to others.

Control questions: Have we recorded the date and hour of detection? Was the service to customers interrupted or materially degraded? Could the effects reach entities outside our organisation? Does anyone in the company have authority to settle this classification without convening the board?

The hour of detection is the single most important fact in the whole procedure - all three deadlines run from it, and it is the one you have to be able to evidence.

Step 2: Early warning - what goes out within 24 hours?

The first stage, set out in Article 23(4) NIS2, does not require full knowledge of the event. A signal is enough, together with two pieces of information: whether the incident may have been caused by a deliberate act such as a cyberattack, and whether it may affect other EU Member States.

Control questions: Do we know which sectoral CSIRT is competent for us? Do we have access to the S46 system, and who holds it? Is the early warning template prepared, or are we writing it from scratch in the middle of the night? Is anyone authorised to send it without board approval?

The most common reason for missing this stage is not technical but decisional: nobody feels authorised to press the button.

Step 3: Notification - what must it contain within 72 hours?

The second stage is the substantive description: the impact of the incident, its causes, its course and its likely consequences. Trust service providers face a shorter deadline here - 24 hours from detection, not 72.

Control questions: Are we collecting logs and evidence in a way that lets us reconstruct the course of events? Do we know who writes this description and who approves it? Can we estimate the impact on service recipients? Are we separating facts from hypotheses about the cause?

A notification filed on time but without an impact description usually comes back with questions, and eats the time you no longer have.

Step 4: Service recipients - who else has to be told?

The duty does not end with the authority. Article 23(1) NIS2 provides that where an incident may affect the services provided, you have to inform their recipients and point to protective measures they can take on their side.

Control questions: Do we have a channel to customers ready beyond the mail system, which may be the very thing that is down? Do we know who drafts that message? Can we name concrete protective measures rather than only apologise? Does the message pass through someone who understands the legal consequences?

This step tends to be skipped because no hour count is attached to it - and yet it decides how the incident looks from the outside.

Step 5: Final report - what closes the case?

The last stage is filed within one month of the notification. It is the summary: what happened, why, how the handling went, and what was done to stop it recurring.

Control questions: Did we keep a log of actions during the incident, or are we reconstructing them from memory? Do the remedial actions have owners and deadlines? Did the conclusions feed back into procedures and training? Did the authority give us feedback, and did we act on it?

A final report without the remedial section describes a failure but does not show that the organisation learned from it.

Step 6: Preparation - what has to exist beforehand?

Incident handling is one of the risk-management measures listed in Article 21(2) NIS2, and management bodies are accountable for its implementation under Article 20. Every step above is only achievable on time if it was prepared before the event. Before an incident happens, the organisation should hold:

• an incident handling procedure with a clear classification threshold;
• the competent sectoral CSIRT identified, and S46 access for at least two people;
• templates for the early warning, the notification and the final report;
• a list of roles with deputies: who classifies, who files, who talks to customers;
• a fallback communication channel in case the primary one is unavailable;
• an incident register that is filled in as things happen, not afterwards.

A procedure the team has never rehearsed works, in practice, like having none.

On your own, or with a tool?

The procedure can be written up and kept on the intranet. The problem is upkeep: people, roles and access rights change, and once a year it is worth running a dry test to see whether anyone actually knows where to click.

That part is what Cyber TrustCERT handles: procedure and policy templates, training separately for staff and for management, and records showing who completed what. If you are not sure whether the rules cover you at all, the Cyber Ready Check gives a preliminary reading in a few minutes, computed in your own browser.

Summary

NIS2 incident reporting comes down to six steps and three deadlines: classification with the hour of detection recorded, an early warning in 24 hours, the notification in 72 hours, information for service recipients, the final report within a month, and the preparation without which the rest is theory.

The clock starts at detection, not at the point where the situation becomes clear. An organisation with a ready procedure and templates makes it. An organisation that starts by asking who is actually allowed to send this usually does not.

This text describes the procedure but does not settle whether a given organisation is covered, nor whether a particular event is a significant incident - both calls stay with the organisation.

✦ This article was written with the help of artificial intelligence and reviewed before publication by the author, who takes editorial responsibility for it.