Significant incident under NIS 2
Two qualitative triggers, one regulation with numbers for certain digital providers, 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 to be significant for the purposes of Article 23(3) of Directive (EU) 2022/2555 with regard to the relevant entities where one or more of the following criteria are fulfilled: (a) the incident has caused or is capable of causing direct financial loss for the relevant entity that exceeds EUR 500 000 or 5 % of the relevant entity’s total annual turnover in the preceding financial year, whichever is lower; (b) the incident has caused or is capable of causing the exfiltration of trade secrets as set out in Article 2 point (1), of Directive (EU) 2016/943 of the relevant entity; (c) the incident has caused or is capable of causing the death of a natural person; (d) the incident has caused or is capable of causing considerable damage to a natural person’s health; (e) a successful, suspectedly malicious and unauthorised access to network and information systems occurred, which is capable of causing severe operational disruption; (f) the incident meets the criteria set out in Article 4; (g) the incident meets one or more of the criteria set out in Articles 5 to 14.
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)
Besonders wichtige Einrichtungen und wichtige Einrichtungen sind verpflichtet, folgende Informationen an eine vom Bundesamt und dem Bundesamt für Bevölkerungsschutz und Katastrophenhilfe eingerichtete gemeinsame Meldestelle zu melden: 1. unverzüglich, spätestens jedoch innerhalb von 24 Stunden nach Kenntniserlangung von einem erheblichen Sicherheitsvorfall, eine frühe Erstmeldung ...
Every member state has to turn Art. 23 into national law. §32 BSIG repeats the cascade and names as recipient a joint reporting office set up by the BSI and the Federal Office of Civil Protection and Disaster Assistance (BBK). It adds no number of its own for non-digital sectors. Austria's NISG 2026 has applied since 1 October 2026. France and the Netherlands had not notified their transposition by July 2026 (the Commission took them to the Court of Justice).
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 service providers (Art. 5): resolution fully down for more than 30 minutes, average response time above 10 seconds for more than an hour, or compromised data (except a misconfiguration affecting fewer than 1,000 domains and no more than 1 % of them). TLD registries (Art. 6): any complete outage of authoritative resolution, response time above 10 seconds for an hour, or any compromise of TLD data. Articles 7 to 14 set thresholds for cloud, data centres, CDNs, MSPs and MSSPs, marketplaces, search engines, social networks 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(2)).
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? The early warning can be updated in the 72-hour notification (Art. 23(4)(b)). For events below the line you can notify voluntarily without taking on extra duties (Art. 30).
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(2) 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 Abs. 2 BSIG implements this: entities in finance, social security, digital infrastructure, ICT service management and digital services must tell customers threatened by a significant cyber threat what they can do, where the customers' interests outweigh their own. Separately, the BSI can order an entity to tell its customers about a significant incident (§ 35 Abs. 1 BSIG), for example by publishing it on its website.
BSI guidance under §32 BSIG
The BSI repeats the definition of § 2 Nr. 11 BSIG and reads 'could cause' as: the effects could realistically happen. Reports go through the BSI portal. It publishes no number for non-digital sectors. The BSI notes that the federal interior ministry may later define 'significant' in more detail by ordinance (§ 56 Abs. 4 BSIG).
ENISA Technical Implementation Guidance
The ENISA Technical Implementation Guidance (TIG, version 1.0 of June 2025; its mapping table was updated to version 1.2 in 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 states
Austria's NISG 2026 has applied since 1 October 2026. France and the Netherlands had not notified their transposition by July 2026 (the Commission took them to the Court of Justice). Germany is the example used here.
Myth 1: We will know it when we see it.
Reality: Art. 23(4)(a) gives you 24 hours from becoming aware of a significant incident to send the early warning. In that time you have to decide, write the reasoning down, and be able to 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 can be one, if the outage severely disrupts the service or causes considerable damage to customers. NIS 2 is not GDPR.
Myth 3: Small incidents below the threshold do not stack.
Reality: For the CIR's digital providers, incidents with the same apparent root cause that happen at least twice in six months count as one significant incident if their financial losses together cross the Art. 3(1)(a) line (Art. 4 CIR). NIS 2 itself has no such rule, but a pattern of small incidents is still a reason to look again.
Annexes I and II of NIS 2 cover 18 sectors. Only the digital group in CIR Art. 1 (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.
- 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): gesetze-im-internet.de/bsig_2025
- ENISA, NIS2 Technical Implementation Guidance, version 1.0, 26 June 2025: enisa.europa.eu
- BSI, NIS-2 FAQ and the BSI portal: bsi.bund.de, portal.bsi.bund.de
In practice
Where this comes up in the walkthrough
The walkthrough turns this into steps you fill in, with the law explained beside each one. Open a step to see its screen, filled in for a made-up company.
Incident Handling
Know how to report an incident
Three reports to your authority, with fixed deadlines.
Incident Handling
Plan what happens in an incident
Who decides, whom you call, how you reach each other.
Been asked to handle NIS2?
In the end you have everything in one document: what is done, what is still open, and your management's approval with name and date. The app writes the texts.
