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

Last verified: November 2026. Incident reporting obligations are established in NIS2 Article 23; Commission Implementing Regulation (EU) 2024/2690 specifies when an incident is significant for eleven types of digital and trust service provider. 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: maximum fines of at least €10 million or 2% of total worldwide annual turnover, whichever is higher, for essential entities, and at least €7 million or 1.4% for important entities (Article 34(4)–(5)).

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 ten of the eleven categories bound by CIR 2024/2690 (every one except trust service providers), 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 of its services, or
• Has caused or is capable of causing financial loss for the entity concerned, 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 — an incident whose consequences have not yet materialised, but could meet the threshold, is reportable. What the phrase does not reach is an event that never became an incident: an attack that was prevented from materialising is a near miss under Article 6(5), and near misses fall under voluntary reporting (Article 30), not the mandatory timeline. 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

These figures bind only eleven types of entity. Article 1 of Commission Implementing Regulation (EU) 2024/2690 limits its significance rules to DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online marketplaces, of online search engines and of social networking services platforms, and trust service providers. Article 23(3) of the Directive itself contains no figure, so for every other essential or important entity — a hospital, a water utility, a manufacturer, an energy operator — the two limbs above are the test, read together with whatever your national transposition law or authority adds.

For those eleven types, Article 3(1) of the Regulation makes an incident significant where it meets one or more of these criteria:

• Direct financial loss that the incident has caused or is capable of causing, above €500,000 or 5% of the entity’s total annual turnover in the preceding financial year, whichever is lower (Art. 3(1)(a))
• Exfiltration of trade secrets, as defined in Article 2(1) of Directive (EU) 2016/943, caused or capable of being caused (Art. 3(1)(b))
• The death of a natural person, or considerable damage to a natural person’s health, caused or capable of being caused (Art. 3(1)(c)–(d))
• A successful, suspectedly malicious and unauthorised access to network and information systems that is capable of causing severe operational disruption (Art. 3(1)(e))
• Recurring incidents: incidents that are not significant on their own count as one significant incident where they occurred at least twice within 6 months, have the same apparent root cause and together meet the financial-loss criterion (Art. 3(1)(f) and Art. 4)
• Any of the entity-specific criteria in Articles 5 to 14 for your category (Art. 3(1)(g))

The entity-specific articles are where the duration and user figures sit, and they are far tighter than the round numbers some guides quote. A DNS resolution, cloud, CDN, managed or managed security service that is completely unavailable for more than 30 minutes is significant (Arts. 5(a), 7(a), 9(a), 10(a)); for a trust service the limit is 20 minutes (Art. 14(a)), and for a data centre service or a TLD’s authoritative resolution any complete unavailability counts (Arts. 6(a), 8(a)). Where users are counted, the test is more than 5% of the service’s users in the Union or more than 1 million of them, whichever number is smaller (Arts. 7 and 9 to 13), and Article 3(3) makes you count the people behind your business customers as well as the customers themselves. A compromise of data integrity, confidentiality or authenticity caused by a suspectedly malicious action needs no user count at all for cloud, data centre, CDN, managed service, marketplace, search and social providers (point (c) of Arts. 7 to 13). No criterion in the Regulation uses a 24-hour duration, a 100,000-user count, or impact in two or more member states. Scheduled interruptions and the planned consequences of scheduled maintenance are never significant incidents (Art. 3(2)).

Significance Decision Checklist

Apply this checklist the moment your security team identifies a potential incident. Start with the gate: has the availability, authenticity, integrity or confidentiality of data or services actually been compromised (Article 6(6))? If the event was prevented or did not materialise, it is a near miss, which you may report voluntarily (Section 6). If an incident has occurred, work through the rows that apply to your entity type. A single 'yes' is sufficient to classify the incident as significant and start the reporting clock.

Criterion	Threshold	Applies to	Assessment
Operational disruption or financial loss (actual or potential)	Severe operational disruption of the services, or financial loss for the entity (Dir. Art. 23(3)(a)); no figure is set at EU level	All essential and important entities	If yes → Significant
Damage to others (actual or potential)	Considerable material or non-material damage to other natural or legal persons (Dir. Art. 23(3)(b))	All essential and important entities	If yes → Significant
Direct financial loss (actual or potential)	€500,000 or 5% of total annual turnover in the preceding financial year (lower of the two) (CIR Art. 3(1)(a))	The eleven CIR entity types	If yes → Significant
Trade secrets	Exfiltration of the entity’s trade secrets, caused or possible (CIR Art. 3(1)(b))	The eleven CIR entity types	If yes → Significant
Human health impact	Death of a natural person, or considerable damage to a natural person’s health (CIR Art. 3(1)(c)–(d))	The eleven CIR entity types	If yes → Significant
Malicious access	Successful, suspectedly malicious and unauthorised access capable of causing severe operational disruption (CIR Art. 3(1)(e))	The eleven CIR entity types	If yes → Significant
Recurring incidents	At least twice within 6 months, same apparent root cause, together meeting the financial-loss row (CIR Art. 4)	The eleven CIR entity types	If yes → Significant
Complete unavailability	More than 30 minutes (DNS, cloud, CDN, MSP, MSSP); more than 20 minutes, or more than one hour calculated on a calendar week basis (trust services); any duration (data centre service, TLD authoritative resolution); more than 5% or 1 million EU users, whichever is smaller (marketplaces, search engines, social networks) (CIR Arts. 5–14)	The named category only	If yes → Significant
Limited availability	More than 5% or 1 million EU users, whichever is smaller, for more than one hour (cloud, CDN, MSP, MSSP) or at any duration (marketplaces, search engines, social networks); more than one hour (data centre service); more than 1% or 200,000 EU users or relying parties, whichever is smaller (trust services); DNS or TLD average response time above 10 seconds for more than one hour (CIR Arts. 5–14)	The named category only	If yes → Significant
Data compromise	Integrity, confidentiality or authenticity of service data compromised: by a suspectedly malicious action, with no user count (cloud, data centre, CDN, MSP, MSSP, marketplaces, search, social); for any cause affecting more than 5% or 1 million EU users, whichever is smaller (the same categories except data centres); any compromise (TLD registries; DNS, except a misconfiguration leaving fewer than 1,000 domain names, and no more than 1% of them, incorrect); more than 0.1% or 100 users or relying parties, whichever is smaller (trust services) (CIR Arts. 5–14)	The named category only	If yes → Significant
Physical access	Physical access to a data centre, or to a trust service provider’s restricted area, is compromised (CIR Arts. 8(d), 14(d))	Data centre and trust service providers	If yes → Significant
Malicious or unlawful origin suspected	Evidence or reasonable suspicion	All essential and important entities	Not a significance test on its own; state it in the early warning (Dir. Art. 23(4)(a))
Cross-border impact	Impact possible in another member state	All essential and important entities	Not a significance test on its own; state it in the early warning (Dir. Art. 23(4)(a)) and the final report (Art. 23(4)(d)(iv))

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(4) establishes four distinct reporting phases and sets out what each one must contain. CIR 2024/2690 adds nothing to that content: it only specifies when an incident is significant, and only for the eleven entity types it covers. Your national CSIRT’s form may ask for more. 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)
Phase 2 Incident Notification	Within 72 hours of becoming aware the incident is significant (trust service providers: within 24 hours)	• 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); trust service providers: Art. 23(4), second subparagraph
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)
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)

Special Rules for Ongoing Incidents

If an incident is still being handled at the one-month point, the standard timeline is modified under Article 23(4)(e):

• 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 notify service recipients — your customers or end users — where appropriate, of significant incidents that are likely to adversely affect the provision 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(4) reporting phases and their 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 Article 23(4) requires 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

Article 23(4) of the Directive specifies 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 the Article 23(4) requirements.

Mistake 4: Waiting for Harm to Materialise Before Reporting

The capable of causing language in Article 23(3) means that an incident which has already compromised your systems can be significant before the harm arrives: if it is capable of causing severe operational disruption, financial loss or considerable damage to others, it is reportable even though services have not yet gone down. What the language does not do is turn a prevented attack into a mandatory filing. Ransomware blocked at the perimeter, with nothing compromised, is a near miss under Article 6(5) — reportable voluntarily under Article 30 (Section 6), not on the 24-hour clock. Build both questions into your significance assessment checklist — did anything get compromised, and what could it cause — rather than leaving them 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 the Article 23(4) content — 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 the member state in which they are established (or, for the Article 26(1)(b) digital categories, of their main establishment). Others attempt to notify every affected-country authority simultaneously without understanding the coordination mechanism. The Article 26 jurisdiction 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 — events that could have compromised your systems or data but were prevented or did not materialise (Article 6(5))
• Cyber threats that have not yet materialised as incidents

Vulnerabilities in ICT products or services go through a separate channel: under Article 12(1), any natural or legal person can report one, anonymously if they ask, to the CSIRT designated as coordinator for coordinated vulnerability disclosure.

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 Article 23(4) content requirements, and under Article 30(2) a voluntary report cannot result in obligations you would not otherwise have had.

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 51)	Phase-specific notification forms covering Early Warning (Phase 1), Incident Notification (Phase 2), and Final Report (Phase 4) — all fields mapped to the Article 23(4) content 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 49)	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 fields Article 23(4) requires, 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, if you are one of the eleven entity types it covers, 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. Article 23(4)(b) asks only for an initial assessment of severity and impact, plus indicators of compromise where available. 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, when a CSIRT, competent authority or single point of contact shares your notification with other affected member states and ENISA, Article 23(6) requires it to preserve your security and commercial interests and the confidentiality of the information. Disclosure is still possible: under Article 23(7), where public awareness is needed to prevent or deal with a significant incident, or disclosure is otherwise in the public interest, the CSIRT or competent authority may inform the public, or require you to, after consulting you. 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, administrative fines with a maximum of at least €10 million or 2% of total worldwide annual turnover, whichever is higher, and, for essential entities where earlier measures have failed, temporary suspension of a certification or authorisation. Under Article 32(6), applied to important entities by Article 33(5), the people who represent or control the entity can be held personally liable for breach of their duty to ensure compliance. 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, where appropriate, to notify service recipients — your customers or end users — of significant incidents that are likely to adversely affect 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.

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.

Related guides

• Process Safety Incident or NIS2 Cyber Breach? The Art.23 Classification Decision Chemicals CISOs Get Wrong
• NIS2 and MSSPs: Who Must Notify CSIRT When Your SOC Detects a Client Incident?
• NIS2 Ransomware Reporting: Why the 24-Hour Clock Starts at Suspicion and Encryption Alone Can Be Significant

Sources

1. Directive (EU) 2022/2555 (NIS2 Directive), Articles 6, 12, 23, 26, 30 and 32–34 — Definitions, reporting obligations, voluntary notification, jurisdiction, supervision and fines. EUR-Lex
2. Commission Implementing Regulation (EU) 2024/2690, Articles 1 and 3–14 — Significant-incident criteria for the eleven entity types listed in Article 1. 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