Significant incident under NIS 2
Two qualitative triggers, one regulation with numbers for digital infrastructure, and a written decision log for everyone else.
Why the definition matters
Significance is what starts the whole reporting clock in Article 23 NIS 2: an early warning within 24 hours, an incident notification within 72 hours, a final report within one month. If the event is significant, the clock starts the moment you find out. If it is not, you owe the CSIRT and the competent authority nothing.
Article 23(3) NIS 2 only gives you two general phrases. Commission Implementing Regulation (EU) 2024/2690 (CIR) adds hard numbers, but only for a small group of digital providers (DNS, TLD, cloud, data centre, CDN, MSP, MSSP, marketplace, search, social network, trust services). For every other NIS 2 sector the test stays qualitative.
Most CISOs underestimate that gap. If you are in manufacturing, food, healthcare or waste management, there is no euro figure, no minute count, no user threshold. You have to decide, you have to decide fast, and you have to be able to explain why later.
NIS 2 Directive (EU) 2022/2555, Art. 23(3)
An incident shall be considered to be significant if: (a) it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned; (b) it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.
This is the only general definition of a significant incident in EU law. Both points use 'capable of causing', so you have to weigh potential damage as well as actual damage. The text never quantifies severe, considerable, or material.
CIR (EU) 2024/2690, Art. 3
An incident shall be considered significant where it has caused or is capable of causing: (a) direct financial loss exceeding EUR 500 000 or 5 percent of total annual turnover in the preceding financial year, whichever is lower; (b) the exfiltration of the entity's trade secrets as set out in Article 2(1) of Directive (EU) 2016/943; (c) the death of a natural person; (d) considerable damage to a natural person's health; (e) successful, suspectedly malicious and unauthorised access to network and information systems capable of causing severe operational disruption; (f) the criteria set out in Article 4 (recurring incidents); or (g) one or more of the criteria set out in Articles 5 to 14 (entity-specific). Any one criterion is enough.
Seven criteria (letters a through g): five substantive plus two cross-references. CIR Art. 1 says these numbers only apply to specific digital providers (DNS, TLD, cloud, data centre, CDN, MSP, MSSP, online marketplace, search engine, social platform, trust services). Articles 5 to 14 add per-sector availability floors for the same group. If your sector is not on that list, these numbers do not bind you and the qualitative test from Art. 23(3) is all you have.
§32 BSIG (Germany, example transposition)
Wesentliche und wichtige Einrichtungen melden dem BSI erhebliche Sicherheitsvorfälle unverzüglich, spätestens innerhalb von 24 Stunden nach Kenntniserlangung als Frühwarnung, innerhalb von 72 Stunden als Sicherheitsvorfallsmeldung und innerhalb eines Monats als Abschlussbericht.
Every member state turns Art. 23 into national law. §32 BSIG repeats the cascade and names the BSI as the recipient. It adds no number of its own for non-digital sectors. The Netherlands, Austria and France follow the same pattern.
Seven criteria (letters a through g)
Five substantive triggers plus two cross-references. (a) EUR 500 000 or 5 percent of turnover (whichever is lower), (b) exfiltrated trade secrets, (c) a person killed, (d) serious harm to a person's health, (e) a successful malicious intrusion capable of severe disruption, (f) recurring incidents per Art. 4, (g) entity-specific thresholds per Arts. 5 to 14. Any one triggers significance for the digital providers in scope.
Recurring incidents
Small incidents stack. If the same root cause produces at least two incidents in six months, and together they cross the financial-loss line in Art. 3(1)(a), the CIR treats them as one significant incident. Counting each one separately is wrong.
DNS and TLD specifics
For DNS resolvers and TLD registries: name resolution down for more than 30 minutes, average response time above 10 seconds for more than one hour, or data integrity broken for more than 1 000 domains or 1 percent of the portfolio. Articles 6 to 14 set similar floors for cloud, CDN, MSP, MSSP, marketplaces, search, social and trust services.
Trigger A: severe operational disruption or financial loss for your entity
This is the inward-facing trigger. The directive gives you no euro figure, no duration, no percentage. Recital 101 names three things to look at: how much of the service is affected, how long the incident lasts, and how many users it hits. Use them to structure your thinking. Do not treat them as a checklist.
Trigger B: considerable material or non-material damage to third parties
This is the outward-facing trigger. Customers, citizens, downstream operators, your supply chain. Non-material damage includes harm to reputation and trust. A short outage that breaks a hospital workflow, leaks customer data, or pulls a city service offline can satisfy this trigger even if your own loss is small.
Ransomware shuts down production for two days
Operations stop. Trigger A of Art. 23(3) NIS 2 (severe operational disruption) is met. Early warning 24h, incident notification 72h, final report 1 month (Art. 23 NIS 2 / §32 BSIG).
Phishing email clicked, no password entered
Containment successful, no impact on services or third parties. Voluntary notification under Art. 30 NIS 2 is available if you want to share, and it imposes no additional obligations (Art. 30(4)).
Cloud provider outage, your own service delayed
If your own service becomes significantly slower or stops, Trigger A is met. Also check Trigger B: do customers or downstream operators suffer? (Art. 23(3) NIS 2)
DDoS attack takes the customer portal offline for four hours
Significant interruption to customers. Both triggers in Art. 23(3) NIS 2 are potentially met. For DNS, cloud or trust-service providers, also check CIR Arts. 5 to 14.
Misconfiguration exposes customer data
GDPR Article 33: 72h to the supervisory authority. If a NIS 2 threshold is also crossed (Art. 23(3) NIS 2 or CIR Art. 3), additionally NIS 2 Article 23: 24h early warning to the CSIRT. Both clocks start at the moment of awareness.
Supplier breached, your own service affected
First check damage to your own entity or your customers. Not every supplier incident triggers your own notification duty. In parallel: document supplier oversight under Art. 21(2)(d) NIS 2.
Unsure whether the threshold is crossed? File the early warning and update later. Art. 23(4)(a) NIS 2 is designed for exactly this. The competent authority prefers an early 'we are not sure yet' over a late 'we waited too long'.
Article 30(1) NIS 2 permits voluntary notification of incidents, cyber threats and near-misses to the CSIRT. This applies to entities in scope of the directive and to entities outside it that wish to notify a significant event.
Article 30(4) NIS 2 is the key protection: voluntary reporting shall not result in the imposition of any additional obligations upon the notifying entity. Reporting a borderline case carries no risk of extra duties. That removes the obvious excuse not to notify an unclear incident.
Article 23(2) NIS 2 adds a separate duty. Essential and important entities communicate, without undue delay, to their service recipients any measures or remedies they can take to mitigate the risks from a significant cyber threat. This is not the CSIRT notification; it is the external communication to customers.
In Germany, §35 BSIG implements this. §35(1) allows the BSI to order the notification. §35(2) additionally obliges certain sectors (finance, social security, digital infrastructure, ICT service management, digital services) to notify on their own initiative. Communication can be made by publishing on the entity's website.
BSI guidance under §32 BSIG
The BSI repeats the Art. 23(3) wording and points you at its standard reporting form (MIRP). It publishes no number for non-digital sectors. The BSI position: judge significance against the qualitative criteria, write down your reasoning, and report when in doubt.
ENISA Technical Implementation Guidance
The ENISA Technical Implementation Guidance (TIG, v1.2 August 2025) gives practical advice on impact assessment and points at the CIR thresholds where they apply. The TIG is non-binding and explicitly hands sectors outside CIR scope back to the national authorities.
Other member state transpositions
The Dutch Cyberbeveiligingswet, the Austrian NISG 2024 draft, and the French OIV/REC regime all repeat the Art. 23(3) test word for word. None of them has published numbers for non-digital sectors yet. The pattern across the EU is the same: qualitative test plus the CIR for the digital group.
Myth 1: We will know it when we see it.
Reality: Art. 23(3) gives you 24 hours to decide, write the reasoning down, and defend it at audit. If you have not written your criteria down before the incident, you will be making the call under pressure with no record to fall back on. Build the decision framework now, not on the day.
Myth 2: Only data breaches count as significant incidents.
Reality: Art. 23(3)(a) covers operational disruption and financial loss with no mention of personal data. A factory line stopped by ransomware with no data exfiltration is a significant incident. A logistics platform offline for three hours is a significant incident. NIS 2 is not GDPR.
Myth 3: Small incidents below the threshold do not stack.
Reality: CIR Art. 4 (and the same logic for the qualitative triggers) says repeated incidents with the same root cause add up. Two 20-minute outages from the same failing component within six months can cross the threshold together. Counting each one in isolation is wrong.
Annexes I and II of NIS 2 cover roughly 18 sectors. Only the digital group in CIR Art. 1 (about 11 entity types) gets numbers. That is a small slice of the entities in scope. For energy, transport, banking, financial market infrastructure, health, drinking water, waste water, public administration, space, postal, waste management, chemicals, food, manufacturing, and research, the test stays qualitative.
That is where you can be useful in the room. The honest answer to the board question ('what counts as significant for us?') is: the EU left it to your judgement, here are the three factors from Recital 101, here is the decision log we will produce on the day, here is who signs it, here is the BSI reporting form we will file. The defensible answer is not a number. It is a written decision.
The incident module on nisd2.eu captures your classification reasoning as a structured field tied to Art. 23(3). For digital-infrastructure entities, the CIR Art. 3, 4 and 5 numbers show up as guard rails. For everyone else, the three Recital 101 factors appear as a guided template, the reasoning gets signed and time-stamped, and the record feeds the 24-hour and 72-hour reports.
The output is a record you can defend: the decision, the reasoning, the signer, the timestamp. That is what the competent authority and the BSI ask for after a borderline event. It is also what protects the management body under Art. 20 NIS 2 if someone disputes the call later.
- Directive (EU) 2022/2555 (NIS 2), Art. 23 and Recital 101: eur-lex.europa.eu/eli/dir/2022/2555/oj
- Commission Implementing Regulation (EU) 2024/2690, Articles 1, 3, 4, 5 to 14: eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- BSIG §32 (Germany): bsi.bund.de regulatory portal
- ENISA Technical Implementation Guidance on NIS 2 incident reporting (TIG): enisa.europa.eu
- BSI MIRP reporting form and incident guidance: bsi.bund.de