What is a significant incident under NIS2? The legal test, the thresholds for digital providers, and how to decide fast

Under Article 23(3) of NIS2, an incident is significant if it has caused or can cause severe operational disruption or financial loss for the entity, or considerable material or non-material damage to others. The directive sets no number. Cloud, data centre, managed service and other digital providers have concrete thresholds in Implementing Regulation (EU) 2024/2690.

This guide covers the legal test, who decides, the thresholds for digital providers, national criteria, a decision tree, the difference from a GDPR personal data breach, what the test leaves open, and a checklist.

Layer	Applies to	Significant if	Source
General test	All essential and important entities	Severe operational disruption or financial loss for the entity, or considerable damage to others, caused or possible	NIS2 Art. 23(3)
Digital provider criteria	DNS, TLD, cloud, data centre, CDN, MSP, MSSP, online platforms, trust services	Direct loss above €500,000 or 5% of turnover, whichever is lower; other general criteria; recurring incidents; service thresholds	Reg. 2024/2690 Arts 3 to 14
National criteria	Depends on the country	Factors or thresholds some authorities add	National law and guidance

What is a significant incident under NIS2?

An incident is any event compromising the availability, authenticity, integrity or confidentiality of data or of the services your systems provide (Article 6(6)). Most incidents are not significant.

Article 23(3) sets the test. An incident is significant if:

1. “it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned”; or
2. “it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage”.

The first limb looks inward, at your services and your money. The second looks outward, at customers, users and anyone else your incident reaches. Either is enough.

What does “capable of causing” mean?

You do not wait for the damage. An intrusion contained at hour three that could have stopped your core service can be significant. Recital 101 describes reporting incidents that, “based on an initial assessment carried out by the entity concerned, could cause” severe disruption, loss or damage. Ransomware found on a production system is the textbook case, covered in NIS2 and ransomware.

What should the assessment weigh?

“Severe” and “considerable” are not defined. Recital 101 says the initial assessment should weigh the affected systems, “in particular their importance in the provision of the entity’s services”, the severity and technical characteristics of the threat, any vulnerabilities being exploited, and your experience with similar incidents. It adds that “the extent to which the functioning of the service is affected, the duration of an incident or the number of affected recipients of services” can show whether a disruption is severe. Payroll down for a morning and your customer platform down for a morning are different incidents.

Who decides whether an incident is significant?

You do. Article 23(1) puts the duty to notify on the entity, and recital 101 bases it on the entity’s own initial assessment.

For the digital providers covered by Regulation 2024/2690, its recital 31 adds when you count as “aware”: when, after a timely initial assessment, you have “a reasonable degree of certainty that a significant incident has occurred”. The assessment itself has to be timely, so a slow one does not buy time.

The authority’s view comes afterwards. It can order you to fulfil the Article 23 reporting obligations in a specified manner and within a specified period (Articles 32(4)(d) and 33(4)(d)). For essential entities, a significant incident can justify an ad hoc audit (Article 32(2)(c)). Infringing Article 23 is subject to fines under Article 34.

Two consequences follow, both practice rather than law:

• Record every assessment, including those you decide not to report: time, facts known, criterion considered, outcome.
• A borderline incident reported with your reasoning is easier to defend than one you kept to yourself. Below the threshold, Article 30 still lets you notify incidents, cyber threats and near misses voluntarily.

Once an incident is significant, the deadlines are in the NIS2 incident reporting timeline.

What are the NIS2 reporting thresholds for digital providers?

Article 23(11) required the Commission to specify when an incident is significant for certain digital providers. It did so in Implementing Regulation (EU) 2024/2690, in force since 7 November 2024 and directly applicable in every Member State. It covers DNS service providers, TLD name registries, cloud, data centre and content delivery network providers, managed service and managed security service providers, online marketplaces, search engines and social networks, and also trust service providers, which Article 23(11) did not list.

The general criteria, Article 3

An incident is significant for these providers if one or more of the following apply:

• direct financial loss, caused or possible, above €500,000 or 5% of the previous year’s total annual turnover, whichever is lower;
• exfiltration of trade secrets, caused or possible;
• death, or considerable damage to a person’s health, caused or possible;
• a successful, suspectedly malicious and unauthorised access to systems, capable of causing severe operational disruption;
• the recurring-incident test in Article 4, or a service criterion in Articles 5 to 14.

Scheduled maintenance does not count. Under recital 36, direct financial loss includes replacement hardware and software, staff costs and overtime, contractual penalties, customer compensation, forgone revenue, and communication, legal, forensic and remediation costs. Administrative fines and normal running costs do not.

Recurring incidents, Article 4

Incidents that are not significant alone become one significant incident if they occurred at least twice within six months, share the same apparent root cause, and together exceed the financial-loss threshold. You only catch this if your incident log records root causes.

Service-specific criteria, Articles 5 to 14

Any one criterion is enough. Users are counted in the EU; under Article 3(3) they include customers with a contract and people associated with your business customers. Where two figures are given, the smaller applies.

Article	Provider	Significant if, for example
5	DNS service providers	Completely unavailable over 30 minutes; responses over 10 seconds for over an hour; data compromised (narrow misconfiguration exception)
6	TLD name registries	Authoritative resolution completely unavailable, any duration; responses over 10 seconds for over an hour; technical data compromised
7, 9, 10	Cloud, CDN, MSP, MSSP	Completely unavailable over 30 minutes; limited for over 5% of users or 1 million for over an hour; data compromised by suspected malicious action, or for over 5% or 1 million users
8	Data centres	Completely unavailable; limited for over an hour; data compromised by suspected malicious action; physical access compromised
11 to 13	Marketplaces, search engines, social networks	Completely unavailable, or limited, for over 5% of users or 1 million; data compromised by suspected malicious action, or for over 5% or 1 million users
14	Trust service providers	Completely unavailable over 20 minutes; unavailable over one hour per calendar week; limited for over 1% or 200,000 users or relying parties; physical access compromised; data compromised for over 0.1% or 100 users

Note the criterion on suspected malicious action: in Articles 7 to 13, a compromise of service data by a suspected malicious action is significant with no size condition. For an MSP, a suspected attacker in the tools used to manage customer environments can meet it before any customer notices. More in NIS2 for managed service providers.

Can national rules add thresholds?

Yes. NIS2 sets a minimum: Article 5 lets Member States adopt or maintain provisions ensuring a higher level of cybersecurity, which leaves room for national laws and authorities to add detail to the general test. Article 23(11) also lets the Commission adopt significance rules for other entities; so far, 2024/2690 covers only the digital providers above.

Luxembourg’s regulator, for example, asks entities which factors apply: number and share of users affected, duration, geographical spread, direct financial loss, material and non-material damage, reputational damage or media coverage, exfiltration of trade secrets or other sensitive information, death or harm to health, and unauthorised access. The procedure is in NIS2 incident notification in Luxembourg. Check your own authority’s guidance before you write your criteria.

How do you decide fast? A decision tree

NIS2 SIGNIFICANT INCIDENT: FIRST-HOURS DECISION

0. Incident? Record the time and who is assessing. Go to 1.

1. Are you a digital provider covered by Regulation 2024/2690?
   Yes -> go to 2.        No -> go to 4.

2. Article 3: any of these, now or potentially?
   [ ] direct loss > EUR 500,000 or 5% of turnover (lower)
   [ ] exfiltration of trade secrets
   [ ] death, or considerable damage to health
   [ ] successful, suspected malicious, unauthorised access
       able to cause severe operational disruption
   Yes -> SIGNIFICANT.    No -> go to 3.

3. Your service criterion in Articles 5 to 14 met?
   Or recurring: at least twice in 6 months, same apparent
   root cause, together above the loss threshold (Article 4)?
   Yes -> SIGNIFICANT.
   No  -> not significant on the Regulation's criteria.
          Record why. Reassess as facts change.

4. Article 23(3), everyone else:
   a) severe operational disruption of your services, or
      financial loss for you, caused or possible?
   b) considerable material or non-material damage to
      others, caused or possible?
   Weigh: systems hit, share of service affected, duration,
   recipients affected, threat. Apply national criteria.
   Yes to a) or b) -> SIGNIFICANT.
   Borderline -> decide, record the reasoning.
                 In practice, reporting is easier to defend.

5. SIGNIFICANT -> early warning within 24h of becoming aware.
   Personal data involved? Run the GDPR test in parallel.

Is a significant incident the same as a GDPR personal data breach?

No. The two tests ask different questions, and one incident can meet either, both or neither.

	NIS2 significant incident	GDPR personal data breach
What it is	Severe disruption or financial loss for you, or considerable damage to others, caused or possible	A breach of security leading to destruction, loss, alteration, unauthorised disclosure of, or access to, personal data
Who reports	The essential or important entity	The controller
Threshold	The significance test	Report unless unlikely to result in a risk to people
To whom	CSIRT or competent authority	Data protection authority

Three examples, as practice:

• Ransomware encrypts the production platform and copies customer records: likely both.
• A denial-of-service attack takes a customer portal down for hours, with no personal data touched: can be significant under NIS2, and is not a personal data breach.
• An email containing one customer’s health data goes to the wrong person: a personal data breach that may need notifying, and rarely a significant incident.

The authorities talk to each other: where a NIS2 authority finds that an infringement of Article 21 or 23 can entail a notifiable personal data breach, it informs the data protection authority (Article 35). More in NIS2 and GDPR.

What does the significance test leave open in practice?

The law gives you criteria, not inputs. Every threshold in 2024/2690 is a measurement: minutes of unavailability, a share of EU users, euros of direct loss. Even under the general test, recital 101 points to how many recipients were affected and for how long. If you cannot measure it at hour two, you cannot decide at hour two. Closing that gap is work done before the incident:

• a map from systems to services to customers, with user counts, so “5% of users” is a lookup;
• availability monitoring that records when each service went down and came back;
• a loss estimate per service and per hour of outage, so €500,000 is a calculation, not a debate;
• searchable logs, kept long enough to show whether access was malicious and what it reached;
• a named decider and deputy, and one incident record holding every assessment.

Most of that data already sits in your monitoring, identity and ticketing systems, if something collects and connects it. The CloudSoul platform does this continuously: automated evidence collection, with human-in-the-loop expertise for calls a tool should not make alone, such as whether an incident is significant. The wider programme is on the NIS2 compliance page.

NIS2 significant incident checklist

• Write the Article 23(3) test in terms of your own services: what severe disruption and considerable damage mean for each.
• If you are a digital provider, list the 2024/2690 criteria that apply to you and the measurement behind each.
• Keep a service map with user counts and a loss estimate per hour of outage.
• Name who decides significance, and a deputy, both reachable out of hours.
• Record every assessment, including the incidents you decide not to report.
• Record root causes, so a second incident within six months is caught.
• Run the GDPR breach assessment in parallel, from the same incident record.

Sources

• Directive (EU) 2022/2555 (NIS2), Articles 5, 6, 23, 30, 32, 33, 34 and 35 and recital 101, EUR-Lex.
• Commission Implementing Regulation (EU) 2024/2690, Articles 1, 3 to 14 and 16 and recitals 31 and 36, EUR-Lex.
• Regulation (EU) 2016/679 (GDPR), Articles 4(12), 33 and 34, EUR-Lex.
• ILR, Incident notification, updated 6 July 2026.

Frequently asked questions