NIS2 Incident Reporting: Deadlines, Requirements, and What to Report

Last verified: March 2026. Incident reporting obligations are established in NIS2 Article 23 and Commission Implementing Regulation (EU) 2024/2690. Specific thresholds and reporting channels may vary by sector and member state transposition law.

Under NIS1, incident reporting was broadly defined and inconsistently applied across member states. NIS2 changes both. Article 23 of Directive (EU) 2022/2555 introduces a four-phase, time-bound notification structure — starting with an early warning that must reach your national authority within 24 hours of becoming aware of a significant incident.

Miss that deadline and the failure to report is itself a compliance violation, independent of the underlying incident. The penalties for non-reporting are the same as those for failing to implement security measures: up to €10 million or 2% of global turnover for essential entities, up to €7 million or 1.4% for important entities.

This guide explains what qualifies as a significant incident, how the four-phase timeline works, who to report to, and how to build a reporting process that functions under real incident pressure. If you are setting up incident reporting for the first time, start with the step-by-step workflow in Section 4. For an overview of all NIS2 obligations, see the NIS2 requirements guide.

If the incident reached you through an application interface, the significance test works differently than most guides describe: for the eleven categories bound by CIR 2024/2690, a data compromise caused by a suspectedly malicious action is significant with no user threshold attached at all. See when an API breach triggers the NIS2 reporting obligation for the limb-by-limb breakdown.

1. What Is a 'Significant Incident' Under NIS2?

Not every security event triggers mandatory NIS2 reporting. Only significant incidents — as defined in Article 23(3) of the Directive — are subject to the four-phase notification timeline. Article 23(3) defines a significant incident as one that:

• Has caused or is capable of causing severe operational disruption to services or other organisations, or
• Has caused or is capable of causing significant financial loss to the affected entity, or
• Has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage

The phrase capable of causing is deliberate and carries significant practical weight. You do not need confirmed harm before reporting — a near-miss that could have met the threshold is reportable. This is one of the most widely misunderstood aspects of NIS2 incident reporting in practice. Industrial operators face a second wrinkle: no implementing act has ever set quantified thresholds for their sectors, so the Article 23(3) limbs above are the whole test — see our guide to NIS2 OT and ICS incident reporting.

Deciding whether a given incident clears that bar is a separate, time-boxed task. For an ordered triage procedure you can run in the first ten minutes, see our five-question NIS2 incident classification decision guide — it works through the Article 6(6) gate before the Article 23(3) limbs, and sets out which member state’s significance test actually binds you.

Once an incident clears that bar, the second filing is where most teams lose time. Our guide to the NIS2 72-hour incident notification requirements sets out the three elements Article 23(4)(b) actually names, why two of them are conditional, and how the required content changes between national authorities.

Specific Thresholds Under CIR 2024/2690

Commission Implementing Regulation (EU) 2024/2690 provides concrete numerical thresholds for determining significance (Article 3). An incident is significant if it results in — or is reasonably capable of resulting in — any of the following:

• Service disruption affecting more than 100,000 users
• Duration of service disruption exceeding 24 hours
• Direct financial loss exceeding €500,000 or 5% of annual turnover (whichever is lower)
• Compromise of the confidentiality, integrity, or availability of data classified as critical
• Loss of life or considerable damage to human health
• Incidents with cross-border impact affecting entities or users in two or more EU member states

Significance Decision Checklist

Apply this checklist the moment your security team identifies a potential incident. A single 'yes' is sufficient to classify the incident as significant and start the reporting clock.

Criterion	Threshold	Assessment
Users affected or potentially affected	More than 100,000	If yes → Significant
Duration (actual or projected)	More than 24 hours	If yes → Significant
Financial loss (actual or projected)	€500,000 or 5% of annual turnover (lower of the two)	If yes → Significant
Critical data compromised	Confidentiality, integrity, or availability of critical data affected	If yes → Significant
Human health impact	Any loss of life or considerable damage to health	If yes → Significant
Geographic scope	Impact on two or more EU member states	If yes → Significant
Malicious or unlawful origin suspected	Evidence or reasonable suspicion	Flag in early warning regardless of other thresholds

When in doubt, report. The cost of submitting an unnecessary early warning is negligible. The cost of a missed mandatory notification — when a competent authority later determines the incident was significant — includes supervisory sanctions and potential fines at the same level as any other NIS2 violation.

Where the incident originates inside the organisation, the same test applies but the evidence and containment sequence do not. See insider threat reporting under NIS2 for how the two-limb test and CIR Article 3(1)(b) and (e) read against an internal actor, and the revocation order that preserves evidence.

2. The NIS2 Notification Timeline

Article 23 establishes four distinct reporting phases. Each phase has specific mandatory content requirements defined in CIR 2024/2690. This is the complete framework:

Phase	Deadline	Required Content	Legal Basis
Phase 1 Early Warning	Within 24 hours of becoming aware the incident is significant	• Incident has occurred and brief initial details • Whether a malicious or unlawful act is suspected • Whether cross-border impact is possible	Art. 23(4)(a); CIR Art. 4
Phase 2 Incident Notification	Within 72 hours of becoming aware the incident is significant	• Updated information from the early warning • Initial assessment of severity and impact • Indicators of compromise (IoCs) where available • Type of incident (best assessment at time of submission)	Art. 23(4)(b); CIR Art. 5–6
Phase 3 Intermediate Report	Upon request by CSIRT or competent authority	• Status update on incident handling • Progress on containment and recovery • Any significant new findings since Phase 2	Art. 23(4)(c); CIR Art. 7
Phase 4 Final Report	Within 1 month of submitting the Phase 2 notification	• Detailed description of the incident, including severity and impact • Type of threat or root cause likely to have triggered the incident • Applied and ongoing mitigation measures • Cross-border impact assessment, where applicable	Art. 23(4)(d); CIR Art. 8–9

Special Rules for Ongoing Incidents

If an incident is still being handled at the one-month point, the standard timeline is modified under CIR Article 10:

• Submit a progress report at the one-month mark instead of a final report
• Submit the final report within one month of the incident being fully handled and closed

This provision is relevant for protracted ransomware events, supply chain compromises, or extended data exfiltration cases where root cause analysis and full remediation span several months. The obligation to report does not disappear because the incident is ongoing — it shifts to a progress-report model.

When the Clock Starts

Both the 24-hour and 72-hour deadlines begin from the moment the entity becomes aware that the incident is significant — not when the SOC first flags an anomaly, and not when senior management is briefed. If your incident response team determines at 14:00 on Monday that the event meets the significance threshold, the Phase 1 early warning is due by 14:00 on Tuesday.

Internal review processes, waiting for management approval, or uncertainty about scope do not pause the clock. Document the significance determination with a precise timestamp as soon as it is made.

That same timestamp discipline decides your Phase 4 deadline: the one-month clock runs from the moment you submit the Phase 2 notification, not from the incident, so filing early shortens your own final-report window. For the four content items Article 23(4)(d) actually requires, how to compute the deadline, and what you are not obliged to file, see our guide to the NIS2 one-month final report.

3. Who to Report To

Your National CSIRT or Competent Authority

Each EU member state designates one or more national competent authorities and a Computer Security Incident Response Team (CSIRT) responsible for receiving NIS2 incident reports. Under Article 23(1), mandatory reports are directed to the CSIRT — or to the competent authority where no CSIRT designation has been made for your specific sector.

Depending on your member state's NIS2 transposition, reporting may go through:

• A national CSIRT serving all sectors (e.g., BSI in Germany, CERT-FR in France, NCSC-NL in the Netherlands)
• A sector-specific competent authority (e.g., a national financial regulator for banking entities, a health ministry body for healthcare organisations)
• A unified national reporting portal that routes submissions to the correct authority automatically

Which of those three you face is a national design decision, not an EU one — and the front doors differ far more than most guides admit. For a country-by-country reference covering all 27 member states, the verified national portals, published CSIRT contact hours and the out-of-hours fallbacks, see our guide to NIS2 CSIRT reporting portals across the EU.

Knowing which CSIRT receives your filing is only half of that relationship. Article 11(3) gives the team eight tasks, and two of them — assistance with real-time monitoring of your systems, and proactive scanning of your estate for vulnerabilities with a potential significant impact — start only when an entity asks for them. Article 23(5) adds two further request-gated duties that attach the moment your early warning lands, which is why a filing that simply reports and waits collects initial feedback and little else. For the full map of what your CSIRT owes you, how to trigger each service and the three provisions that let it decline, see what a CSIRT actually does under NIS2.

There is a third national designation that is easy to mistake for a reporting destination. Article 8(3) requires every member state to name a single point of contact, and in 16 of the 27 country entries the Commission publishes it is the same organisation as the competent authority — but its job under Article 8(4) is liaison between authorities, not receiving your filing. Article 23(8) only has it forward your notification to other affected member states at the request of your CSIRT or competent authority. For the full three-body map and which model your member state uses, see the NIS2 single point of contact explained.

Contact details for each national authority are maintained in the ENISA CSIRT directory. Establish your reporting contact before an incident occurs and verify it annually, as designations continue to evolve as member states finalise NIS2 transposition.

For the practical mechanics of that first submission — the exact portal URL, login/access requirement, and the fields the form asks for in Germany, France, the Netherlands, Belgium, Poland, Italy, Spain, and Ireland — see our CSIRT notification portal directory.

Research and education institutions have an additional technical incident response layer: the European NREN (National Research and Education Network) CSIRT hierarchy, coordinated at GÉANT CERT. This runs in parallel with—not in place of—the Art. 23 notification obligation. See our guide to NIS2 incident response for research institutions, covering IP theft classification, GÉANT CERT routing, and Art. 21(2)(d) obligations for research consortia.

ENISA's Coordination Role

Under Article 23(6), where a significant incident concerns two or more member states, the CSIRT, competent authority or single point of contact informs the other affected member states and ENISA without undue delay. ENISA's formal role is to provide the secretariat for the CSIRTs network and for EU-CyCLONe and to support shared situational awareness — it is not itself the coordinator of a cross-border incident, and it is never a primary reporting destination for organisations. Individual entities report to their own national authority.

Multi-Country Operations

If your organisation operates in multiple EU member states, you may have reporting obligations to more than one national authority. Article 26(1) sets the default: entities fall under the jurisdiction of the member state in which they are established — so a group with separately established in-scope entities in several countries files separately in each, within the same 24 hours. The single-jurisdiction “main establishment” rule is the exception, in Article 26(1)(b), and it is reserved for named digital categories: cloud, data centre and CDN providers, MSPs and MSSPs, DNS service providers, TLD registries, online marketplaces, search engines and social platforms. Map your reporting chain by jurisdiction before an incident forces the question — and see our guide to cross-border escalation after a critical infrastructure attack for the full path above your CSIRT, the Article 6(7) large-scale threshold, and why NIS2 has no GDPR-style one-stop shop.

Notifying Affected Service Recipients

Article 23(1) imposes a separate obligation to inform service recipients — your customers or end users — when a significant incident is capable of adversely affecting the delivery of your services to them. This customer notification obligation runs in parallel with regulatory reporting, not sequentially after it. Your incident response plan should include a customer communications track with pre-approved templates and a clear trigger point tied to the significance determination.

4. Step-by-Step NIS2 Incident Reporting Workflow

The following nine-step process is designed to be incorporated into your incident response plan as a standing procedure. Each step maps to the Article 23 reporting phases and CIR 2024/2690 content requirements. The internal side of that procedure — who is authorised to declare an incident significant, and the four internal deadlines those filings depend on — is covered in building the incident response plan backwards from the 72-hour notification.

#	Action	Deadline	Output
1	Detect incident; apply significance checklist	Immediately on detection	Significance decision with timestamp
2	Activate incident response team; assign reporting lead with standing submission authority	Within 1–2 hours of significance determination	IRT activated; reporting lead identified
3	Complete and submit Phase 1 Early Warning using pre-drafted template	T + 24 hours	Early warning submitted to CSIRT / authority; confirmation reference retained
4	Investigate and contain the incident; collect indicators of compromise	Ongoing	Containment actions documented; IoC list maintained
5	Complete and submit Phase 2 Incident Notification with severity assessment and available IoCs	T + 72 hours	Notification submitted; authority receives full Phase 2 package
6	Respond to authority requests for intermediate reports; cooperate with CSIRT if assistance is requested	Upon request	Intermediate status reports provided
7	Execute remediation and recovery; preserve forensic evidence	Ongoing	Systems restored; root cause identified; evidence secured
8	Complete and submit Phase 4 Final Report covering root cause, timeline, and mitigation measures	T + 1 month from Phase 2 submission	Final report submitted; incident formally closed with authority
9	Conduct post-incident review; update incident response plan and significance checklist	Within 2–4 weeks of incident closure	Updated IRP; revised procedures; lessons-learned document

Steps 3, 5, and 8 should each use a pre-drafted template populated by the reporting lead — not drafted from scratch under incident pressure. Pre-drafted templates are the single most effective way to ensure nothing required by CIR 2024/2690 is omitted when your team is working through an active breach.

5. Common Mistakes in NIS2 Incident Reporting

These are the six most frequent reporting failures organisations encounter in practice. Each creates either a late notification, an inadequate notification, or both.

Mistake 1: Missing the 24-Hour Deadline Due to Unclear Escalation

Early warnings often require sign-off from a senior executive who may be unavailable during a weekend or out-of-hours incident. The regulatory clock does not pause for internal process. The solution is a pre-authorised escalation path: the incident reporting lead should hold standing written authority to submit early warnings without ad-hoc approval from above. Bake this into your incident response policy before it is needed.

Mistake 2: Confusing the Awareness Trigger

The legal trigger is when the entity becomes aware the incident is significant. This is the moment your incident response team completes the significance assessment — not when the SOC first detects an alert, and not when a senior executive is informed. Regulators examining a late notification will typically apply the earlier of any plausible awareness timestamp. Document the significance determination with a precise timestamp and keep it as part of your incident record.

Mistake 3: Submitting Incomplete Notifications That Require Resubmission

CIR 2024/2690 specifies exactly what each phase must contain. Notifications missing an IoC section, lacking a cross-border impact assessment, or omitting a severity rating are common. Incomplete submissions attract follow-up requests from authorities, delay the regulatory process, and flag your organisation for closer scrutiny. This is almost entirely preventable with phase-specific templates mapped to CIR requirements.

Mistake 4: Treating Near-Misses as Non-Reportable

The capable of causing language in Article 23(3) means that a contained incident that would have met the significance thresholds is still significant — and therefore reportable. A ransomware attack blocked at the perimeter that would have disrupted services for more than 24 hours meets the threshold even if no data was exfiltrated and no services went down. Near-miss classification must be built into your significance assessment checklist, not left to ad-hoc judgment.

Mistake 5: Drafting Notifications During an Active Incident Without Templates

Composing a regulatory submission from a blank document while simultaneously managing an active breach is a reliable path to late, inaccurate, or incomplete reporting. Pre-drafted templates — with fields structured around CIR requirements — allow a reporting lead to populate and submit within hours. This is especially critical for the Phase 1 early warning, where available information is limited and every minute of preparation time counts.

Mistake 6: Reporting to the Wrong Authority in Multi-Jurisdiction Operations

Organisations operating across multiple EU member states sometimes report to the authority of the country where the incident originated, rather than the authority of their main establishment. Others attempt to notify every affected-country authority simultaneously without understanding the coordination mechanism. The Article 26 main-establishment rule is the starting point, but sector-specific regulations and affected-country obligations add complexity. Establish your reporting chain by jurisdiction as part of incident preparedness — not as an exercise conducted during an active event.

One recurring version of this mistake involves third parties: when a cloud or hosting provider fails, entities often log the vendor’s post-mortem and file nothing, on the assumption that the incident belongs to the provider. Article 23(1) measures the impact on the provision of your services, so the provider’s own filing does not discharge yours — see when a cloud provider outage triggers your own report.

6. Voluntary Reporting Under Article 30

NIS2 reporting is not limited to significant incidents. Article 30 of the Directive explicitly permits voluntary reporting of:

• Incidents that do not meet the significance threshold
• Near-misses that were contained before thresholds were reached
• Cyber threats that have not yet materialised as incidents
• Vulnerabilities discovered in ICT products or services

Voluntary reports can be submitted by in-scope entities and organisations outside NIS2 scope alike. The practical benefits are real: voluntary reporting establishes a working relationship with your national CSIRT before a crisis occurs, contributes to threat intelligence sharing across the NIS network, and can result in your CSIRT providing tailored guidance, technical assistance, or indicators of compromise from related incidents affecting other organisations in your sector.

Voluntary reports are submitted through the same channel as mandatory reports — your national CSIRT or competent authority — but are not subject to mandatory deadlines or the full CIR content requirements.

7. Templates and Tools for NIS2 Incident Reporting

Effective incident reporting under pressure depends on preparation. Our NIS2 template library includes four documents designed specifically for the Article 23 reporting workflow:

Document	Purpose	Phase
Incident Handling Policy (Doc 48)	Defines your organisation's internal incident classification, escalation, and reporting procedure — including the significance assessment framework and pre-authorised escalation paths	Foundation document
Incident Notification and Reporting Forms (Doc 49)	Phase-specific notification forms covering Early Warning (Phase 1), Incident Notification (Phase 2), and Final Report (Phase 4) — all fields mapped to CIR 2024/2690 requirements	Phases 1, 2, and 4
Incident Log / Register (Doc 50)	Running register of all incidents assessed, including significance decisions, notification timestamps, authority references, and outcome — creates an auditable compliance record	Ongoing
Minor Incident Response Procedure (Doc 51)	Handling procedure for non-significant incidents — including voluntary reporting decisions — ensuring non-reportable events are still managed and documented consistently	Non-significant incidents

Each form pre-populates the required fields from CIR 2024/2690 with guidance notes for completing each section under time pressure. The Incident Log provides an auditable record of every reporting decision — including incidents assessed as non-significant and the reasoning applied — which is essential evidence if a competent authority later reviews your compliance history under Article 32 or 33 supervision.

These templates integrate directly with the broader NIS2 compliance checklist and the NIS2 security requirements framework. They are designed for CISOs and IT managers who need working documents, not legal abstractions.

Frequently Asked Questions

When does the 24-hour NIS2 reporting clock start?

The clock starts when the entity becomes aware that the incident is significant — meaning your incident response team has assessed the event against the criteria in Article 23(3) and CIR 2024/2690 Article 3 and determined that one or more thresholds are met or likely to be met. It does not start when the SOC first detects an anomaly, and it does not wait for management to be briefed. Document the significance determination with a precise timestamp the moment it is made.

What if we do not have full details within 72 hours?

Submit what you have. CIR 2024/2690 requires your best available assessment at the time of submission. If information is incomplete, state this explicitly in the notification and indicate when updated information is expected. Failing to submit within 72 hours because the investigation is not complete is not an acceptable position — regulators expect a partial notification on time rather than a complete notification submitted late.

Can we report a NIS2 incident anonymously?

No. Mandatory incident reports under Article 23 must identify the reporting entity. However, information submitted to competent authorities and CSIRTs is subject to confidentiality obligations under Article 35 of NIS2 — authorities must protect commercially sensitive data and may not publish identifying details without the entity's consent. Voluntary reports under Article 30 may in some cases be submitted anonymously depending on the member state's transposition rules.

What happens if we miss a NIS2 reporting deadline?

Missing a mandatory reporting deadline is itself a compliance violation, independent of the underlying incident. Consequences can include supervisory warnings, binding instructions, temporary suspension of certifications, and administrative fines up to €10 million or 2% of global turnover. Under Article 20, management body members may also face personal liability. There is no grace period for good-faith late reporting.

Do we need to notify affected customers about a significant NIS2 incident?

Yes, in certain circumstances. Article 23(1) requires entities to inform service recipients — your customers or end users — when a significant incident is capable of adversely affecting the provision of your services to them. This obligation runs in parallel with regulatory reporting, not sequentially after it. Your incident response plan should include a customer communications track with pre-approved templates and a clear trigger aligned to the significance determination.

For a complete step-by-step breakdown of the Article 23 notification process — including the significance decision tree, CIR 2024/2690 thresholds, and role-responsibility matrix — see How to Report a NIS2 Significant Incident: 24-Hour, 72-Hour, and 30-Day Obligations Explained.

For a complete step-by-step walkthrough, see chemicals sector incident response — Art.23 classification for Seveso-regulated facilities.

For a complete step-by-step walkthrough, see MSSP incident response and the Art.23 notification cascade.

For a complete step-by-step walkthrough, see how the Article 23 clock and significance test work in a ransomware attack.

When an incident spans several Member States, the filing itself changes less than you would expect: our guide on which CSIRT receives the notification and what Article 23(6) puts on the regulator works through the jurisdiction test and the hour-by-hour sequence.

These deadlines only work if they are written into the plan that fires when the clock starts. For the document itself, see the six sections CIR Annex 3 expects in an incident response plan — and the four things a NIST-derived template leaves out.

Sources

1. Directive (EU) 2022/2555 (NIS2 Directive), Article 23 — Reporting obligations for significant incidents. EUR-Lex
2. Commission Implementing Regulation (EU) 2024/2690, Articles 3–14 — Significance thresholds, notification content requirements, and timelines. EUR-Lex
3. ENISA — NIS Directive 2: Cybersecurity policy, ENISA responsibilities, and implementation status. European Union Agency for Cybersecurity
4. ENISA CSIRT Inventory — National CSIRT contact points by EU member state. European Union Agency for Cybersecurity