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.

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.

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.

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.

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

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.

ENISA's Coordination Role

ENISA acts as coordinator for cross-border incidents affecting entities in two or more member states. When this occurs, the national CSIRTs of the affected countries share information through the CSIRTs Network, with ENISA providing coordination support. Individual entities report to their own national authority — ENISA is not a primary reporting destination for organisations.

Multi-Country Operations

If your organisation operates in multiple EU member states — for example, as a cloud service provider, managed security service provider, or digital marketplace serving customers across Europe — you may have reporting obligations to more than one national authority. Article 26 of NIS2 establishes rules for identifying the primary competent authority (generally the member state of main establishment), but sector-specific rules and bilateral arrangements can create parallel obligations. Map your reporting chain by jurisdiction before an incident forces the question.

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.

#	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.

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.

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