NIS2 doesn't require essential and important entities to report every disruption, failed login or blocked phishing email to their CSIRT. It requires them to correctly identify which incidents are "significant" and get that judgement right within a clock that starts ticking the moment they become aware of it. Article 23(3) of the Directive sets out exactly how that call is made, and it's a narrower, more specific test than most organisations assume.
Every NIS2 reporting deadline — the 24-hour early warning, the 72-hour incident notification, the one-month final report — is triggered by a single prior judgment: is this incident "significant"?
Miss that call in one direction and an organisation fails to report something a regulator expected to hear about within 24 hours. Miss it in the other direction and every report an organisation files starts looking like noise a competent authority learns to discount.
Article 23(3) of NIS2 defines exactly where that line sits, and it's worth reading closely rather than assuming it means "anything that felt bad."
NIS2 doesn't leave "significant" to organisational judgement alone. Article 23(3) states:
"An incident shall be considered to be significant if: (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."
Two things about this wording matter more than they first appear:
Trigger A — Severe operational disruption or financial loss to the entity itself. This asks whether the incident meaningfully degraded the services the entity provides, or cost the entity itself money, directly or through consequential loss. The bar is "severe," not "noticeable" — a brief, fully-contained blip that never touched service delivery sits below this threshold, while an outage that meaningfully interrupted the entity's core function sits above it.
Trigger B — Considerable material or non-material damage to other people. This shifts the lens outward, to clients, users, or any other natural or legal person affected by the incident. "Material" damage covers financial or physical harm; "non-material" damage extends to things like reputational or dignitary harm — a broader net than Trigger A, and one that can be met even when the entity's own operations barely felt the incident.
Unlike DORA's classification RTS, which sets out specific quantitative materiality thresholds for its six criteria, NIS2's Article 23(3) test is qualitative by design — it asks for a judgement about severity and materiality, not a percentage of clients affected or a euro figure crossed. That's a deliberate structural choice: NIS2 applies across a far wider range of sectors and entity sizes than DORA's financial-services scope, so a single numeric threshold would be either too strict for a small important entity or meaningless for a systemically significant one.
The practical consequence is that the judgement has to be exercised consistently, by trained people, against a documented internal standard — because the Directive itself won't do that calibration for you. An organisation that hasn't translated Article 23(3)'s language into its own operational thresholds (what "severe" disruption looks like for its specific services, what "considerable" damage looks like for its specific client base) is left improvising that judgment in the middle of an actual incident, under the same 24-hour clock the judgment is meant to trigger.
The inclusion of potential impact — not just realised impact — is easy to underweight. It means a near-miss with a credible worst-case scenario has to be assessed the same way as an incident that actually caused the harm. A ransomware attempt caught and contained before encryption completed, but which was capable of causing severe operational disruption had it succeeded, still needs to be run through the Article 23(3) test on its potential trajectory, not just its actual outcome. Teams that only escalate confirmed, realised impact are applying a narrower test than the Directive sets out.
Because the reporting clock starts from the moment an entity becomes aware that an incident meets this test, the significance assessment can't be reconstructed from first principles during a live incident without eating into the 24-hour window. This is precisely why the NIS2 Incident Response Document Library treats Significant Incident Assessment as one of its 13 core categories — the criteria, thresholds and escalation logic that operationalise Article 23(3) need to exist as a pre-built, rehearsed decision tool, mapped against the same 15 mandatory document profiles that cover the reporting templates the assessment feeds into.
A written assessment procedure also does something a mental judgment call can't: it creates a defensible, consistent record. If a competent authority later asks why an incident wasn't reported, "we judged it didn't meet Article 23(3)" is a far stronger answer when it points to a documented assessment applying pre-agreed internal thresholds, than when it's a retrospective justification built after the fact.
Internal thresholds for "severe" and "considerable" aren't static — they should shift as an organisation's services, client base, risk appetite and regulatory guidance evolve. A significance assessment procedure written once at NIS2 go-live and left untouched drifts out of alignment with the organisation it's meant to protect. The NIS2 Master Document Register tracks exactly this kind of artefact — with a named owner, review date and regulatory basis — as one row among the 146 documents it holds as the working, Excel-ready control sheet for the entire NIS2 incident response set, so the significance assessment procedure gets revisited on schedule rather than only when an ambiguous incident exposes that it's stale.
1. What is the legal definition of a "significant incident" under NIS2?
Article 23(3) defines a significant incident as one that has caused, or is capable of causing, severe operational disruption of services or financial loss for the entity concerned, or one that has affected, or is capable of affecting, other natural or legal persons by causing considerable material or non-material damage. Either condition alone is sufficient.
2. Does an incident need to meet both Article 23(3) conditions to be reportable?
No. The two conditions are independent alternatives. An incident that only causes severe disruption to the entity, with no third-party impact, still qualifies, just as one that only causes considerable harm to clients or other parties, with minimal impact on the entity's own operations, also qualifies.
3. Does NIS2 set numeric thresholds for what counts as "severe" or "considerable"?
No. Unlike DORA's classification RTS, which sets specific quantitative materiality thresholds, NIS2's Article 23(3) test is deliberately qualitative, reflecting the far broader range of sectors and entity sizes NIS2 covers. Organisations are expected to translate the language into their own documented, consistently applied internal thresholds.
4. Does a contained incident that didn't cause real harm still need to be assessed under NIS2?
Yes. Article 23(3) covers incidents that are "capable of causing" severe disruption or considerable damage, not only those that actually did. A near-miss with a credible worst-case scenario needs to be assessed on that potential impact, not dismissed because it was contained.
5. When does the NIS2 24-hour reporting clock start?
The clock starts from the moment an entity becomes aware that an incident meets the significance threshold under Article 23(3), which is why the significance assessment itself needs to be fast and pre-documented rather than debated from scratch during the incident.
6. What's the difference between the NIS2 Document Library and the Master Document Register for significance assessment documentation?
The NIS2 Incident Response Document Library explains what the Significant Incident Assessment category should contain and profiles the mandatory documents in full. The NIS2 Master Document Register is the working, Excel-ready control sheet that tracks ownership, review dates and regulatory basis for that assessment procedure alongside the other 145 documents in a complete NIS2 set.
7. Who should be responsible for making the significance determination during an incident?
This should be a named, pre-agreed role within the incident response procedure, not an ad hoc decision by whoever is available. Because the judgment is time-critical and has direct legal consequences, it should sit with a trained individual empowered to apply the organisation's documented internal thresholds without needing to escalate the interpretation itself under pressure.
8. Can an incident be reassessed as significant after initially being judged not to meet the threshold?
Yes. If new information emerges showing the incident's actual or potential impact was greater than first assessed, the significance judgment should be revisited, and the reporting clock reassessed from the point the entity became aware of the revised impact, rather than being locked to the original, since Article 23(3) evaluates impact as understood at the time of assessment.