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 trade secrets; (c) the death of a natural person; (d) considerable damage to a natural person's health; (e) successful, suspectedly malicious and unauthorised access capable of causing severe operational disruption.
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.
General thresholds
EUR 500 000 or 5 percent of turnover (whichever is lower), trade secrets exfiltrated, a person killed, serious harm to a person's health, or a successful malicious intrusion that could cause severe disruption. Any one of these 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.
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