Skip to content
AuditFront
Art.23.3 NIS2

NIS2 Art.23.3: Incident Significance Assessment Criteria

What This Control Requires

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; or (b) it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.

In Plain Language

Not every security incident triggers NIS2 reporting. The directive sets out a two-pronged test: an incident is significant if it causes (or could cause) severe operational disruption or financial loss to your organisation, or if it causes (or could cause) considerable damage to other people or organisations.

The phrase "capable of causing" is the critical bit. You cannot wait around to see whether the damage actually materialises. If an incident has the potential for significant impact, it needs to be reported even if you managed to contain it early.

In practice, you need to translate these broad legal definitions into specific, pre-defined thresholds that make sense for your operations. What counts as "severe" disruption for your services? What financial loss figure matters? These decisions should be made calmly in advance, not debated in the middle of a live incident.

How to Implement

Write a documented significance assessment procedure that maps Art.23.3 criteria to your specific organisation. The procedure needs to be fast - ideally producing a determination within one to two hours of detection, leaving enough runway for the 24-hour early warning deadline.

Define concrete thresholds, both quantitative and qualitative. Think about service disruption affecting a certain percentage of users or lasting beyond a set duration, financial loss above a given amount, personal data compromise beyond a certain number of individuals, downstream impact on other entities, involvement of advanced persistent threats or state-sponsored actors, and anything touching critical infrastructure.

Build a simple decision matrix or flowchart that incident responders can follow under pressure. It needs to produce consistent results no matter who is on shift.

Add a review step where a senior incident responder or designated authority validates the initial assessment. This is a quality check, not a bottleneck - keep it fast.

Document every significance assessment, including the ones where you decide an incident is not significant. If a regulator asks why something was not reported, you want a clear paper trail showing the reasoning.

Review your thresholds regularly. Update them when your services change, when regulators issue new guidance or implementing acts, after post-incident reviews reveal your thresholds were miscalibrated, or when industry benchmarks shift.

Train every member of the incident response team on the assessment process. Run significance assessment scenarios during your tabletop exercises so the process feels natural when it matters.

Evidence Your Auditor Will Request

  • Documented significance assessment criteria with organisation-specific thresholds
  • Assessment decision matrix or flowchart for rapid evaluation
  • Records of significance assessments for all incidents (significant and non-significant)
  • Review and approval records for significance determinations
  • Training records showing IR team familiarity with significance criteria

Common Mistakes

  • No pre-defined significance thresholds; assessment is subjective and inconsistent
  • Assessment criteria do not cover 'capable of causing' scenarios, only actual impact
  • Significance assessment takes too long, leaving insufficient time for the 24-hour early warning
  • Team members untrained on significance criteria; rely on management judgment during incidents
  • Non-significant determinations not documented, creating audit gaps

Related Controls Across Frameworks

Framework Control ID Relationship
ISO 27001 A.5.25 Related
GDPR Art.33 Related

Frequently Asked Questions

Should we report if we're unsure whether an incident is significant?
When in doubt, report. Underreporting carries real regulatory risk, while overreporting has minimal downside. You can always send a follow-up update clarifying the incident's actual significance once you have more information.
Are there sector-specific significance thresholds?
The European Commission may issue implementing acts with more specific thresholds per sector, and national authorities may provide their own guidance. Check with your national competent authority and ENISA for the latest applicable to your sector.

Track NIS2 compliance in one place

AuditFront helps you manage every NIS2 control, collect evidence, and stay audit-ready.

Start Free Assessment