NIS2 Incident Reporting: The 24-72-30 Day Timeline Explained

Article 23 NIS2 imposes the most prescriptive incident reporting regime ever placed on network and information system operators in the EU. Three stages, hard deadlines, and a clock that starts the moment you "become aware" — a definition that creates strong incentives to monitor your own systems rather than wait for someone else to tell you something is wrong.

This article explains what each stage contains, where the clock actually starts, who you report to, and the pitfalls that catch real SMEs. For the broader context, start with the complete NIS2 and DORA compliance guide.

This is not legal advice. National transpositions vary on some points — Cyprus, for example, requires a six-hour early warning rather than 24 hours. Always verify against your national competent authority's published guidance.

The three stages at a glance

Stage	Deadline	What goes in it
Early warning	Within 24 hours of awareness	Brief alert; whether the incident is suspected of being unlawful/malicious; whether it could have cross-border impact
Incident notification	Within 72 hours of awareness	Initial assessment of severity and impact; indicators of compromise where available; update of the early warning
Final report	Within one month of the notification	Detailed description, root cause, mitigation measures applied, cross-border impact

A trust service provider has a different deadline at stage two: it must notify within 24 hours, not 72, for incidents affecting its trust services. This is the only derogation built directly into Article 23.

Two other things to know before you read the detail. Significant incidents trigger the obligation, not every event — the definition is precise and we'll cover it below. And the CSIRT or competent authority must reply to your early warning, with guidance where possible, within 24 hours. Article 23 is not a one-way reporting channel.

What counts as a "significant" incident?

Article 23(3) NIS2 defines a significant incident as one that meets either of two thresholds:

• It has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned
• It has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage

The word "capable" matters. You report incidents that could have caused severe disruption even if they did not in fact do so. Near-misses that crossed your detection threshold but were contained before reaching production are typically below the significance bar; near-misses that could have caused severe disruption if not for last-minute containment are typically above it. The Commission Implementing Regulation (EU) 2024/2690 specifies quantitative significance criteria for certain entity types (DNS providers, cloud computing service providers, and others). For most other entities, member state competent authorities issue their own guidance.

When in doubt, report. The cost of an unjustified early warning is approximately zero. The cost of an unreported significant incident is up to €10 million or 2% of global turnover.

Stage 1: the 24-hour early warning

When the clock starts

The clock starts when the entity "becomes aware" of the significant incident — not when the incident occurs, not when the SOC opens a ticket, and not when the CISO is briefed. Becomes aware is interpreted to mean the point at which the entity has enough information to suspect, with reasonable grounds, that the significance threshold has been met.

The directive deliberately uses an awareness trigger rather than a discovery trigger. The intent is to prevent entities from running long investigations before reporting. If your SOC analyst at 02:00 sees indicators that look like ransomware deployment in progress, your clock is running by 02:01 — not when your incident commander is in the office at 09:00.

What goes in the early warning

Article 23(4)(a) is sparse. The early warning must indicate, where applicable:

• Whether the significant incident is suspected of being caused by unlawful or malicious acts
• Whether it could have cross-border impact

That is the minimum. National CSIRT portals typically request more — basic entity identification, contact details, a one-paragraph description of what you know — but the directive itself sets a low bar. The intent is speed. You are raising your hand, not filing an investigation.

Who you report to

You report to the national CSIRT designated under NIS2, or where applicable, the competent authority. Examples:

• Denmark — CFCS (Centre for Cybersecurity)
• Germany — BSI (Bundesamt für Sicherheit in der Informationstechnik)
• France — ANSSI (Agence nationale de la sécurité des systèmes d'information) and CERT-FR
• Netherlands — NCSC-NL

For cross-border incidents, you report to each affected member state's CSIRT. Cooperation duties between CSIRTs are set out in Article 23(7), but they do not relieve you of the obligation to notify each one yourself.

The CSIRT response obligation

Article 23(5) creates a corresponding obligation on the CSIRT or competent authority: respond to the early warning, where possible within 24 hours of receipt, with initial feedback and guidance or operational advice. This is one of the most under-appreciated features of Article 23. The reporting channel is a two-way line — make sure your runbook captures whatever the CSIRT responds with.

Stage 2: the 72-hour incident notification

What changes from stage 1

Stage 2 is where you update the early warning with everything you have learned in the intervening 48 hours. Per Article 23(4)(b), the incident notification must, where applicable:

• Update the information from the early warning
• Provide an initial assessment of the significant incident, including severity and impact
• Include, where available, indicators of compromise (IoCs)

This is where the work scales. The 24-hour early warning is one paragraph. The 72-hour notification is typically several pages. Affected systems, users, customers, data categories. Method of attack, attack vector, attribution where known. Containment actions taken. Mitigation deployed. Cross-border effects confirmed or ruled out.

The IoC question

"Where available" is doing real work in this provision. Many SMEs do not have the in-house forensics capability to extract detailed IoCs within 72 hours. That is acceptable — the directive does not require you to invent IoCs you do not have. It requires you to share what you do have. Treat your endpoint detection logs, firewall logs, and authentication logs as your IoC source set; share hashes, IPs, domains, and TTPs as you identify them.

If you engage external incident response support, agree in advance that the IR firm will produce a 72-hour summary in a format you can include in the notification. Trying to extract this from a third-party report after the deadline has passed is one of the most common ways to miss the 72-hour mark.

Trust service provider derogation

Per Article 23(4), trust service providers must submit the incident notification within 24 hours rather than 72 for incidents affecting their trust services. This reflects the cross-systemic importance of trust services — if a qualified certificate authority is compromised, downstream effects propagate to every relying party in hours.

Customer notification obligation

Article 23(1) imposes a separate obligation: when a significant incident is likely to adversely affect the provision of your services, you must inform your service recipients. This is not satisfied by your notification to the CSIRT. Two separate communications, two separate audiences. The customer notification typically goes out in parallel with the 72-hour notification or shortly after. Communications must include what happened, what services are affected, and what mitigation measures users should take.

Stage 3: the 1-month final report

Per Article 23(4)(d), the final report is due no later than one month after the incident notification at stage 2. It must include:

• A detailed description of the incident, including its severity and impact
• The type of threat or root cause that likely triggered the incident
• The mitigation measures applied and ongoing
• Where applicable, the cross-border impact of the incident

This is the document that becomes part of the audit record. Three things distinguish a good final report from a defensive one:

1. Real root cause, not symptoms. "Ransomware via phishing email" is a symptom. "Phishing email exploited the gap in our email filtering during the maintenance window on 14 March, evading detection because the lure was in a new domain registered four hours earlier" is root cause.
2. Honest impact assessment. Auditors and competent authorities cross-reference final reports against the 72-hour notification. If your 72-hour assessment said "limited customer impact" and your one-month report quietly upgrades that to "1,400 customers affected," expect follow-up questions.
3. Mitigation that addresses root cause. Buying a new firewall when the root cause was a misconfigured policy is theatre. The competent authority is looking for evidence the underlying weakness has been remediated.

Ongoing incidents

If the incident is still ongoing at the one-month mark, Article 23(4)(d) requires a progress report instead, with a final report due within one month of incident resolution. Some member state transpositions (notably Belgium and Austria) specify the progress report format more tightly than the directive.

National variations to be aware of

The 24-72-30 timeline is the directive's floor — member states may set shorter timelines, and a few have. Known variations as of mid-2026:

• Cyprus — six-hour early warning (gold-plated below the directive's 24h)
• Belgium — Centre for Cybersecurity Belgium (CCB) requires the early warning via a specific online form; failure to use it counts as non-compliance even if the timing is met
• Italy — adopted the directive's 24-72-30 timeline with no derogation, but ACN guidance specifies severity thresholds that differ from the Commission Implementing Regulation
• Hungary — requires reporting of significant cyber threats in addition to incidents, broadening the scope
• Slovakia — same broadening as Hungary; reports of "thwarted significant incidents" are required

Check your country tracker for the specifics. For Denmark, the directive's 24-72-30 applies without national derogation; reports go to CFCS.

📨 27 transpositions, 27 reporting portals, and the deadlines are not all the same. Risk Letters tracks the variations weekly. Free.

Common pitfalls

Six failure modes that show up repeatedly:

1. Confusing NIS2 and GDPR timelines. NIS2 early warning is 24 hours. GDPR breach notification is 72 hours. Different clocks, different authorities, different content. If your incident involves personal data, both apply.
2. No pre-established CSIRT relationship. Entities that have never contacted their CSIRT before the first real incident waste critical time establishing communication channels. Send a "hello, we are in scope, here is our contact" email now, before you need it.
3. Single point of failure in the reporting team. If only one person knows how to file the early warning and they are unreachable, you miss the deadline. Always designate a deputy and document the process well enough for the deputy to act alone.
4. Treating the final report as optional. Some entities submit the early warning and notification but fail to follow through with the final report. Competent authorities track this. Missing the one-month deadline is a standalone violation.
5. Reporting too late because you wanted certainty. The directive's whole structure assumes uncertainty in the early stages. The early warning exists precisely so you don't have to wait for certainty. Report what you know; update as you learn more.
6. Forgetting cross-border obligations. A 200-person SaaS provider serving customers in DE, FR, and NL must consider whether the incident affects services in each jurisdiction. The 24-hour clock runs in parallel to each affected CSIRT.

Building the reporting capability

A pragmatic capability includes four operational components:

• Detection — SIEM/EDR/IDS aligned to your significance thresholds; logging with at least 12 months retention as a defensible baseline
• Classification — a pre-agreed matrix that lets a tier-1 analyst confidently decide significant or not without waking the CISO
• Reporting workflow — pre-approved templates for each of the three stages, with named owners and a documented deputy chain
• Tabletop drills — at minimum annual; ideally semi-annual, with rotation of who plays the incident commander

The full reporting capability sits inside Article 21(2)(b) (incident handling). See NIS2 Article 21: All 10 Risk Management Measures Explained for how it fits.

Frequently asked questions

Does GDPR's 72-hour breach notification replace NIS2 reporting? No. They are parallel obligations to different authorities. NIS2 goes to the CSIRT; GDPR breach notification goes to the data protection authority. If your incident involves personal data, file both.

Is the early warning expected to be detailed? No. Article 23(4)(a) is deliberately sparse. Speed beats detail at this stage.

What if we are not sure whether an incident is significant? Report. The cost of an unjustified early warning is negligible; the cost of an unreported significant incident is up to €10M or 2% of global turnover.

Can we use one report for multiple member states? You must notify each affected CSIRT, but most portals accept the same content. Build your reports modularly so you can submit identical content to multiple authorities without rework.

What does "becomes aware" mean in practice? The point at which the entity has enough information to reasonably suspect the significance threshold has been met. Not when the analyst opens the ticket; not when the CISO is briefed. The directive uses an awareness trigger to incentivise detection investment.

Are managed service providers required to report on behalf of clients? No. The reporting obligation sits with the in-scope entity. An MSP may produce the report content, but the entity files it.

What if the incident is contained in 30 minutes — do we still report? If it met the significance threshold at any point, yes. The 24-72-30 timeline still applies, but the content will reflect rapid containment.

The bottom line

Three takeaways:

1. The clock starts at awareness, not investigation completion. Build detection so you cannot miss the trigger; build reporting so you don't miss the deadline.
2. The three stages have different content, not the same content in three formats. Pre-build templates for each.
3. Tabletop drills are the only honest way to know whether your capability works. Run them before you need them.

For the management body's role in incident response and reporting, see NIS2 Board-Level Accountability: Personal Liability Explained. For how DORA reporting differs (4-hour initial notification, different classification scheme), see NIS2 vs DORA: Key Differences for European Companies.

---

Sources & further reading

• Directive (EU) 2022/2555 — NIS2 — Article 23 (reporting obligations), Article 21(2)(b) (incident handling)
• Commission Implementing Regulation (EU) 2024/2690 — significance criteria for specific entity types
• ENISA — NIS2 technical implementation guidance
• ECSO — NIS2 Transposition Tracker (national variations)
• National CSIRT guidance: CFCS (DK) · BSI (DE) · ANSSI (FR) · NCSC-NL (NL) · CCB (BE)