NIS2 significant incident threshold: a decision tree for the on-call team

Every NIS2 reporting obligation in Article 23 of Directive (UE) 2022/2555 hinges on a single qualifier: the incident must be significant. Below the threshold, the entity owes nothing to the regulator. Above it, the 24-hour, 72-hour and one-month clocks start running. The cost of getting this judgement wrong runs in both directions — over-report and the CSIRT drowns; under-report and the supervisor opens an enforcement file under Article 32.

Eighteen months after entry into force, the NIS2 significant incident threshold remains the most-asked operational question on this directive. Article 23(3) gives the principle. Implementing Regulation (UE) 2024/2690 gives the numbers — for the seven sectors it covers. Everywhere else, the entity has to decide. This guide turns the legal definition into a decision tree your duty officer can run at 03:00.

1. The directive's two-part test

Article 23(3) defines a significant incident as one that meets either of two conditions:

• 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.

Two operative phrases load the test: is capable of causing — the threshold catches near-miss incidents whose impact was avoided only by chance — and considerable — undefined in the directive itself, deferred to implementing acts and supervisory practice.

Recital 101 frames the assessment as a judgement, not an automatic trigger. The CSIRT and the competent authority expect the entity to be the first instance of evaluation, subject to challenge. That makes the on-call team's reasoning, not just the outcome, part of what the regulator will read.

2. What Implementing Regulation 2024/2690 quantifies

The Commission's Implementing Regulation, adopted 17 October 2024, sets concrete thresholds for seven sector categories: 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, online marketplaces, online search engines, social networking service platforms, and trust service providers.

For these, an incident is significant when it crosses one of three quantified bands. Translated into operational language:

• Availability impact — the service is unavailable for a stated duration to a stated number of users (e.g. one hour for 5% of EU users on a cloud service is significant; thresholds vary by service type and entity size).
• Data confidentiality / integrity impact — non-trivial unauthorised access to or modification of customer data.
• Cascading impact — the incident affects another in-scope provider that depends on the disrupted service.

The exact numbers per service type sit in the annexes of 2024/2690 and are the operational reference. CISOs in those sectors must read them once and pin the table to the SOC wall.

3. What the seven sectors don't cover — the qualitative test

For the eleven other NIS2 sectors (energy, transport, banking, financial market infrastructures, health, drinking water, waste water, public administration, space, postal services, waste management, manufacture of chemicals/food/medical-device/computer/transport-equipment/machinery, digital providers not in the IR list, research, agri-food production), the IR thresholds do not apply. The qualitative two-part test of Article 23(3) does — supplemented by the entity's own pre-defined classification matrix.

A defensible matrix uses three axes:

• Service criticality — is the affected service in the entity's continuity plan as a tier-1 dependency?
• Customer impact — number of affected users; whether vulnerable populations (patients, energy customers in winter) are touched.
• Containment confidence — is the incident bounded, or could it escalate without intervention?

When two of three axes hit a pre-agreed level, the incident is significant. The matrix is approved by the board under Article 20 and reviewed annually. ENISA's published incident-handling guidance — referenced in the Cooperation Group's NIS2 implementation work — points consistently to this kind of pre-defined classification as the operational standard.

The NIS2 significant incident threshold is not a number you hit. It's a judgement you defend — with the on-call team's reasoning timestamped at the moment of awareness.

4. The decision tree your duty officer runs at 03:00

By the time the on-call analyst is staring at a SIEM alert in the small hours, the legal definition is too abstract. They need a four-question runbook, written in advance, that produces one of three outcomes: notify, do not notify, escalate to the CISO for a judgement call.

1. Is the affected service in our IR 2024/2690 service catalogue? If yes, apply the quantified thresholds from the annex. If no, continue.
2. Has the incident caused or is it capable of causing severe operational disruption to a service we provide? Severe = failure of a tier-1 service, financial loss above an entity-defined material threshold, or service degradation affecting more than an entity-defined percentage of users.
3. Does the incident touch other natural or legal persons in a way that is more than minor? Examples: data exfiltration, cascading outage in a customer's NIS2 obligations, public health or safety impact.
4. If two or more of axes 2–3 are unclear, escalate to the CISO. Default to notification rather than delay — the 24h early warning is a flag, not a conclusion, and can be corrected at the 72h notification.

Question 4 is the most important rule. Article 23(4)(a) lets entities update an early warning at the 72-hour notification with substantive information; the directive explicitly anticipates incomplete first reporting. Defensive over-notification at the 24-hour mark is cheaper than missed deadlines.

5. Cross-border, cross-regulation: where significance multiplies

Two amplifiers turn a borderline incident into a clearly significant one:

• Cross-border impact. Article 23(4)(a) requires the early warning to flag whether the incident is suspected to have cross-border impact. If your service is consumed in another Member State, a duty of care to notify that State's CSIRT is added. The Cooperation Group's pan-European incident-coordination framework is built on this signal.
• Overlap with GDPR / DORA / CRA. A NIS2 significant incident frequently triggers parallel obligations. A personal-data breach feeds Article 33 GDPR (also 72 hours, but with a different starting clock — awareness of the breach, not awareness of the incident). A financial-services entity falls under DORA's incident-reporting regime in parallel. CRA-covered products with digital elements add a third channel. Mapping these in advance — which regulator gets which form, on which clock — is the only way to avoid a missed-deadline failure mode under one regime when responding to the other.

The site's own practical guide of the 72 hours walks through the reporting cadence once a significant incident is confirmed. This article sits upstream — answering the question of whether the cadence applies in the first place.

What good looks like

Three signals come up consistently in published supervisory guidance from ANSSI, BSI, INCIBE, ACN, NCSC-IE and ENISA on incident-significance assessment:

1. A board-approved classification matrix — not a one-page memo, a written matrix with the three or four axes the entity uses to score incidents, last reviewed within twelve months, signed by the board under Article 20.
2. A timestamped reasoning trail — for each incident the duty officer assessed, the matrix scores at the moment of awareness, the resulting decision (notify / do not notify), and the named officer who took it. Pulled from the ticketing system, not reconstructed afterwards.
3. An annual recalibration — the threshold values in the matrix are reviewed against the year's actual incidents and adjusted. Static thresholds drift away from operational reality and become a defendability liability after eighteen months.

None of these documents is exotic. They live in mature incident-management programmes already. The work for the next twelve months, for entities that have not yet codified them, is to write them down — before the first significant incident lands.

Sources

1. Directive (UE) 2022/2555, Article 23 ("Reporting obligations").
2. Directive (UE) 2022/2555, Article 23(3) (definition of "significant incident").
3. Directive (UE) 2022/2555, Recital 101 (assessment of significance as a judgement).
4. Commission Implementing Regulation (UE) 2024/2690 of 17 October 2024 (technical and methodological requirements; significance thresholds for digital service providers and related entities).
5. Directive (UE) 2022/2555, Article 32 ("Supervisory and enforcement measures in respect of essential entities").
6. Implementation guidance published by national competent authorities — ANSSI (FR), BSI (DE), INCIBE (ES), ACN (IT), NCSC-IE (IE) — and by ENISA via the NIS Cooperation Group.