Who should read this: Legal Teams, IR Teams, Compliance Officers, CSOs.
The NIS2 Directive requires essential service providers to report significant incidents to competent authorities and national CSIRTs within 24 hours of detection. But what constitutes a “significant” incident? The directive does not establish a bright-line rule (a specific data volume, outage duration, or financial threshold) that automatically triggers reporting. Instead, Article 23(3) establishes criteria requiring judgment and contextual analysis.
For compliance officers and incident response teams, understanding the significance threshold is critical. Misclassifying incidents, either over-reporting and overwhelming regulators, or under-reporting and violating the directive, creates compliance risk. Over-reporting incidents that are not genuinely significant may lead regulators to view future reports with scepticism; under-reporting risks regulatory sanction and loss of credibility.
This post unpacks Article 23(3), illustrates how the significance criteria apply across different sectors and incident types, and provides practical guidance on decision-making when incidents occur. The goal is not to provide a definitive checklist (the directive intentionally uses judgment-based criteria), but to clarify the framework and illustrate its application.
The Statutory Criteria for Significance
Article 23(3) defines a significant incident as one meeting any of the following criteria:
“It has resulted in a widespread disruption of the delivery of the essential service provided by the entity, or is likely to result in such a disruption.”
“It has substantially compromised the confidentiality, integrity or availability of networks or information systems used to provide the essential service.”
“It has a substantial impact on the continuity of critical functions, or has generated a substantial operational or security impact.”
These criteria are interrelated but distinct. The first addresses service disruption (impact to customers and public); the second addresses technical compromise (loss of data protection or system availability); the third addresses broader operational and strategic impact.
Criterion 1: Widespread Disruption of Essential Services
The first criterion asks whether the incident has disrupted, or is likely to disrupt, the delivery of the essential service. For different sectors, “disruption” means different things:
For a hospital (healthcare essential service provider): Disruption means impairment of clinical operations. If ransomware encrypts the electronic health record system and the hospital cannot access patient records, that is disruption. Alternatively, if malware compromises the pharmacy system and medications cannot be dispensed, that is disruption. By contrast, if malware is discovered on a non-clinical administrative system (e.g., payroll), that is unlikely to be disruption unless the malware begins to spread to clinical systems.
For a telecommunications provider (digital infrastructure essential service provider): Disruption means impairment of network services. If an attack disables a major cell tower affecting thousands of users, that is disruption. If an attack compromises a core network router, causing call failures across a region, that is disruption.
For an energy provider (energy essential service provider): Disruption means power outages or voltage instability. If an attack on industrial control systems causes a loss of power to a region, that is clearly disruption.
Critically, the criterion uses the term “widespread.” A localised disruption (affecting a single hospital ward, a single cell tower, or a single substation) might not be “widespread,” depending on context. A large hospital with multiple wards might not be “widely” disrupted if one ward’s systems go down and other wards continue functioning. Conversely, disruption to core services (a hospital’s main EHR affecting all clinical staff, a national telecom provider’s core network) is inherently widespread.
Member State regulators and CSIRTs will have expectations about what constitutes “widespread.” If a regulator publishes sector-specific guidance, it may clarify that disruption affecting X% of service delivery, Y number of customers, or Z duration qualifies as widespread. In the absence of specific guidance, entities must apply judgment.
For planning purposes, incident response teams should document their assessment of disruption at the time of incident detection. What percentage of service is affected? How many customers are impacted? Is disruption localised or widespread? This assessment informs the decision of whether reporting is required.
Criterion 2: Substantial Compromise of Confidentiality, Integrity, or Availability
The second criterion asks whether the incident has substantially compromised the confidentiality, integrity, or availability of networks or systems used to provide the essential service. This criterion focuses on technical compromise rather than service disruption.
Confidentiality compromise: Data has been exfiltrated or is at risk of exfiltration. If an attacker has copied sensitive data (patient records, personal information, trade secrets) from the system, confidentiality is compromised. The threshold is “substantial”: a compromise affecting a small number of records, or data with limited sensitivity, might not meet the threshold.
Integrity compromise: Data has been modified, deleted, or is at risk of modification. If an attacker has altered patient records, financial transactions, or critical configuration files, integrity is compromised. For healthcare, integrity compromise of patient records is particularly serious because it directly affects patient safety.
Availability compromise: Systems are unavailable or unable to function. If an attacker has deployed ransomware encrypting critical systems, or if a distributed denial-of-service attack has overwhelmed systems, availability is compromised.
For each type of compromise, the threshold is “substantial.” This requires judgment. A data breach affecting 100 patient records in a hospital with millions of records may not be “substantial”; a breach affecting 100,000 records likely is. A ransomware infection affecting 1% of systems might not be “substantial”; affecting 50% likely is.
In practice, incident response teams often apply thresholds based on sector guidance or internal policies. For example, a financial institution might consider any breach affecting more than 1,000 customer records to be substantial. A healthcare provider might consider any breach affecting patient treatment data to be substantial, regardless of volume. These internal policies should align with regulatory expectations.
Member States or CSIRTs may publish guidance clarifying substantiality thresholds. For example, a data protection authority might issue guidance that breaches affecting more than 1% of an organisation’s data subjects are “substantial.” Such guidance informs the significance determination.
Criterion 3: Substantial Impact on Continuity of Critical Functions
The third criterion addresses impact on critical functions or broader operational and security impact. This criterion is broader and more contextual than the previous two.
Continuity of critical functions: If an incident affects a function critical to the entity’s operations or to the sector’s operations, it is significant. For a power plant, the critical function is electricity generation; an attack on the generation control system is significant. For an airport, critical functions include air traffic control, ground movement control, and runway operations; attacks on these are significant.
Operational impact: This encompasses impacts on the entity’s ability to function, even if not affecting service delivery to external customers. An attack on the entity’s internal communication systems, or on internal business systems, might have substantial operational impact.
Security impact: This encompasses impacts on the entity’s security posture or on the security of other entities. If an attacker has obtained credentials allowing access to critical systems, or if an attack demonstrates a vulnerability in the entity’s security controls, the security impact is substantial.
For this criterion, “substantial” again requires judgment. A minor system malfunction affecting non-critical operations is not substantial. An attack disabling critical functions, substantially degrading operations, or revealing major security vulnerabilities is substantial.
Decision Framework and Practical Application
In practice, when an incident occurs, incident response teams must decide within the first few hours (and certainly within 24 hours) whether the incident is significant and whether reporting is required. A systematic approach helps:
Step 1: Determine which systems are affected. Are they systems used to provide the essential service (directly significant) or supporting systems (less likely to be significant)? A breach of a hospital’s EHR system is directly significant; a breach of the hospital’s payroll system is not (unless it cascades to clinical systems).
Step 2: Assess service disruption. Is the essential service disrupted? Is the disruption localised or widespread? If a hospital’s EHR is offline, all clinical staff cannot access records; that is widespread. If a single hospital ward’s systems go offline, but other wards continue functioning, that may not be widespread.
Step 3: Assess technical compromise. Has confidentiality, integrity, or availability been substantially compromised? For a breach, how many records, what is their sensitivity? For availability loss, what percentage of systems, what duration? Use the entity’s internal policies or sector guidance as reference points.
Step 4: Assess operational and security impact. Beyond service disruption and technical compromise, has the incident revealed major security vulnerabilities, exposed credentials with broad access, or substantially degraded the entity’s operational capabilities?
Step 5: Make a judgment call. If the incident meets any of the three criteria to a substantial degree, it is significant and reporting is required.
Documentation is critical. The incident response team should document the analysis at the time of incident detection, explaining the reasoning for the significance determination. If reporting is not triggered, the documentation explains why the incident did not meet the significance threshold.
Borderline Incidents and Conservative Reporting
Many incidents fall in a grey zone: they do not clearly meet the significance criteria, but they arguably could. For example, a ransomware attack affecting 30% of an organisation’s systems clearly meets the threshold; an attack affecting 5% arguably does not. An attack affecting a critical function clearly meets the threshold; an attack affecting a non-critical system arguably does not.
For borderline incidents, entities should consider a conservative approach. Over-reporting (notifying authorities of borderline incidents that are not quite significant) is unlikely to result in sanction; under-reporting (failing to notify for incidents that arguably are significant) risks regulatory violation. If an entity is uncertain, consulting with the national competent authority or CSIRT in advance of reporting may clarify expectations.
Additionally, entities should consider that the significance determination may be made after the incident is contained and investigated. The criterion “is likely to result in” disruption (future disruption) is important: if the incident is not reported because it has not yet caused disruption, but investigation reveals that it was likely to have caused significant disruption if not contained, the failure to report is still a violation.
Timing and the 24-Hour Clock
Article 23 requires reporting “without undue delay and in any case within 24 hours of becoming aware of a significant incident.” The 24-hour clock begins when the entity becomes aware of the incident, not when investigation is complete.
In practice, incident response should proceed in parallel with the significance determination. As soon as an incident is detected, containment measures should begin and the initial significance assessment should commence. Entities should have procedures defining who makes the significance decision (typically the chief information security officer or a designated incident commander) and who initiates notification (often legal counsel or a designated compliance officer).
The 24-hour window is binding. The directive does not allow delayed reporting in order to investigate or contain the incident. Reporting should be prompt, with initial notification including available information and follow-up reporting providing additional detail as investigation proceeds.
Key Takeaways
- A significant incident under Article 23(3) is one that: (1) has widely disrupted delivery of the essential service; (2) has substantially compromised confidentiality, integrity, or availability of critical systems; or (3) has substantial impact on critical functions or operational/security posture.
- “Widespread” and “substantial” are judgment-based criteria without bright-line thresholds. Entities should develop internal policies and align with sector guidance clarifying what meets these thresholds in their context.
- Incident response teams must assess significance at the time of incident detection, before full investigation is complete. The assessment should document which criterion is met, the reasoning, and supporting evidence.
- Borderline incidents warrant conservative treatment: when uncertain, consult with competent authorities or your CSIRT. Over-reporting is safer than under-reporting.
- The 24-hour reporting window begins upon awareness of the incident, not upon completion of investigation. Reporting should be prompt, with follow-up providing additional detail.
- Documentation of the significance determination is critical, both to support the decision and to demonstrate good faith compliance if the decision is later questioned.
