What is a significant incident under NIS2?

An incident is significant under NIS2 if it has caused or can cause severe operational disruption or financial loss for your organisation, or if it has affected or can affect others by causing considerable material or non-material damage. Only significant incidents trigger the 24-hour reporting duty.

The two criteria in Article 23(3)

NIS2 does not ask you to report every incident. It asks you to report significant ones. Article 23(3) of the directive says 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
it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.

One criterion is enough. Note the words "is capable of": an incident you contained before it did harm can still be significant if it could have caused that harm.

Stricter, numeric thresholds for some digital providers

For certain types of entity, the Commission made the criteria concrete in Implementing Regulation (EU) 2024/2690 [2]. It covers digital infrastructure and digital provider types such as DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, managed service providers, managed security service providers and online marketplaces, among others. If you are one of these, the regulation's thresholds apply on top of the directive.

Some examples of what the regulation sets [2]:

General financial threshold (Article 3): the incident has caused or can cause direct financial loss above EUR 500 000 or 5% of the entity's total annual turnover in the preceding financial year, whichever is lower.
Recurring incidents (Article 4): incidents that are not significant on their own count together as one significant incident if they occurred at least twice within six months, have the same apparent root cause, and together meet the financial criterion.
Cloud computing providers (Article 7): among other things, a service that is completely unavailable for more than 30 minutes.
DNS service providers (Article 5): among other things, a recursive or authoritative resolution service that is completely unavailable for more than 30 minutes.

These are not all the criteria. Read the article for your entity type in the regulation itself before you rely on a number.

What if you are not covered by the regulation?

Most entities in sectors such as energy, transport or health are not in the list of the implementing regulation. For them, the test in Article 23(3) applies as written [1], and national law or guidance from the national authority may add detail. This means you have to make a reasoned judgement, so it helps to agree in advance what "severe" means for your services. For example: which systems, if down for how long, would stop you from delivering your core service?

A decision checklist

Use these questions in the first hours. Write the answers down with the time you answered them.

Is it an incident? Has an event compromised the availability, authenticity, integrity or confidentiality of data or of the services your systems provide?
Disruption: Has it caused, or could it cause, severe disruption of the services you provide? Name the service and the impact.
Financial loss: Has it caused, or could it cause, financial loss for you? If you are covered by Regulation 2024/2690, compare against the EUR 500 000 or 5% threshold.
Others harmed: Could customers, patients, suppliers or other persons suffer considerable material or non-material damage?
Sector thresholds: If you are a cloud, DNS, data centre, managed service or other provider covered by the regulation, does any numeric threshold for your type apply?
Recurrence: Have you seen the same root cause before in the last six months?
Decision: Significant, not significant, or not sure yet. If not sure, set a time to decide again.

If the answer to any of questions 2 to 6 is yes, treat the incident as significant and start the clock described in the 24-hour, 72-hour and one-month deadlines.

Worked example

A managed service provider runs remote monitoring for about 40 small business clients. On a Friday at 18:00 its monitoring platform goes fully offline after a faulty update. Engineers restore it at 18:50.

As a managed service provider, it is one of the entity types covered by Regulation 2024/2690 [2], so it checks the article for its type, not only the general test.
The outage lasted 50 minutes and affected the whole service. The provider compares this with the availability criteria in the regulation for managed service providers.
No sign of malicious activity: the cause is a bad update. That does not decide the question. Significance is about impact, not about whether an attacker was involved.
Outcome: the team records the facts, the article it compared against and its conclusion, with the time. If significant, the early warning is due 24 hours after the moment it became aware.

The point of the example is the process: name the criterion, compare the facts, record the decision and the time. That record is what you show the authority later if they ask why you did or did not report.

Common mistakes

Waiting for certainty. The test includes harm the incident is "capable of" causing. Waiting until you know the full impact can mean missing the 24 hours.
Thinking only about attacks. Outages from failed changes or hardware can also be significant.
Ignoring small repeats. Under the regulation, repeated incidents with the same cause can add up to one significant incident [2].
Not writing down a "no". A decision not to report is also a decision. Record the reason.

Once you decide an incident is significant, the next job is the text of the reports. The NIS2 incident report template follows the content Article 23 asks for.

Related guides

Sources

This guide explains the rules in plain language. It is not legal advice. Check your own country's law and, when in doubt, ask a qualified adviser.