NIS2 incident reporting: the 24 and 72 hour clocks

NIS2 gives you three deadlines for a significant incident: an early warning within 24 hours of becoming aware of it, an incident notification within 72 hours, and a final report within one month of that notification. A CSIRT or your competent authority can ask for an intermediate status report in between.

That is the whole clock. If you have read somewhere that NIS2 imposes an eight hour reporting deadline, it does not. The numbers are 24, 72 and one month, and they are set out in article 23. It is worth being blunt about that one because the eight hour figure circulates widely and turns a manageable procedure into a panic.

What each stage actually contains

Early warning, within 24 hours

This is deliberately thin. It is a heads up, not an investigation. Where applicable it indicates two things: whether the incident is suspected of being caused by unlawful or malicious acts, and whether it could have cross border impact.

You are not expected to know root cause. You are expected to have picked up the phone.

Incident notification, within 72 hours

This updates the early warning and adds an initial assessment: severity, impact, and where available the indicators of compromise. Still an assessment, not a conclusion.

Trust service providers work to a tighter version of this for incidents affecting their trust services, so check your national act if that is you.

Intermediate report, on request

If the CSIRT or authority asks for status updates, you provide them. There is no fixed cadence; it is driven by whoever is handling it on their side.

Final report, within one month

Note the anchor: one month after the 72 hour notification, not one month after you noticed. It contains a detailed description including severity and impact, the type of threat or root cause likely to have triggered it, the mitigation measures applied and still ongoing, and where applicable the cross border impact.

If the incident is still live when that month is up, you file a progress report at that point, and the final report within one month of finishing your handling of it.

What counts as a significant incident?

Article 23 defines it with two limbs. An incident is significant if either applies:

• it has caused or is capable of causing severe operational disruption of your services, or financial loss for you
• it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage

Read "is capable of causing" carefully. A near miss that could have taken you down qualifies on the plain wording. This is the judgement call your procedure has to make at speed, which is exactly why it should not be made for the first time during an incident.

Some member states are issuing thresholds that put numbers behind those words. In Poland the relevant regulation has not been issued yet, so classification currently rests on the statutory definition alone. If your country has published thresholds, use them. If it has not, write down the reasoning you will apply and keep it with the procedure, so the decision is consistent and defensible rather than improvised.

You may also have to tell your customers

This one gets missed because everyone focuses on the regulator. Where appropriate, you must notify the recipients of your services of significant incidents likely to adversely affect the provision of those services. And where a significant cyber threat is in play, you communicate to potentially affected recipients any measures or remedies they can take themselves.

That is a customer communications duty sitting inside a security regulation. It needs an owner, a channel and a draft, and the person who owns it is usually not the person watching the alerts.

Who actually receives the report?

The recipient is set by national law, which is the recurring theme of this whole topic. It is your CSIRT or your competent authority, and the routing differs by country and sometimes by sector.

Poland is a useful worked example of why you should check rather than assume. Reports go to CSIRT NASK today. A sectoral CSIRT is being stood up at UKE, due by 3 October 2027. And there is no such body as CSIRT Telco, despite the name appearing in circulating summaries. If your procedure names a recipient that does not exist, you will discover it at the worst possible moment.

Building a procedure that survives a Sunday morning

A 24 hour clock starts when you become aware, and awareness does not respect office hours. The procedure that works is short and specific:

1. One named owner and one named deputy for the reporting decision, with contact routes that work at 3am. Not a team alias.
2. A significance test written down as two or three questions, mapped to the two limbs above, so an on call engineer can answer them without a lawyer.
3. The authority, the channel and the form recorded in the procedure itself. Find the actual submission route before you need it.
4. Three prepared templates, one per stage. The 24 hour one should be fillable in ten minutes.
5. A customer notification draft and the decision rule for when it goes out.
6. One rehearsal. Tabletop it once with a plausible scenario and time yourself to the early warning. Most teams find the bottleneck is the decision, not the writing.
7. Keep the artifacts. The timeline, the decision record, the submissions. A regulator asking about an incident twelve months later wants dated evidence, the same way an auditor wants evidence with its source and timestamp intact.

If you already run ISO 27001, controls A.5.24 to A.5.28 give you the detection, assessment, response and learning parts. What they do not give you is the external clock, because ISO never asks you to notify a regulator. That gap, and the three others, are covered in the ISO 27001 to NIS2 comparison.

Where we can help, and where we cannot

AuditBadger has incident management with an anonymous reporting portal and tracking tokens, so the intake and the timeline evidence live in one place alongside your controls. Our incident management module is the part of this we can genuinely take off your plate.

What we do not do is decide for you whether an incident is significant under your national act, or file on your behalf. NIS2 support is early access, switched on per account after a conversation, and the Polish transposition is the one we modelled first. Everything else about the reporting duty is a procedure and a named human, which is unglamorous and exactly why it tends to go unwritten.

If you are not sure the duty even reaches you, start with the scope test. The measure areas, the national divergences and where we are today are on our NIS2 page.