ISO Compliance Insights & Best Practices

NIS2 Incident Reporting: A Clear Guide to the 3 Deadlines

NIS2 incident reporting runs on three clocks that start from two different events, and most of the mistakes organizations make come from assuming they all start together. Under Article 23 of Directive (EU) 2022/2555, an essential or important entity must send an early warning within 24 hours of becoming aware of a significant incident, a full incident notification within 72 hours of becoming aware, and a final report within one month of submitting that notification — not one month of awareness. This guide sets out the three deadlines and what each submission has to contain, explains how “significant” is defined and where the Commission has set hard thresholds, and covers the duties the reporting rules attach to that are easy to miss: notifying your own customers, and the cross-border notifications the CSIRT will make on your behalf.

NIS2 incident reporting: three deadlines anchored to two events — 24 hours and 72 hours run from awareness; the one-month final report runs from the 72-hour notification.

Who NIS2 incident reporting applies to

Article 23 applies to every essential and important entity — both classes, identically. The classification in Article 3 changes supervision and penalties, not the reporting duty: essential entities face ex-ante supervision under Article 32 and fines of at least €10 million or 2% of worldwide turnover, important entities face ex-post supervision under Article 33 and at least €7 million or 1.4%, but both owe the same three reports on the same clocks. Our guide to who NIS2 applies to explains the two classes; the penalties post covers the fines.

The obligation is national. Member States had to transpose the Directive by 17 October 2024 and apply their measures from 18 October 2024, and the reporting goes to the national CSIRT or competent authority the transposing law names, on the form and platform it specifies. The Directive sets the minimum; some national laws add fields, shorter internal deadlines or additional recipients.

What counts as a significant incident for NIS2 incident reporting

Only significant incidents are reportable. Article 23(3) gives the test: 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 if it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. “Capable of” matters — the duty attaches to potential impact, not only realized impact, which is why the early warning exists.

For eleven types of digital entity the Commission replaced that judgement with numbers. Implementing Regulation (EU) 2024/2690 of 17 October 2024 applies to DNS service providers, TLD name registries, cloud computing, data centre and CDN providers, managed service and managed security service providers, online marketplaces, search engines, social networking platforms and trust service providers. Its Article 3 makes an incident significant where any of the following applies:

Criterion	Threshold in Regulation 2024/2690
Financial loss	Direct financial loss exceeding €500,000 or 5% of annual turnover in the preceding financial year, whichever is lower
Trade secrets	Exfiltration of the entity’s trade secrets as defined in Directive (EU) 2016/943
Health	Death of a natural person, or considerable damage to a natural person’s health
Malicious access	Successful, suspectedly malicious and unauthorized access to network and information systems capable of causing severe operational disruption
Recurring incidents (Article 4)	Incidents with the same apparent root cause that individually miss the thresholds but together, within six months, meet the financial-loss criterion
Sector-specific availability (Articles 5–14)	Per entity type — for DNS, for example, name resolution unavailable for more than 30 minutes, or response times above 10 seconds for more than an hour, or integrity issues affecting 1,000 domains or 1% of the portfolio

Entities outside those eleven types apply the Article 23(3) test under national guidance. Either way, write the criteria into the incident procedure so that the significance decision is made by rule, on the record, and quickly — because the 24-hour clock is already running while you decide.

The three NIS2 incident reporting deadlines

Submission	Deadline	Anchored to	Must contain (Article 23(4))
Early warning	Without undue delay and in any event within 24 hours	Becoming aware of the significant incident	Where applicable: whether the incident is suspected to be caused by unlawful or malicious acts, and whether it could have a cross-border impact
Incident notification	Without undue delay and in any event within 72 hours	Becoming aware of the significant incident	Updates the early warning; an initial assessment of the incident’s severity and impact, and the indicators of compromise where available
Intermediate report	On request of the CSIRT or competent authority	The request	Relevant status updates
Final report	Not later than one month	Submission of the incident notification	A detailed description of the incident, its severity and impact; the type of threat or root cause likely to have triggered it; applied and ongoing mitigation measures; where applicable, the cross-border impact
Progress report, then final	Progress report at the one-month point; final within one month of handling the incident	Where the incident is still ongoing at the final-report deadline	As for the final report, on completion

The anchor trap

The 24-hour and 72-hour clocks run from awareness. The one-month clock for the final report runs from the day the 72-hour notification was submitted, so an entity that submits its notification at hour 70 has until roughly day 34 from awareness, and one that submits at hour 20 has until day 31. Procedures that write “final report within one month of the incident” are wrong on the face of the Directive — and, in practice, early. Trust service providers have a shorter second clock: Article 23(4) requires them to submit the incident notification for significant incidents affecting their trust services within 24 hours of becoming aware, not 72.

What “aware” means

The Directive does not define awareness, and national laws vary. The defensible reading is the point at which the entity has enough information to judge the incident significant, which is why the significance criteria need to be in the procedure: an entity that has the facts but has not applied the test is aware. Logging the timestamp of the significance decision, and the facts it was based on, is the single most useful record in a later dispute about whether the 24 hours were met.

Notifying your own service recipients

Article 23(1) also requires entities, where appropriate and without undue delay, to notify the recipients of their services of significant incidents that are likely to adversely affect the provision of those services. Article 23(2) adds a separate duty: where a significant cyber threat exists that could affect recipients, entities must inform the recipients potentially affected of measures or remedies they can take in response, and where appropriate of the threat itself. Neither duty has a fixed clock, but both are enforceable, and the CSIRT will ask what customers were told and when. Build the customer notification template alongside the regulator template.

What the CSIRT does after you report

NIS2 incident reporting is two-way. Under Article 23(5), the CSIRT or competent authority must respond to the early warning without undue delay and in any event within 24 hours with initial feedback and, on request, guidance or operational advice on possible mitigation measures. Where the incident affects other Member States, Article 23(6) requires the CSIRT to inform its counterparts and ENISA, and Article 23(7) allows the authority to inform the public where public awareness is necessary to prevent or handle the incident, or is otherwise in the public interest — after consulting the entity. Under Article 23(8), the entity can be required to inform the public itself. The cross-border and public-disclosure paths are why the early warning asks about cross-border impact and unlawful acts: they decide who else gets told.

Building the NIS2 incident reporting procedure

Write the significance test into the procedure. Use the Regulation 2024/2690 numbers if you are one of the eleven digital types; otherwise write your own quantified version of Article 23(3) — hours of disruption, euros of loss, number of affected persons — so the decision is fast and recorded.
Define awareness and log it. Name the role that makes the significance decision, require the timestamp and the facts, and start the 24-hour clock from it.
Prepare three templates plus the customer notice. Early warning, incident notification and final report, each with the Article 23(4) fields, plus the customer notification under 23(1) and the threat advisory under 23(2). Pre-fill the entity identification fields.
Know the national platform. Register on the CSIRT’s reporting portal before the incident; the 24 hours is not the time to discover an onboarding process.
Align with other regimes. A financial entity under DORA has its own clocks — initial within 4 hours of classification and 24 hours of awareness, intermediate 72 hours after the initial, final within one month — and DORA takes precedence for those entities. GDPR’s 72-hour breach notification to the supervisory authority runs in parallel where personal data is involved. One incident, one timeline, several outputs. Our guide to DORA incident reporting covers the financial-sector clocks.
Rehearse it. Management bodies are liable under Article 20 for the Article 21 measures, and incident handling is Article 21(2)(b). A tabletop exercise that runs the three reports to the clock is the evidence that the procedure works.

Our overview of NIS2 compliance covers the ten Article 21 measures the NIS2 incident reporting procedure sits inside.

Frequently asked questions

What are the NIS2 incident reporting deadlines?
Early warning within 24 hours of becoming aware; incident notification within 72 hours of becoming aware; final report within one month of submitting the incident notification. Intermediate reports on request; a progress report instead of a final report if the incident is still ongoing.

Do important entities have to report incidents?
Yes. Article 23 applies identically to essential and important entities. The classification changes supervision and fine levels, not the reporting duty.

What makes an incident significant?
Severe operational disruption or financial loss for the entity, or considerable damage to other persons, actual or potential (Article 23(3)). For eleven digital entity types, Regulation 2024/2690 sets hard thresholds — for example a direct financial loss above €500,000 or 5% of turnover, whichever is lower.

Does the one-month final report run from the incident?
No. It runs from submission of the 72-hour incident notification. Writing it as one month from the incident makes the internal deadline earlier than the law requires, which is safe but wrong.

Do we also have to tell our customers?
Where appropriate, yes, without undue delay, for significant incidents likely to adversely affect service provision (Article 23(1)); and separately, for significant cyber threats, the measures or remedies recipients can take (Article 23(2)).

Where this leaves you

NIS2 incident reporting is a procedure problem before it is a security problem. Quantify the significance test, define and log awareness, hold three pre-filled regulator templates and a customer notice, register on the national portal, and rehearse the clocks. Do that and the 24 hours is a routine rather than a scramble.

References

Directive (EU) 2022/2555 (NIS2), Article 23 — Reporting obligations, on EUR-Lex.
Commission Implementing Regulation (EU) 2024/2690 — Significance thresholds for DNS, cloud, data centre, CDN, managed service, marketplace, search, social network and trust service providers.