Part of the NIS2 guide
When Is an Incident Significant Under NIS2? The Thresholds in Implementing Regulation 2024/2690
NIS2's 24-hour clock starts only for significant incidents, so the first question in any incident is whether it is one. For most sectors the directive gives a general test. For digital infrastructure and digital service providers, Implementing Regulation (EU) 2024/2690 turns it into hard numbers. Here they are, in one place.
The general test in the directive
Under Article 23(3) of NIS2 (Directive (EU) 2022/2555), an incident is significant if it:
- has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned; or
- has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.
Note "is capable of": the test looks at potential impact, not only what has already happened. For most sectors, this general test, plus any national guidance, is what you apply. Significant incidents must then be reported in stages: early warning within 24 hours, notification within 72 hours, final report within one month; see NIS2 incident reporting.
Who the detailed thresholds apply to
Implementing Regulation (EU) 2024/2690 applies to DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online marketplaces, online search engines and social networking services platforms, and trust service providers (Article 1). For them, an incident is significant if it meets one or more of the general criteria in Article 3 or the criteria for their provider type in Articles 5 to 14.
General criteria for all these providers (Article 3)
| Criterion | Article |
|---|---|
| Direct financial loss above €500,000 or 5% of total annual turnover of the preceding financial year, whichever is lower (caused or capable of causing) | 3(1)(a) |
| Exfiltration of trade secrets of the entity | 3(1)(b) |
| Death of a natural person | 3(1)(c) |
| Considerable damage to a natural person's health | 3(1)(d) |
| A successful, suspectedly malicious and unauthorised access to network and information systems capable of causing severe operational disruption | 3(1)(e) |
| Recurring incidents: at least twice within six months, same apparent root cause, together meeting the financial loss criterion | 3(1)(f), 4 |
Scheduled interruptions and the planned consequences of scheduled maintenance are not significant incidents (Article 3(2)). When counting users, include customers with a contract giving access to your systems or services, and the people associated with business customers who use them (Article 3(3)).
Thresholds by provider type
In the table, "5% / 1 million" means more than 5% of the service's users in the EU or more than 1 million of them, whichever number is smaller.
| Provider | Availability | Data (integrity, confidentiality, authenticity) | Article |
|---|---|---|---|
| Cloud computing | Completely unavailable > 30 minutes; or limited for 5% / 1 million users for > 1 hour | Compromised by a suspectedly malicious action; or compromised affecting 5% / 1 million users | 7 |
| Managed service and managed security service providers | Completely unavailable > 30 minutes; or limited for 5% / 1 million users for > 1 hour | Compromised by a suspectedly malicious action; or compromised affecting 5% / 1 million users | 10 |
| Content delivery networks | Completely unavailable > 30 minutes; or limited for 5% / 1 million users for > 1 hour | Compromised by a suspectedly malicious action; or compromised affecting 5% / 1 million users | 9 |
| Data centre services | Completely unavailable (any duration); or limited for > 1 hour | Compromised by a suspectedly malicious action; or physical access to the data centre compromised | 8 |
| DNS service providers | Recursive or authoritative resolution completely unavailable > 30 minutes; or average response time > 10 seconds for > 1 hour | Data of the authoritative resolution service compromised, except misconfiguration affecting fewer than 1,000 domain names and no more than 1% of those managed | 5 |
| TLD name registries | Authoritative resolution completely unavailable (any duration); or average response time > 10 seconds for > 1 hour | Data related to the technical operation of the TLD compromised | 6 |
| Online marketplaces, search engines, social networks | Completely unavailable for 5% / 1 million users; or 5% / 1 million users affected by limited availability | Compromised by a suspectedly malicious action; or compromised affecting 5% / 1 million users | 11, 12, 13 |
| Trust service providers | Completely unavailable > 20 minutes; or unavailable > 1 hour per calendar week; or limited availability for more than 1% of users or relying parties or 200,000, whichever is smaller | Compromised affecting more than 0.1% of users or relying parties or 100, whichever is smaller; or restricted physical access compromised | 14 |
Read the data criteria carefully: for cloud, CDN, managed services and the platforms, any compromise of service data by a suspectedly malicious action is significant on its own, regardless of how many users are affected. A single targeted intrusion can trigger reporting.
For everyone else
Entities outside the list, for example in energy, transport, health, manufacturing or food, apply the general test in Article 23(3) and their national authority's guidance. Check whether your national authority has published criteria or examples. The 2024/2690 numbers can still be a useful benchmark for internal triage rules.
Turning the thresholds into triage
- Translate the thresholds for your provider type into monitoring alerts: outage duration, share of users affected, response times.
- Decide in advance who confirms "suspectedly malicious" and who estimates financial loss, and record the time of each decision.
- Keep a running count of minor incidents by root cause, so recurring incidents are caught within the six-month window.
- Exclude planned maintenance explicitly, with a change record to show it was scheduled.
- Run a tabletop exercise against the thresholds; see tabletop exercise scenarios.
Managed service providers have their own guide: NIS2 for MSPs and MSSPs.
Classify fast when it matters. The Incident Response Playbook includes a master incident response plan, six scenario playbooks, regulatory notification templates and tabletop exercise scenarios.
Sources
- Directive (EU) 2022/2555 (NIS2), Article 23, EUR-Lex
- Commission Implementing Regulation (EU) 2024/2690, Articles 1 and 3 to 14, EUR-Lex
Related tools
Further reading: NIS2 Incident Reporting · NIS2 for Managed Service Providers
ClevSec
Compliance & security tools for modern businesses
We build practical tools and templates that help startups and SMBs stay compliant with NIS2, GDPR, and DORA. Explore our free tools →
This article is for informational purposes only and does not constitute legal advice. Last updated: October 2026.