Does Your Incident Trigger NIS2 Reporting? The Art. 23(3) Two-Limb Test, €500K Thresholds, and 24h/72h/1-Month Deadlines

The 24-hour early warning clock starts the moment your organisation becomes aware of a potential significant incident — not when you have confirmed it. That is a deliberately low bar, and it catches most unprepared compliance teams off guard. The harder question, which Art. 23(3) of NIS2 Directive 2022/2555 answers in a deceptively short paragraph, is: what makes an incident significant in the first place?

Most organisations under NIS2 scope have memorised the timeline — 24 hours, 72 hours, one month. Fewer have worked through the threshold logic that determines whether those clocks start at all. The directive sets a two-limb qualitative test in Art. 23(3). For specific digital service providers, Commission Implementing Regulation 2024/2690 (CIR 2024/2690) adds a second layer: exact quantitative thresholds by service type, published in the Official Journal on 17 October 2024 and directly applicable across all EU member states. Get the definition wrong, and the timeline becomes irrelevant.

This guide unpacks the Art. 23(3) two-limb test into a step-by-step decision tree, presents the CIR 2024/2690 thresholds by entity type in a single reference table, and maps out exactly what content Art. 23(4) requires at each of the three notification stages. For a full walkthrough of the submission process itself, see our guide on how to report a NIS2 significant incident.

The Art. 23(3) Two-Limb Test: Definition and Decision Tree

Art. 23(3) of the NIS2 Directive defines a significant incident through two alternative criteria. Either one, on its own, is sufficient to trigger the reporting obligation.

Limb (a) — Impact on the entity: The incident has caused, or is capable of causing, severe operational disruption of the services the entity provides, or significant financial losses to the entity.

Limb (b) — Impact on others: The incident 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 intentional and load-bearing. An incident does not need to have caused disruption to qualify — the risk of disruption is sufficient. If your security team contained a ransomware attack before encryption completed, but the attack had the capability to disrupt service delivery, limb (a) is met. Under-reporting because “nothing bad actually happened” is one of the most common NIS2 compliance errors — and one the directive explicitly anticipated.

One practical note on limb (b): “considerable non-material damage” covers reputational harm to affected users and disruption to services they depend on, not only financial harm. Data exfiltration that has not yet been monetised by an attacker can trigger limb (b) if it exposes individuals to fraud risk.

Decision tree for the significance test:

Has any system, service, or data your organisation uses to deliver a regulated service been affected by an incident?

→ No — Monitor. No reporting obligation yet.
→ Yes — Continue.

Could the disruption cause severe operational disruption of your services, OR significant financial loss to your organisation?

→ Yes (either) — Limb (a) is met. Incident is significant. Begin the 24h early warning process.
→ Uncertain — If you are a CIR-covered digital service provider, apply the quantitative thresholds in Section 2. If not, continue.
→ No — Continue.

Could the incident cause considerable material or non-material damage to other persons — customers, downstream entities, or third parties?

→ Yes — Limb (b) is met. Incident is significant. Begin the 24h early warning process.
→ No — Incident is likely not significant. Document your assessment and the reasoning behind it.

That documented assessment matters. Every decision not to report must be defensible to your national competent authority. If an unreported incident later causes damage, the absence of a written significance assessment is an aggravating factor in any supervisory review.

CIR 2024/2690 Thresholds: Exact Numbers for Digital Service Providers

Commission Implementing Regulation 2024/2690 applies to a defined list of digital service providers. If your organisation is in this list, you have access to precise quantitative thresholds that replace the qualitative judgment call in Art. 23(3) for operational triggers — though the financial threshold applies in addition, not instead.

CIR scope — covered entity types:

• DNS service providers and top-level domain (TLD) name registries
• Cloud computing service providers and data centre service providers
• Content delivery network (CDN) providers
• Managed service providers (MSP) and managed security service providers (MSSP)
• Online marketplace, search engine, and social networking platform providers
• Trust service providers

If your organisation is not in this list, you apply the Art. 23(3) qualitative two-limb test directly. Non-CIR entities are not exempt from the significant incident definition — they simply lack a pre-set quantitative benchmark and must make the severity assessment without one.

Cross-entity financial threshold (all CIR-covered entities, Art. 3 CIR 2024/2690): An incident that causes financial loss exceeding EUR 500,000 or 5% of the entity’s annual global turnover — whichever is lower — is significant, regardless of operational impact. This threshold applies across all CIR entity types.

Entity-specific operational thresholds (Art. 5–14, CIR 2024/2690):

Entity type	Complete unavailability threshold	Limited availability / data impact threshold
DNS service providers	>30 minutes	Avg response >10s for ≥1 hour; data integrity affecting >1% of managed domains or >1,000 domains
TLD name registries	Any duration	Avg response >10s for ≥1 hour
Cloud computing providers	>30 minutes	>5% of users or >1 million users for ≥1 hour; data compromise affecting same thresholds
MSP / MSSP	>30 minutes	>5% of users or >1 million users for ≥1 hour; data compromise affecting same thresholds
Online marketplaces, search engines, social platforms	Affects >5% of users or >1 million users	Affects >5% of users or >1 million users; data compromise affecting same thresholds
Trust service providers	>20 minutes	>1 hour per calendar week; limited availability affecting >1% or >200,000 users; data compromise affecting >0.1% or >100 users

The recurring incident aggregation rule (Art. 4, CIR 2024/2690): Individual incidents that fall below the threshold do not escape the significance test if they recur. Where two or more incidents within a six-month window collectively meet the threshold, they must be treated as a single significant incident and reported accordingly. This provision is specifically designed to catch drip-attack patterns — persistent, low-severity disruptions that appear benign in isolation but constitute a coordinated campaign in aggregate.

The Three-Stage Notification Cascade: Exact Content Requirements

Art. 23(4) of NIS2 specifies what each stage must contain. The stages are sequential and cumulative — each builds on the previous submission. For the operational process — which portals to use, how to register with your national CSIRT — see the NIS2 incident reporting overview.

Stage 1 — Early Warning (within 24 hours of awareness)

The early warning is deliberately minimal. Art. 23(4)(a) requires only two substantive elements beyond basic entity identification:

1. Whether the incident is suspected of being caused by unlawful or malicious acts
2. Whether the incident could have a cross-border impact

Do not delay the early warning because your investigation is incomplete. The directive does not require you to confirm the cause — it requires you to signal awareness and potential scope. A submission that reads “cause under investigation, cross-border impact cannot be excluded” is fully compliant at this stage. A delayed submission because your team waited for forensic confirmation is a separate violation, assessed independently of the incident itself.

Stage 2 — Incident Notification (within 72 hours of awareness)

The 72-hour notification updates and expands on the early warning. Art. 23(4)(b) requires, where applicable:

1. Updated information from the early warning
2. Initial assessment of severity and impact on service delivery
3. Indicators of compromise (where available at time of submission)
4. An initial estimate of affected users or downstream entities
5. Reassessment of cross-border impact

The phrase “where available” gives operational flexibility at this stage. If indicators of compromise are still being extracted by your forensic team at the 72-hour mark, you submit what you have and note what is pending. Completeness matters less than timeliness. ENISA’s June 2025 Technical Implementation Guidance recommends a structured escalation process involving the CISO, a designated cybersecurity implementer, and a legal/compliance officer — with roles and contact details pre-assigned before any incident occurs.

Stage 3 — Final Report (within one month of the 72-hour notification)

The final report carries no “where available” carve-outs. Art. 23(4)(c) requires:

1. Detailed description of the incident, including its severity and impact on service delivery
2. Type of threat or root cause likely to have triggered the incident
3. Applied and ongoing mitigation measures
4. Cross-border impact, including effects on users or services in other member states
5. Lessons learned and corrective actions (best practice, aligned with ENISA June 2025 guidance, though not in the directive text itself)

Two timing points to note. First, the one-month clock starts from submission of the 72-hour notification — not from the date of the incident. Second, where root cause analysis is still ongoing at the one-month mark, most national CSIRTs accept a progress report in place of a final report, provided you include a confirmed submission timeline. Verify this with your national authority directly — the practice varies by member state and is not established in the directive itself.

When the Clock Starts: Awareness Is Not Confirmed Knowledge

“Awareness” in Art. 23 is not the same as confirmed knowledge of a breach. The 24-hour clock starts when your organisation has reasonable grounds to believe that an incident has occurred or is occurring — not when the investigation is complete, not when a vendor confirms a breach, and not when the incident is fully contained.

In practice: if your SOC identifies anomalous behaviour at 09:00 on a Monday that suggests a potential significant incident, the early warning deadline is 09:00 on Tuesday. Whether you have confirmed root cause by then is not material to the deadline.

This trigger is substantially earlier than the GDPR breach notification standard. GDPR requires notification within 72 hours of “becoming aware” of a personal data breach — a phrase that supervisory authorities have generally interpreted as confirmed knowledge, not mere suspicion. Under NIS2, reasonable suspicion is enough. Organisations that are subject to both regimes must maintain separate escalation tracks: the NIS2 early warning can be due 48 hours before the GDPR notification clock even starts.

Trust service providers: compressed timeline. Where a significant incident affects the provision of trust services — qualified electronic signatures, website authentication certificates — Art. 23 condenses the 72-hour incident notification into a 24-hour notification. The rationale is the immediate public reliance on trust services: an undetected compromise of a trust service creates cascading liability across every relying party. The one-month final report obligation applies on the same terms as for all other entities.

Penalties and Management Liability

Missing a reporting deadline under Art. 23 is treated as a separate violation from the underlying incident. National competent authorities assess these independently: an organisation can be penalised for the incident itself and again for a late or absent notification.

Under NIS2, maximum administrative fines are:

• Essential entities: up to EUR 10 million or 2% of global annual turnover, whichever is higher
• Important entities: up to EUR 7 million or 1.4% of global annual turnover, whichever is higher

Art. 20(1) goes further than organisational penalties. It states that members of the management body “can be held liable for infringements” of the cybersecurity risk-management obligations under Art. 21, where those infringements result from a failure to oversee compliance. The incident reporting framework sits downstream of Art. 21 — but the governance failure that leads to a missed notification is exactly the kind of oversight gap that triggers management liability. Incident reporting is a board-level governance item, not a technical one.

Action Checklist by Role

The Art. 23(3) definition and the notification cascade affect different functions in your organisation differently. The table below maps obligations to the roles most commonly responsible for them in in-scope entities.

Role	Key obligations under Art. 23
CISO	Maintain an always-on awareness baseline; ensure the 24h early warning can be submitted at any hour of any day. Designate a named reporting contact registered with your national CSIRT.
Compliance Officer	Pre-build the three report templates before an incident occurs. Establish and document the escalation matrix that routes potential significant incidents to the reporting decision within hours, not days.
Legal Counsel	Document the significance assessment for every incident your organisation decides not to report — including the “capable of causing” analysis. Cross-border impact evaluation is a legal assessment, not a technical one.
Board / Management	Approve and review the escalation matrix under Art. 20(1) governance obligations. Confirm NCA registration is current. Understand that missing a reporting deadline is separately actionable from the incident itself.

Frequently Asked Questions

Is every system outage a significant incident?
No. Art. 23(3) requires “severe” operational disruption — not any disruption. Minor outages that do not affect service delivery at a level causing material harm to the entity or third parties are not significant. The CIR 2024/2690 thresholds — for example, more than 30 minutes of complete unavailability for cloud providers — give digital service providers a precise reference for where the line sits.

We contained the incident before it caused damage. Do we still have to report?
Potentially yes. Art. 23(3) explicitly covers incidents that are “capable of causing” severe disruption, not only those that did cause it. Document your containment assessment: your analysis of why the contained incident did not cross the significance threshold is part of your compliance record, not an optional exercise.

We are not a CIR-covered digital service provider. How do we assess significance?
Apply the Art. 23(3) qualitative two-limb test using the decision tree in Section 1. The CIR thresholds are quantitative benchmarks for the listed entity types, not the universal floor. Non-CIR entities must make the severity assessment themselves, document it, and be prepared to defend it to their national competent authority.

Can we submit the 72-hour notification and the final report simultaneously if the incident resolves quickly?
The directive does not prohibit early submission of the final report. If your investigation is complete before the one-month deadline, submit the full report as soon as it is ready. What the directive does not allow is using an early final report to replace the 72-hour notification — each stage has its own content requirements and its own deadline.

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.

Sources

1. Article 23 — Reporting Obligations, NIS 2 Directive 2022/2555
2. Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex Official Journal
3. ENISA NIS2 Technical Implementation Guidance (June 2025)
4. NIS2 Incident Reporting: 24h/72h/1-Month Playbook — nisd2.eu