NIS2 Incident Classification: The 5 Questions That Settle Significant vs Non-Significant Before the 24-Hour Clock Runs Out

Your monitoring flags a confirmed intrusion at 09:14. Someone asks the only question that matters for the next 24 hours: do we file? The usual answer — we don’t know enough yet — is the most expensive sentence in NIS2 incident response, and it rests on a misreading of the test.

Article 23(3) of Directive (EU) 2022/2555 does not ask what an incident did. It asks what it "has caused or is capable of causing". That phrase appears exactly once in the entire Directive, and it is doing enormous work: significance is assessed on capability, not on confirmed outcome. Forensics tell you what actually happened, and you will not have them for days. Capability you can usually assess in ten minutes, because it turns on what the affected systems do and who depends on them — facts a duty manager already knows.

What follows is an ordered decision procedure built from that reading: five binary questions, each answerable from information available during the first ten minutes of an incident. Three of them can end the analysis outright.

The Five Questions, in Order

Order matters. Questions 1 to 3 are exclusion gates — a "no" (or, for Question 3, a "yes") stops the analysis and no Article 23 report is due. Only Questions 4 and 5 involve the significance test itself, and Question 4 determines which yardstick Question 5 uses.

#	Question	Legal source	Effect of the answer
1	Is this an incident at all, rather than a near miss or a vulnerability?	Art. 6(6), 6(5), 6(15)	No → stop. No Article 23 duty. Voluntary route under Article 30 remains open.
2	Did it affect the systems you use to provide your regulated service?	Art. 23(1) vs Art. 21(1)	No → stop. An Article 21 risk-management matter, not an Article 23 reporting matter.
3	Is it a scheduled interruption or a planned consequence of maintenance?	CIR 2024/2690 Art. 3(2)	Yes → stop. Expressly not a significant incident.
4	Which significance test actually binds you?	Art. 23(11); CIR Art. 1; national guidance	Selects the yardstick for Question 5. The answer differs by member state.
5	Does it clear either limb of Article 23(3), alone or aggregated?	Art. 23(3); CIR Art. 3, Art. 4	Yes → significant. The 24-hour early-warning clock applies.

The procedure applies to essential and important entities within the scope of Article 2 — broadly, medium-sized and larger entities of a type listed in Annex I or II, plus certain entities regardless of size, including trust service providers, DNS service providers and TLD name registries.

Question 1: Is It Even an Incident?

Nearly every published guide opens at Article 23(3). That skips a gate the Directive builds in: Article 23(1) requires notification of "any incident that has a significant impact", so the Article 6(6) definition is a precondition, not background reading.

Article 6(6) defines an incident as "an event compromising the availability, authenticity, integrity or confidentiality of stored, transmitted or processed data or of the services offered by, or accessible via, network and information systems". Two neighbouring definitions do the exclusion work:

• Near miss — Article 6(5): an event that "could have compromised" those properties "but that was successfully prevented from materialising or that did not materialise". A blocked attack is not an incident, however alarming the telemetry.
• Vulnerability — Article 6(15): "a weakness, susceptibility or flaw of ICT products or ICT services that can be exploited by a cyber threat". An unexploited flaw creates no Article 23 duty regardless of its severity score, a point developed further in our guide to zero-day disclosure and the Article 12 route.

The trap runs the other way too. Because availability dominates intuition, teams under-call integrity events — yet Article 6(6) makes integrity and authenticity co-equal with availability. An altered record, a tampered configuration or a suppressed alert is an incident even with uptime untouched. Where an attack is executed entirely outside your estate, as in some business email compromise cases, whether Question 1 is cleared at all becomes genuinely contested rather than obvious.

Question 2: Did It Touch the Systems That Deliver Your Service?

The Directive draws a boundary here that is easy to miss because the two provisions sit close together and read almost alike.

Article 21(1) attaches the risk-management duty to network and information systems "which those entities use for their operations or for the provision of their services". Article 23(1) narrows the reporting trigger to incidents with significant impact "on the provision of their services". Operations are in scope for one duty and not the other.

Corporate email, HR systems and finance platforms are unambiguously operational, and frequently not service-providing. An incident confined to them is always an Article 21 matter and only sometimes an Article 23 matter. Two cautions keep this from becoming an escape hatch: Article 6(6) covers services "accessible via" your systems, so an indirect dependency still counts; and a supervisor reviewing your Article 21 controls is not bound by the reporting threshold you applied. Deciding not to report is not the same as deciding nothing happened — a distinction that matters particularly for insider incidents, where the affected systems are often internal by definition.

Question 3: Is It Excluded as Planned Maintenance?

Article 3(2) of Commission Implementing Regulation (EU) 2024/2690 states that "scheduled interruptions of service and planned consequences of scheduled maintenance operations carried out by or on behalf of the relevant entities shall not be considered to be significant incidents".

The phrase "by or on behalf of" is the operative detail, and no competing guide we reviewed cites this provision at all. It reaches your provider’s announced maintenance windows, not only your own. An announced migration window at a hosting provider sits outside the regime; an unplanned failure at the same provider does not, as our analysis of cloud outage reporting sets out.

Two limits. The carve-out does not stretch to cover the consequences of emergency remediation you chose to perform, however necessary. And a breached service-level agreement is a contractual matter, not a reporting trigger — your SLA is not your significance threshold. Formally, Article 3(2) binds the entities named in Article 1 of the Implementing Regulation; for everyone else it is persuasive rather than binding, which brings us to the question that decides the rest of the analysis.

Question 4: Whose Significance Test Actually Binds You?

Article 23(11) required the Commission to adopt implementing acts specifying when an incident is significant, and it named the sectors: 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, and providers of online marketplaces, online search engines and social networking services platforms. Ten categories. The next sentence reads: "The Commission may adopt such implementing acts with regard to other essential and important entities."

May, not shall. There is a checkable detail here worth pausing on: Article 1 of the Implementing Regulation covers eleven categories, adding trust service providers to the ten that Article 23(11) mandated. For significance criteria, the Commission has exercised its discretionary power exactly once, and not for any of the other sectors listed in Annexes I and II.

So if you operate in energy, manufacturing, health, water, transport, waste, food, chemicals, public administration, space, postal services or research, the absence of a numeric EU threshold is not an oversight to be filled by analogy. It is a drafting choice. What fills the gap instead is national guidance, and it does not fill it identically.

Which rulebook applies	What supplies the criteria	Direct financial-loss figure
One of the eleven categories in CIR Art. 1, any member state	CIR Art. 3(1) horizontal criteria plus the entity-specific criteria in Arts. 5 to 14	Exceeds EUR 500 000 or 5% of total annual turnover, whichever is lower
Germany, sectors outside those eleven	BSI treats the CIR Art. 3(1) criteria as a presumption, and treats failure or impairment of a critical service as always significant	EUR 500 000 or 5%, by presumption rather than by binding rule
Belgium, all NIS2 entities	CCB NIS2 Notification Guide v1.2, its own categories of significant incident	Exceeds EUR 250 000 or 5% of total annual turnover, whichever is lower
Other member states, sectors outside those eleven	The Art. 23(3) limbs plus any national competent authority guidance	No figure specified at EU level

Belgium’s figure is half the Implementing Regulation’s, and applies far more broadly. Both numbers appear in the same CCB document — the guide reproduces the CIR criteria separately — which is how secondary sources come to report the wrong one. One qualifier applies to every row: a euro figure only bites where the 5%-of-turnover alternative sits higher, which for the CIR means turnover above EUR 10 million, and in Belgium above EUR 5 million. Below that, the percentage governs and the headline number is irrelevant.

The practical instruction is narrow: identify the member state whose law regulates the affected service, name the guidance document and its version, and apply that. Do not import a threshold you read in a vendor blog written for a different jurisdiction. Our guide to the significance test and the sector-specific treatment of DDoS reporting thresholds go deeper on how the entity-specific criteria in Articles 5 to 14 operate.

Question 5: Does It Clear Either Limb of Article 23(3)?

The test has two limbs, joined by "or":

• (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"

Limb (a) is itself disjunctive, and this is the most commonly repeated error in circulation: financial loss is a free-standing trigger. No downtime is required. On the natural reading, "severe" attaches to operational disruption, not to financial loss, and Article 23(3) puts no figure on financial loss anywhere — which is precisely why the Implementing Regulation and national authorities had to supply their own.

Limb (b) points outward, at other people. It frequently fires when limb (a) does not: a data compromise that leaves your service running perfectly can still cause considerable damage to the individuals or businesses whose information was taken.

Then the check almost nobody runs in real time. Article 4 of the Implementing Regulation aggregates individually sub-threshold incidents into one significant incident where all three criteria are met: they occurred at least twice within six months, they share the same apparent root cause, and they "collectively meet the criteria set out in Article 3(1)(a)". That third limb is money only — so repeated short outages never sum by elapsed minutes into a reportable event, however irritating. They sum by euros or not at all. This is why the ten-minute triage should always include one question about the preceding six months.

For the eleven CIR-bound categories there is also a short circuit worth knowing: Article 3(1)(e) makes "a successful, suspectedly malicious and unauthorised access to network and information systems" that is "capable of causing severe operational disruption" significant on its own, with no euro calculation required. That criterion does a great deal of work in ransomware cases.

When You Genuinely Cannot Decide in Ten Minutes

Sometimes the answer is honestly unclear, and the clock is the reason it matters. Recital 31 of the Implementing Regulation states the awareness standard: an entity is "to be regarded as having become ‘aware’ of the significant incident when, after such initial assessment, that entity has a reasonable degree of certainty that a significant incident has occurred". Recitals explain intent and create no obligation, so treat it as the Commission’s own statement of how the standard is meant to work rather than as an operative rule — but note that it is the EU-level text, and the national guidance frequently quoted on this point is largely reproducing it.

National authorities then tighten it. Germany’s BSI defines the triggering moment (Kenntniserlangung) as the point at which an employee of the entity, during working hours, learns of a significant incident — not the point at which the security team confirms it. A colleague’s report can therefore start the clock before your SOC has reached a view. The same authority’s guidance states plainly that speed takes priority over completeness.

The decisive argument for filing under uncertainty is that the costs of being wrong are asymmetric by design:

• Wrongly deciding not to report exposes you to the enforcement regime in Article 34, which covers infringements of Article 21 or Article 23 alike. Note the drafting: member states must provide for fines of "a maximum of at least" EUR 10 000 000 or 2% of total worldwide annual turnover for essential entities, whichever is higher, and EUR 7 000 000 or 1.4% for important entities. That is a floor on the national ceiling, not a cap — a member state may transpose a higher maximum, so the widespread phrasing "fines of up to EUR 10 million" is wrong in both direction and kind.
• Wrongly deciding to report costs you comparatively little. Article 23(1) provides that "the mere act of notification shall not subject the notifying entity to increased liability". If the event turns out not to be an incident at all, the voluntary route under Article 30 carries its own protection: voluntary reporting "shall not result in the imposition of any additional obligations upon the notifying entity to which it would not have been subject had it not submitted the notification".
• Filing also buys you something. Under Article 23(5) the CSIRT or competent authority must respond, where possible within 24 hours of the early warning, with initial feedback and — on request — guidance or operational advice on mitigation, plus guidance on reporting to law enforcement where criminal conduct is suspected. The early warning is not a one-way filing; it opens a support channel while the incident is still live.

Documenting a "Non-Significant" Decision

When the answer is no, the deliverable is a written record, not silence. The reason is structural: because Article 23(3) is prospective, your classification will be judged on the capability assessment you made with the facts you had, not on how the incident eventually resolved. An incident that looked containable and then escalated is not evidence of a bad decision. An undocumented decision, however, offers nothing to show that any decision was made at all.

Role	Owns in the first ten minutes	Must be able to evidence later
Duty SOC lead / incident manager	Questions 1 to 3 — incident or near miss, service-providing systems or not, carve-out or not	Timestamped record of the facts as known at the decision point, not as later established
CISO / IT security manager	Question 5 — the technical judgement on capability of severe operational disruption	The recovery objective or availability baseline used as the yardstick, and why
Compliance officer / legal	Question 4 — which member state’s rulebook, which authority, which guidance version	The named guidance document, its version and date, and the jurisdictional reasoning
Management body	Sign-off on borderline "no" calls	Approval and oversight of the risk-management measures under Article 20(1), which is where management-body liability attaches

One nuance on that last row: Article 20(1) makes management bodies approve and oversee the Article 21 measures and provides that they can be held liable for infringements "of that Article" — Article 21. Personal liability under Article 20(1) is therefore tied to the risk-management regime, while the Article 34 fines reach both Article 21 and Article 23. The classification procedure itself is an Article 21 incident-handling control, which is what puts a repeatedly undocumented triage in front of the board rather than only in front of the SOC.

Finally, treat the classification as provisional. New information can flip the answer, and the clock runs from the point of reasonable certainty — which may arrive on day three. A structured re-assessment when material facts change is the difference between a late report and a missed one. Our complete NIS2 incident reporting guide covers the notification cascade that follows once the answer becomes yes.

Frequently Asked Questions

Do we have to report an attack our defences blocked?
No. Article 6(5) classifies an event that was "successfully prevented from materialising" as a near miss, and the Article 23 duty attaches to incidents. You may report it voluntarily under Article 30, which many entities do for threat-intelligence value, and Article 30 expressly protects you from picking up additional obligations by doing so.

Our sector has no numeric threshold. What do we actually apply?
The two limbs of Article 23(3) plus whatever your national competent authority has published. In Germany the BSI treats the CIR Article 3(1) criteria as a working presumption for sectors the Regulation does not bind, and treats failure or impairment of a critical service as always significant. In Belgium the CCB sets its own lower financial-loss figure. Neither is EU law of general application, so identify your own authority’s position rather than assuming the CIR numbers travel.

If a breach is notifiable under the GDPR, is it automatically a NIS2 significant incident?
No. The tests are different and run on separate clocks to different regulators. A personal-data breach engages the GDPR regime on its own terms; whether it is a NIS2 significant incident still depends on Article 23(3). The two frequently coincide, particularly through limb (b), but neither notification substitutes for the other.

What if we classify an incident as non-significant and later find it was worse?
Re-classify and file. The awareness standard turns on reaching a reasonable degree of certainty, so a properly documented initial assessment that was later overtaken by new facts is materially different from an assessment never made. This is exactly why the contemporaneous record matters more than the eventual outcome.

Can we withdraw a report we filed in error?
Not necessarily. Practice is national: the BSI, for example, states that a submitted report cannot subsequently be cancelled or withdrawn, and that corrections are made through a follow-up report instead. Check your own authority’s procedure before treating a filing as reversible — though given Article 23(1)’s protection against increased liability, an over-inclusive filing is rarely the expensive mistake.

Sources

• Directive (EU) 2022/2555 (NIS2) — Articles 2, 6, 20, 21, 23, 30 and 34. EUR-Lex, CELEX 32022L2555 (linked above).
• Commission Implementing Regulation (EU) 2024/2690 — Articles 1, 3, 4 and 5, and Recital 31. EUR-Lex, OJ L 2024/2690 (linked above).
• "NIS-2-Meldepflicht", Bundesamt für Sicherheit in der Informationstechnik (bsi.bund.de) — national guidance on significance for non-CIR sectors, the Kenntniserlangung trigger, and reporting practice.
• "NIS2 Notification Guide", version 10.2024 – 1.2, Centre for Cybersecurity Belgium (ccb.belgium.be) — Belgian categories of significant incident and the EUR 250 000 financial-loss figure. A later version 1.3 (August 2025) exists.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.