How to Report a NIS2 Significant Incident: 24-Hour, 72-Hour, and 30-Day Obligations Explained

When a ransomware attack encrypts your servers at 2:47 AM, the natural instinct is to call your security team, assess the damage, and understand what happened before notifying anyone outside the organisation. That instinct is the most common compliance failure under NIS2 Article 23.

Article 23 of Directive (EU) 2022/2555 starts a 24-hour clock not when you confirm an incident is significant — but when you become aware of it. Awareness is not certainty. A credible alert from your security operations centre, an anomaly flagged by your monitoring platform, or a supplier notification that systems have been compromised can trigger the obligation. Waiting for forensic confirmation before notifying your national CSIRT is itself a reportable violation.

This guide walks through the complete Article 23 operational process: how to determine whether an incident crosses the significance threshold, what the three mandatory notification reports must contain at each stage, who receives them, and the procedural errors that convert a single incident into multiple separate enforcement actions.

Who Article 23 Applies To

The reporting obligation applies to essential and important entities as classified under NIS2 — operators in 18 regulated sectors across Annexes I (essential) and II (important), covering energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, public administration, space, and a further eight sectors under Annex II including food production and manufacturing. If your organisation has assessed its NIS2 scope and confirmed it is in scope, Article 23 applies in full. If you have not yet completed a scope assessment, the NIS2 requirements overview covers the ten risk management measures and the scope criteria under Articles 3 and 6.

One category of entities has additional quantified significance thresholds on top of the general Article 23(3) test: the 11 digital service provider types covered by Commission Implementing Regulation (EU) 2024/2690, published 17 October 2024 and in force from 7 November 2024. These include cloud computing service providers, managed service providers (MSP), managed security service providers (MSSP), DNS service providers, TLD name registries, content delivery network providers, data centre service providers, providers of online marketplaces, online search engines, and social networking services platforms, and trust service providers. For these entities, CIR 2024/2690 specifies exact financial loss amounts and availability thresholds in Articles 3 to 14. For all other essential and important entities — energy companies, hospitals, water utilities, transport operators — the significance test under Article 23(3) applies qualitatively, without specific numeric thresholds from the CIR.

Is Your Incident Significant? The Article 23(3) Test

Article 23(3) sets a two-limb test using disjunctive logic — an incident is significant if it meets either limb:

(a) It has caused, or is capable of causing, severe operational disruption to your services or significant financial loss to your organisation.

(b) It has affected, or is capable of affecting, other natural or legal persons by causing considerable material or non-material damage.

Both limbs are forward-looking: the incident does not need to have caused harm already. Capability of harm, assessed on what you know at the moment of awareness, is sufficient to trigger the obligation.

For entities covered by CIR 2024/2690, the following specific thresholds apply under Article 3:

Significance Criterion	Threshold	Applies To
Financial loss (direct)	EUR 500,000 or 5% of annual global turnover — whichever is lower	All 11 digital provider types under CIR 2024/2690
Complete service unavailability	More than 30 continuous minutes	Cloud computing, CDN, DNS, data centre providers
Partial service degradation	5% of users or 1 million EU users affected for 1 or more hours	Cloud computing, CDN, online marketplace and social platform providers
Recurring incidents	Two or more incidents with the same root cause within any 6-month period, combined impact meeting the financial or availability threshold	All 11 digital provider types under CIR 2024/2690
Severe operational disruption (general)	Qualitative assessment — core service unavailable, severely degraded, or at serious risk of disruption	All essential and important entities not covered by CIR 2024/2690
Third-party material damage	Considerable material or non-material harm to service recipients — includes supply chain disruption, health or safety impact, and reputational harm to others	All essential and important entities

Use this sequence to classify an incident at the moment of awareness:

1. Does the incident cause or risk severe disruption to a core service? → Yes: significant.
2. Does it cause or risk direct financial loss at or above the EUR 500,000 / 5% turnover level (for digital providers)? → Yes: significant.
3. Is the service completely unavailable for more than 30 minutes (cloud/CDN/DNS)? → Yes: significant.
4. Are 5% of users or 1 million EU users affected for 1 or more hours? → Yes: significant.
5. Does it cause or risk considerable damage to service recipients — material or non-material? → Yes: significant.
6. None of the above, but the incident is still in progress? → Document your assessment in writing and continue monitoring.

A practical rule endorsed by national CSIRTs across the EU: when in doubt, report. Voluntary notification carries no additional compliance burden. Filing an early warning for an incident that later proves sub-threshold costs nothing; missing a mandatory early warning for one that meets the threshold is an independent violation.

One structural point that competitors consistently miss: if your organisation has experienced two or more incidents with the same root cause in any rolling six-month window — each individually sub-threshold — and their combined financial or availability impact crosses the threshold, the combination constitutes a single significant incident under CIR 2024/2690 Article 3. This cumulative rule is relevant to managed service providers and cloud operators facing repeated, low-severity disruptions from the same vulnerability.

The Three-Stage Notification Workflow

Article 23(4) establishes three mandatory notification stages plus an optional fourth at the CSIRT’s request. Each stage has a fixed deadline, a mandatory minimum content, and a separate owner within your organisation. The architecture that fails most often is one where the CISO owns all three stages — because after the immediate crisis resolves, the 30-day final report loses visibility.

Step 1 — Detection and the Awareness Clock

The 24-hour window opens the moment a responsible person in your organisation receives credible information that a significant incident has occurred or may be occurring. National CSIRT guidance consistently interprets “becomes aware” as triggering at first credible signal — not at root cause confirmation, not at management briefing, not at forensic investigation completion.

If your SOC analyst flags what appears to be active ransomware encryption at 2:47 AM on Tuesday, your 24-hour early warning deadline is 2:47 AM on Wednesday. That window does not extend because the forensics team has not yet confirmed the infection vector. The fact of awareness — not the depth of understanding — is the trigger.

Immediate actions from the moment of detection:

1. Apply the significance criteria table above against available information. If any row triggers, treat as significant.
2. Notify the incident commander and start the reporting clock formally — record the date and time.
3. Notify Legal. If personal data may be involved, notify the DPO — GDPR Article 33 starts a separate 72-hour clock from the moment of data-protection awareness, which may differ from the NIS2 clock.
4. Preserve forensic evidence before any system re-imaging or recovery. Deleted evidence before forensic preservation is an enforcement risk independent of the reporting timeline.
5. Designate a named reporting contact with CSIRT portal access who will submit all three notifications.

For a complete step-by-step incident handling workflow including the full four-phase timeline reference, see the NIS2 incident reporting hub.

Step 2 — Early Warning (Within 24 Hours)

The early warning under Article 23(4)(a) is a concise, factual notification — not a full incident report. At this stage, the regulation mandates two specific pieces of information:

• Whether the incident is suspected to involve unlawful or malicious acts (confirm, suspect, or unknown)
• Whether the incident may have cross-border impact on other member states (yes, possible, or unknown)

Beyond those two mandatory indicators, include: your organisation’s name and NIS2 sector classification, a brief factual description of what is known at the time of submission, the systems or services affected, the immediate containment steps taken so far, and a named contact person for CSIRT follow-up.

The rule on unknowns is operationally important: explicitly document what is not yet established and commit in writing to providing it in the 72-hour notification. Submitting an early warning with documented unknowns is fully compliant. Submitting nothing while waiting for complete information is not. CSIRTs across the EU report that this is the most common early warning failure — teams accumulate information for 20+ hours before filing, then discover they have missed the 24-hour window.

Submit via your national CSIRT’s designated portal or secure channel. If the portal is unavailable, document your attempt and use the backup channel (typically a secure email address) immediately. Record the submission timestamp from the portal confirmation, not from when you drafted the notification.

Step 3 — Incident Notification (Within 72 Hours)

The 72-hour incident notification under Article 23(4)(b) updates the early warning with substantive findings. At this stage you must provide:

• An updated incident description incorporating findings since the early warning
• An initial severity and impact assessment — what systems are affected, estimated scope, whether data was accessed or exfiltrated
• Available indicators of compromise (IP addresses, domain names, file hashes, YARA rules) — share what exists; a partial list is better than none
• Confirmation or revision of the cross-border impact assessment from the early warning
• Containment and mitigation measures taken since the initial notification

This is also the stage at which parallel regulatory obligations become time-critical. If personal data is confirmed as accessed or exfiltrated, your GDPR Article 33 notification to the supervisory data protection authority is due within 72 hours of data-protection awareness — which may be an earlier or later timestamp than the NIS2 awareness trigger. Do not assume the two clocks are the same. A single incident can trigger two separate regulatory notification deadlines measured from different moments.

For entities that are also subject to DORA (financial entities under Regulation (EU) 2022/2554), NIS2 and DORA incident notifications run in parallel with different taxonomies. A cybersecurity incident at a bank that meets both frameworks requires two coordinated notifications to two different authorities. Build this coordination into your incident response procedure before an incident occurs.

Step 4 — Final Report (Within One Month)

Article 23(4)(d) requires a comprehensive final report no later than one month after the submission of the 72-hour incident notification. This is the most frequently omitted of the three obligations — early warnings and incident notifications receive attention during the crisis; final reports are deprioritised after operations are restored. Each unfiled final report is an independent violation, unrelated to the underlying incident.

The final report must contain:

• A detailed description of the incident with confirmed severity and full impact scope — number of systems affected, estimated data volume involved, operational downtime duration
• The threat type or root cause analysis: malware family, initial access vector, exploitation technique, and contributing vulnerabilities
• All mitigation and remediation measures deployed, with completion dates and verification evidence
• Cross-border impact confirmed or excluded with supporting basis
• Lessons learned with assigned owners and implementation timelines for corrective actions

If the incident is still active at the one-month deadline, Article 23(4)(d) provides for an interim progress report. Submit the interim report explicitly labelled as such, state the reason the incident remains active, and provide an estimated timeline for the full final report. When the incident closes, submit the complete final report separately. Document both submissions with timestamps.

Assign ownership of the final report to a named individual at the moment the 72-hour notification is submitted — not after the crisis has passed. Build the final report deadline into your incident management tracker as a mandatory item regardless of operational recovery status. See the NIS2 business continuity guide for how incident handling connects to the continuity planning obligations under Article 21(2)(c).

What Each Report Must Contain

Report	Deadline	Mandatory Content	Common Omission
Early Warning	24 hours from awareness	Malicious intent indicator (confirm/suspect/unknown); cross-border potential; contact; brief description; immediate actions taken	Waiting for more information before submitting; missing the malicious acts indicator
Incident Notification	72 hours from awareness	Updated severity and impact assessment; IoCs if available; cross-border update; mitigation status since early warning	No IoCs listed; not updating cross-border assessment; conflating with GDPR 72h deadline
Intermediate Report	At CSIRT request	Status update at CSIRT’s specification	Not responding within CSIRT’s specified timeframe
Final Report	1 month from notification submission	Detailed description; confirmed impact scope; root cause analysis; remediation evidence; cross-border conclusion; lessons learned with owners	Not submitted at all after operations restore; submitted without root cause analysis

Who to Notify: CSIRT or Competent Authority?

Article 23(1) requires notification to the CSIRT or — where the member state has so designated — the competent authority. The architecture differs by jurisdiction:

• National CSIRT: in most member states, the primary recipient of all Article 23 notifications. CSIRTs provide technical assistance, threat intelligence, and coordinate with law enforcement when criminal activity is detected. Under Article 23(5), your CSIRT must acknowledge receipt and provide initial guidance within 24 hours of receiving your notification.
• Competent authority: the supervisory and enforcement body for your sector. In some member states, all notifications go directly to the competent authority, which then forwards to the CSIRT. In others, both receive parallel notifications. Check your member state’s national transposition law and sector-specific guidance.
• Cross-border operations: if your services affect users in more than one member state, you must notify the national CSIRT of each affected member state. CSIRTs coordinate through the EU CSIRT Network, but the filing obligation rests with you — CSIRT-to-CSIRT coordination does not satisfy your parallel reporting obligation to each affected jurisdiction.
• Service recipients: Article 23(2) requires that you inform service recipients who may be adversely affected by a significant cyber threat, and where appropriate advise them on protective measures. For incidents where recipient systems have been compromised — for example, a supply chain attack via your software — recipient notification may be mandatory on CSIRT instruction under Article 23(7).

Establish your CSIRT portal account and sector authority contacts before an incident occurs. First contact with a CSIRT during an active incident, combined with a portal account that has never been tested, reliably contributes to late submissions. Most national CSIRTs publish sector-specific contact pages and test reporting channels; use them.

Roles and Responsibilities During Notification

A single-owner notification process — where one person is responsible for all three reports — creates a single point of failure. The 30-day final report is the stage most likely to be missed when the sole responsible person is focused on operational recovery. Distribute ownership across the notification lifecycle:

Action	CISO / IT Security	Legal / Compliance	DPO	Board / C-Suite
Significance assessment	Lead	Review	Advise (if data involved)	Informed
Early warning (24h)	Lead — submit	Review before submission	Advise on data elements	Informed
Incident notification (72h)	Lead	Review	Coordinate GDPR Art. 33 parallel	Informed
GDPR Art. 33 notification	Input	Lead	Lead	Informed
Final report (1 month)	Lead	Review and sign-off	Input on data elements	Sign-off
Non-reporting decision documentation	Lead	Sign-off	Advise	—

Five Mistakes That Turn an Incident Into a Separate Violation

1. Starting the clock at confirmation, not awareness. The 24-hour window begins when someone with reporting responsibility receives a credible signal — not when root cause is confirmed. Organisations that brief their CISO “once we know what happened” routinely discover the 24-hour window closed during the investigation. Awareness and certainty are not the same threshold under Article 23.

2. Applying GDPR’s 72-hour deadline to NIS2’s 24-hour early warning. These are parallel obligations with separate clocks. NIS2 Article 23(4)(a) requires an early warning within 24 hours; GDPR Article 33 requires breach notification within 72 hours of the data controller becoming aware of a personal data breach. When both apply to the same incident — which is common in attacks involving exfiltration of customer data — you face two distinct deadlines measured from two potentially different moments of awareness. Conflating them delays the NIS2 early warning by 48 hours. For a full overview of the security measure obligations that sit alongside the reporting obligation, see the NIS2 requirements guide.

3. No pre-incident CSIRT relationship or portal access. Most CSIRTs operate portal-based reporting. Discovering that your designated reporter does not have an active portal account — or that the portal requires a registration step — during an active incident at 3 AM reliably produces a late early warning. Register, verify portal access, and test the submission flow before an incident occurs. Include the CSIRT portal URL, backup email, and emergency contact number in your incident response playbook alongside your internal escalation chain.

4. Treating the final report as optional. The crisis passes, operations restore, and the 30-day final report quietly slips past without submission. Each unfiled final report is an independent violation under Article 23, unrelated to the incident severity or whether the early warning and 72-hour notification were filed correctly. Assign a named owner for the final report at the moment the 72-hour notification is submitted. Put the deadline in the organisation’s incident management tracker as a non-negotiable item.

5. Failing to document non-reporting decisions. When your significance assessment concludes that an incident does not meet the threshold, record that assessment in writing: the incident description, the significance criteria evaluated, and the reasoning for concluding the criteria were not met. An undocumented non-reporting decision creates serious audit exposure. If a supervisory authority later investigates the incident and finds no documented significance assessment, the presumption may be that no assessment was conducted.

After You Submit: What Article 23 Requires of Your CSIRT

Reporting under Article 23 is not a one-way obligation. Under Article 23(5), your national CSIRT is required to respond within 24 hours of receiving your early warning or notification with:

• Acknowledgement of receipt
• Initial feedback, including relevant guidance specific to your incident type
• Referral to law enforcement authorities where criminal activity is indicated or suspected

CSIRTs may also share indicators of compromise with the sectoral CSIRT community, coordinate with sector-specific supervisory bodies, and — for incidents with confirmed cross-border impact — notify ENISA and the CSIRT Network for coordination across affected member states. Under Article 23(9), CSIRTs compile quarterly aggregate and anonymised summary reports for ENISA; your individual notification contributes to EU-level threat intelligence that informs the annual ENISA Threat Landscape report.

If you do not receive CSIRT acknowledgement within 24 hours of submitting an early warning, follow up via the backup channel and document the contact attempt. The CSIRT’s response obligation is separate from yours — their failure to respond does not affect your compliance, but documenting your follow-up does.

Frequently Asked Questions

If we are unsure whether an incident is significant, should we report it?
Yes. Article 23 guidance from the European Commission, ENISA, and national CSIRTs consistently recommends filing when uncertain. Voluntary notifications under Article 30 carry no additional compliance burden. Over-reporting is not penalised; filing a mandatory early warning 25 hours after awareness — one hour late — is.

Can we submit an early warning if we do not yet know the root cause?
Yes, and you should. Article 23(4)(a) only requires that you indicate whether malicious or unlawful acts are suspected (confirmed, suspected, or unknown) and whether cross-border impact is possible. Both fields explicitly accept “unknown.” The purpose of the early warning is to give your CSIRT early visibility — not to receive a complete picture.

What if the incident is still active when the one-month final report is due?
Submit an interim progress report stating the current status, the reason the incident remains active, and an estimated timeline for the complete final report. Clearly label it as an interim submission. When the incident closes, file the full final report separately with the complete root cause analysis and remediation evidence.

Do we need to notify customers or end users?
Article 23(2) provides that entities may inform service recipients of significant cyber threats and should advise on protective measures. For incidents that have materially affected recipients — for example, a breach exposing customer data or a supply chain attack that propagated to recipient systems — your CSIRT may instruct mandatory recipient notification under Article 23(7). Banking and health-sector entities face additional sector-specific notification obligations to affected individuals beyond NIS2.

What is the penalty for missing the 24-hour early warning deadline?
Under Article 35 of NIS2, essential entities face administrative fines up to EUR 10 million or 2% of global annual turnover, whichever is higher. Important entities face fines up to EUR 7 million or 1.4% of global annual turnover. In Germany, under §38 NIS2UmsuCG (in force November 2025), management personnel bear personal liability for failures to ensure timely reporting. Each missed deadline — early warning, 72-hour notification, and final report — is a separate violation independent of the underlying incident.

Sources

Directive (EU) 2022/2555 (NIS2 Directive), Article 23 — EUR-Lex
Commission Implementing Regulation (EU) 2024/2690, Articles 3–14 — EUR-Lex
EU Digital Providers Get Final Implementing Regulation on Cybersecurity — A&O Shearman
NIS Directive 2: Cybersecurity Policy and Implementation — ENISA

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.