NIS2 Incident Reporting: Meeting 24 and 72 Hours

NIS2's reporting deadlines start when you become aware of a significant incident, not when the working week starts. Here is how to build a procedure that meets them.

Article 23 of NIS2 sets three reporting deadlines for significant incidents. An early warning within 24 hours of becoming aware, an incident notification within 72 hours, and a final report within one month. ISO 27001 and most frameworks require incident management, but none requires notifying a regulator on that clock. Here is how to build a procedure that meets it.

The three reports

Report	Deadline	Content
Early warning	24 hours from awareness	Whether the incident is suspected to be malicious, and whether it could have cross-border impact
Incident notification	72 hours from awareness	An update, an initial assessment of severity and impact, and indicators of compromise where available
Final report	One month after the notification	Detailed description, likely root cause, mitigation applied and ongoing, cross-border impact

The authority can also ask for intermediate updates, and if the incident is still ongoing at one month you give a progress report and a final report within a month of handling it.

Step 1: define "significant" for your organisation

The test in Article 23(3) is broad: severe operational disruption or financial loss, or considerable damage to others. For certain digital providers, the Implementing Regulation sets more specific criteria. Turn them into a short decision checklist your on-call lead can apply in minutes, with examples, and say clearly that when in doubt, you send the early warning.

Step 2: name the people

Who decides significance (and a deputy, at any hour).
Who submits to the CSIRT or authority, with access to the reporting portal tested in advance.
Who approves the content, without making approval a bottleneck. An early warning needs little detail.
Who informs management, who under Article 20 are accountable.

Photograph of a phone face down on a bedside table beside a lamp and a glass of water in a dark room — The 24-hour clock doesn't wait for office hours.

Step 3: connect it to your incident process

Add a reporting decision point to your existing incident response plan: at triage, ask "could this be significant?", and start the clock log there. Record the time of awareness carefully; it's the moment every deadline is measured from.

Step 4: coordinate the other clocks

A significant incident often triggers more than one obligation:

GDPR: notify the supervisory authority within 72 hours if personal data is breached (Article 33).
Contracts: customer notification terms, often 24 to 72 hours.
Other regimes: payment brands for card data, sector regulators, and DORA for financial entities.

One coordinator should own the list, so no clock is missed because another team assumed it was theirs.

Step 5: templates and practice

Prepare templates for each of the three reports with the required fields, pre-filled with company details. Then run an exercise at least once a year, ideally starting on a Friday evening, and time it.

A practice scenario

To test the procedure, run a short exercise like this, ideally starting late on a Friday:

Hour 0: monitoring flags unusual encryption activity on a file server that supports a customer-facing service.
Hour 2: the on-call engineer confirms ransomware on several servers; the service is degraded for some customers.
Decision point: is this significant? Apply your checklist and record the decision and time.
Before hour 24: submit an early warning using the template, noting suspected malicious activity and possible cross-border impact.
Before hour 72: submit the notification with an initial assessment and indicators of compromise.
Parallel clocks: does personal data trigger GDPR notification? Do contracts require customer notice?

Time each step. The gaps you find (who has portal access, who can approve, where the templates are) are the procedure's real weaknesses.

Keep the records

Log every incident you assessed for significance, including those you decided not to report, with the reasoning. Supervisors will ask how you decide, not just what you reported.

The Incident Response and Reporting topic pages compare requirements across frameworks, and the NIS2 guide covers the rest of the regulation.

Questions

What counts as a significant incident under NIS2?

Under Article 23(3), an incident that has caused or can cause severe operational disruption or financial loss to the entity, or that has affected or can affect others by causing considerable material or non-material damage. The Implementing Regulation sets more specific thresholds for certain digital providers.

Who do you report to under NIS2?

The national CSIRT or competent authority designated under your member state's NIS2 law. Some countries use a single reporting point.

Data as of 2026-10-27: numbers in this post are computed from the current crosswalk and update when it changes. Crosswalk a published crosswalk (NIST, ENISA, CIS, PCI SSC) makes the link · Editorial ControlMapping's judgement where no crosswalk exists; the reason is shown · only shares a CSF 2.0 outcome: worth checking, not a mapping · No mapping in our data nothing mapped in our data; often new work, but check the coverage notes. Not compliance advice.

Building an incident reporting procedure for the NIS2 24- and 72-hour deadlines