Article 23(3) significant incident criteria

Significant incident criteria decide whether the 24-hour clock starts

When an incident has just been detected, the first decision your team faces is whether NIS2 reporting applies at all. Article 23(3) sets the test for a significant incident, and every later reporting step, from the early warning to the final report, depends on that answer. If the incident is significant, the 24-hour clock for the early warning starts from the moment your entity becomes aware of it. If it is not, no national reporting duty is triggered, although you may still need to record the decision and keep the evidence. The risk this test addresses runs in two directions. Under-reporting means a significant incident is handled quietly and the authority learns of it late or never. Over-reporting floods the national CSIRT or competent authority with incidents that do not matter, which wastes supervisor attention and can bury the reports that count. The test is hard to apply because it is written in forward-looking terms: an incident is significant if it has caused *or can cause* severe operational disruption, financial loss or considerable damage to others. Entities covered by Implementing Regulation (EU) 2024/2690 also face quantified thresholds that must be checked against their own financial figures and incident data. The organization owns this decision, and it should be made by people with the authority to commit the entity, not left to the first analyst on shift. An assessor or supervisor will not re-make the call. They will test whether the decision was reasoned, made on time, based on the facts available at that point, and recorded with its basis so it can be revisited as facts change. Confirm with your national competent authority how it expects that record to look and whether it wants notification of decisions not to report.

Which entities and incidents the significant incident criteria apply to

Before any incident can be judged significant, the entity has to know which legal regime applies to it and which systems feed the assessment. The Directive's two-part test applies to essential and important entities generally, while Implementing Regulation 2024/2690 sets quantified criteria for named digital entity types. The cards below cover the scoping decisions that change how much assessment work follows.

Directive entities or digital entities

Determine first whether the organization falls under the general Article 23(3) test as an essential or important entity, or under Implementing Regulation 2024/2690 as one of the named digital entity types such as DNS, TLD, cloud, data center, CDN, managed service, managed security service, online platform or trust service provider. The regulation's quantified criteria apply only to the second group, so a single organization with several business lines may need two sets of thresholds. Confirm the classification with the national competent authority or legal counsel, and record the reasoning.

Services in scope of the assessment

Map which services, customer-facing platforms and internal systems are part of the entity's covered activity. An incident is assessed against the service it affects, so an outage in a non-covered internal tool may not carry the same weight as one in a service delivered to customers. Document the service inventory and the dependencies between services, because a disruption in a shared component can affect several covered services at once and must be assessed for each.

Systems that produce detection evidence

Identify the systems that must be monitored to decide whether an incident is significant: identity providers, cloud control planes, network devices, endpoints and application logs. Without them, the entity may not detect a suspected malicious unauthorized access or know whether a financial loss threshold has been reached. Confirm log coverage for each covered service and the retention period needed to reconstruct events, since the recurring incident rule depends on comparing events over time.

Hosted and third-party logs

When a cloud provider, managed SOC, SaaS platform or hosting partner operates a component, the entity may not hold the raw logs that show whether an incident occurred or how long it lasted. Review contracts to confirm which party retains logs, how quickly they can be exported and whether the entity can obtain evidence during the reporting window. Where the supplier cannot provide logs in time, the entity still owns the reporting obligation and needs an agreed route to the data.

Recurring incidents across the window

Individually minor incidents can become significant when they recur within a short period and share an apparent root cause. Decide which incident categories and root cause labels the entity will track, and who reviews them on a fixed schedule. For covered digital entities, the recurring incident assessment runs quarterly, so the process must keep incident records consistent across teams and sites that may handle the same fault differently.

Exclusions for planned work

Scheduled service interruptions and the planned consequences of scheduled maintenance are excluded from significance under the implementing regulation. Keep change records, maintenance windows and approval evidence, because an assessor or authority will ask whether an outage was truly planned. An unplanned extension of a maintenance window is not covered by the exclusion and should be assessed like any other incident.

How the two-part test in Article 23(3) works

An incident is reportable under NIS2 when it meets a two-part test in Article 23(3) of the Directive: it has caused, or can cause, severe operational disruption of the entity's services or financial loss for the entity, or it has affected, or can affect, other natural or legal persons by causing considerable material or non-material damage. Either limb is enough. The first limb looks inward at the entity's own services and finances, and the second looks outward at customers, users and other parties. Because the test covers what an incident can cause, not only what it has already caused, an entity cannot wait for full impact data before deciding. It has to judge severity on the information it holds at the time and revisit that judgment as facts change, for example when an outage turns out to affect more customers than first thought or when data is confirmed as taken.

Article 23(3) is the general test that applies to every in-scope entity. Entities covered by Commission Implementing Regulation (EU) 2024/2690 apply its quantified criteria on top of it, so for those entities the general test is a floor, not the full answer. The quantified criteria set specific thresholds, including a financial loss limit, and they are discussed in the sections that follow. Entities outside that regulation's scope still need to apply the general test, and they should confirm with their national competent authority how it is applied in practice. The authority in each Member State can also add requirements through its transposition law, so the wording of the national law and any guidance issued under it should be checked alongside the EU texts.

The practical decision for an operations or security lead is to record, at the moment of triage, which limb is engaged and why. The record should state the basis for the judgment, the facts known at the time, the assumptions made and the date of the next review. Entities covered by the implementing regulation should also confirm that their incident tooling can hold this record and its later revisions, so the reasoning can be shown to a supervisor. Confirm the approach with your national authority or your legal advisers before relying on it, because interpretation of the national law may differ across Member States.

The quantified triggers and exclusions for digital entities

For digital entities covered by Implementing Regulation 2024/2690, the quantified criteria decide whether an incident is reportable. The cards below cover each financial, harm and access trigger, the recurring incident rule and the exclusions, with the records a decision file should hold for each.

Financial loss trigger

An incident is significant if it causes or can cause direct financial loss above EUR 500 000 or 5% of annual turnover, whichever is lower. The lower figure applies, so for smaller entities the percentage often sets the threshold. Record the loss estimate, the turnover figure and the year it relates to, and note how the estimate was reached. Estimates that can rise must be re-tested as the investigation progresses.

Exfiltration of trade secrets

Exfiltration of trade secrets is significant on its own, without a financial loss figure. The decision file should state what data left the environment, how the entity classified it as a trade secret, and the evidence of transfer such as flow logs, object access records or exfiltration indicators. Classification should be made by a named owner, not inferred after the fact.

Death or considerable health damage

An incident that causes death or considerable damage to health is significant regardless of its financial or operational effect. This trigger matters most for providers whose services support healthcare or emergency workflows. Keep the link between the incident and the harm documented, including the source of the information, the date it was received and any statement from the affected party or authority.

Suspected malicious access capable of severe disruption

A successful, suspected malicious unauthorized access is significant when it is capable of causing severe disruption. The test is about capability, so the entity does not need proof of damage. Record the access path, the affected accounts or systems, the time the access was first seen and the reasoning for why severe disruption was possible. Suspicion can be reported before confirmation, so the file should show when the suspicion arose.

Recurring incident rule

Incidents that are individually not significant count as one significant incident when they occur at least twice within 6 months, share the same apparent root cause and together meet the financial loss threshold. Assess recurrence every quarter. The decision file needs a register of minor incidents with dates, root cause tags and loss figures, plus a dated quarterly review that shows the check was made. The quarterly review is the evidence a supervisor will ask to see.

Scheduled interruptions and maintenance

Scheduled service interruptions and the planned consequences of scheduled maintenance are not significant incidents. The exclusion covers what was planned, so the decision file must show the change record, the approved window and the planned impact. An interruption that runs past the planned window, or causes effects outside what was announced, falls back into the normal test. Confirm that change tickets match the actual timeline.

How an assessor tests the significant incident decision

This table compares what an assessor tests, the evidence it requests and the findings it commonly raises for each part of the significant incident decision under Article 23(3) and Implementing Regulation 2024/2690. The assessor is usually the national competent authority or an auditor it accepts, and NIS2 issues no certificate, so the outcome is a finding or a clean review rather than a certificate. Use the rows to check whether your classification record would survive a sampled review.

Test area	Test approach and evidence requested	Common findings
Documented criteria and decision procedure	Assessor reads the written procedure and checks it covers both the Article 23(3) test and the Article 3(1) quantified criteria, with named decision owners	Criteria exist but no owner or sign-off step; procedure ignores the exclusions
Sampling of recent incidents, including those judged not significant	Assessor selects incidents across the review period, including closed ones classed as not significant, and asks for the reasoning on each	Reasoning is missing or written after the fact; non-significant records lack the facts used
Financial loss calculation and turnover basis	Assessor asks for the loss workings, the annual turnover figure used for the 5% limb and the date of the figure	Loss estimate not traceable to records; turnover basis unclear or outdated
Recurring incident review and quarterly record	Assessor checks for a quarterly assessment of recurring incidents and the root-cause comparison over a rolling six-month window	No quarterly record; repeat incidents with the same root cause not linked
Suspected malicious unauthorized access	Assessor tests whether suspected malicious access was screened against the severe disruption criterion, with timestamps	Suspicion dismissed without documented assessment; no escalation trail
Scheduled maintenance exclusions	Assessor compares maintenance logs and change records against outages claimed as excluded	Unplanned consequences treated as scheduled; change tickets missing or approved late
Timing from awareness to classification	Assessor reconstructs the time between first awareness, classification and the 24-hour early warning clock	Classification delayed without record; awareness time not captured in the case system

How to build a significant incident decision process that holds up

This sequence turns the Article 23(3) test and the Implementing Regulation 2024/2690 criteria into a written, tested procedure that classifies each incident on time, records the facts behind the decision, and catches recurring incidents that look minor one at a time.

Confirm which regime applies to each entity
Start by establishing, for each legal entity in scope, whether it is covered by Implementing Regulation 2024/2690 or only by the general Article 23(3) test as transposed in its Member State. Entities in the digital categories named in the regulation use the quantified criteria, while others rely on the two-part Directive test. Legal counsel or the compliance lead should record the answer per entity, with the national transposition law that applies. The output is a signed scope memo that names the regime for each entity and is reviewed whenever the entity structure or service portfolio changes.
Write the criteria into the incident response procedure
Copy the applicable criteria into the incident response procedure in operational language, so responders can apply them without reading the regulation. Cover the severe disruption and financial loss limbs, the exfiltration of trade secrets, death or considerable damage to health, suspected malicious unauthorized access, the scheduled maintenance exclusion, and the recurring incident rule. Each criterion should name the evidence an analyst needs to decide it. The output is a versioned procedure section approved by the management body or its delegate.
Assign classification ownership and decision deadlines
Name the role that makes the significance decision, a deputy who acts when that role is unavailable, and the escalation path to the management body. Define the internal time the decision must be made after an incident is detected, and record who is informed of each decision. Because the early warning clock in Article 23 runs from awareness of a significant incident, the procedure should state when awareness is considered to exist. The output is a classification record template with fields for the decision, the criteria considered, the approver, the timestamps and the reasons for any negative decision.
Set up the financial loss calculation method
Document how direct financial loss is estimated, which costs count, who provides the figures and when the estimate is refreshed. The financial criterion uses two bounds, the EUR 500 000 figure and 5% of annual turnover, and the lower of the two applies. Finance and the entity's turnover basis, such as the most recent audited annual figure, should be agreed in advance so that the threshold is not recalculated under pressure. The output is a calculation worksheet and a written turnover basis, reviewed with finance each year. Confirm with your supervisor how they expect the loss to be measured.
Configure detection and case tooling to capture decision facts
Configure detection and case management so that the facts needed for each criterion are recorded at triage rather than reconstructed later. A case management platform such as DFIR-IRIS can hold assets, indicators, tasks and evidence in one record with an audit trail, while SIEM or detection rules such as OpenSearch Security Analytics with Sigma rules, or Wazuh alerts mapped to MITRE ATT&CK, supply the alert source. Add mandatory fields for affected services, data categories, suspected access and loss estimates. The output is a tested case template and a triage checklist that prove which facts were known at each point in time.
Run the quarterly recurring incident review
Each quarter, review closed and minor incidents to test whether several individually non-significant events share the same apparent root cause, occurred at least twice within six months, and together meet the financial loss threshold. The Implementing Regulation requires this assessment on a quarterly basis. Group incidents by root cause, not by ticket category, and document the reasoning for those that are dismissed. The output is a quarterly recurrence memo signed by the decision owner, with any reclassified incidents referred back into the reporting process.
Test the procedure with tabletop exercises
Run tabletop exercises that present realistic but invented scenarios to the people who make the decision, including edge cases such as planned maintenance that goes wrong, a suspected intrusion with no confirmed data loss, and recurring low-value incidents. Record how long the decision took, which facts were missing, and whether the approver used the procedure as written. Feed the findings into procedure revisions and tooling changes. The output is an exercise report with dated action items and a revised procedure version. Scenarios should be labeled as illustrative when shared outside the team.

Evidence that proves each significance decision

A regulator reviewing a reporting decision will ask whether the entity applied its criteria consistently and can show how it reached each conclusion. The cards below cover the documents, records and case files that make a significance decision defensible, whether the incident was reported or judged not significant. Each one should be checked against the criteria your entity applies under Article 23(3) and, where it applies, Implementing Regulation 2024/2690.

Approved criteria procedure

A written procedure that states how your entity tests an incident against the Article 23(3) two-part test and, where applicable, the quantified criteria in Implementing Regulation 2024/2690. It should name the management or security role that approves it, the date it took effect, and a version history showing each change and its reason. Check that the procedure matches the thresholds that apply to your entity type, and that staff who triage alerts can find and follow the current version. An assessor will ask which version governed a decision made months earlier, so the history matters as much as the text.

Per-incident classification record

For every incident assessed, a record that captures the facts known at the time, the criterion tested, the decision reached, the approver and the timestamps of each step. The timestamps matter because the 24-hour early warning clock depends on when the entity became aware of a significant incident. Confirm that your ticketing or case tool can hold these fields as structured data and keep them unchanged after approval. Where the decision is revised as facts emerge, the record should show the original decision and the revision rather than overwriting it.

Financial loss and turnover workings

Where the financial loss criterion applies, the calculation behind each figure: the direct loss estimate, the source data, the annual turnover used for the 5% comparison, and the rule applied to pick the lower amount. Under Implementing Regulation 2024/2690 the threshold is EUR 500 000 or 5% of annual turnover, whichever is lower, so a missing turnover figure can change the outcome. Ask finance to confirm which turnover year is used and how estimates are updated as losses become clearer. Keep the workbook and its inputs with the incident record.

Quarterly recurring incident review

A dated review, held each quarter, that looks for incidents which are individually not significant but could become one significant incident. The test asks whether incidents occurred at least twice within 6 months, share the same apparent root cause and together meet the financial loss threshold. Record the search parameters, the incidents reviewed, the root causes compared and the conclusion, even when nothing is found. Detection data helps here: Wazuh writes matching alerts to alerts.log and alerts.json, and OpenSearch Security Analytics records rule matches as findings with severity, so you can query repeated events across months. Confirm each tool retains enough history for a six-month look-back.

Register of incidents judged not significant

A register listing each incident that was assessed and found not significant, with the rationale and the approver. This record shows the reporting decision was made deliberately, and it lets a reviewer test whether exclusions were applied correctly. Scheduled maintenance interruptions are excluded from significance under Implementing Regulation 2024/2690, so tag those entries with the exclusion relied on. Near misses reported voluntarily under Article 30 can be kept here as well. Ask whether your register can be exported for a supervisor in a readable format.

Case records holding timeline and evidence

A single case record per incident that links the assets affected, indicators of compromise, tasks, the consolidated timeline and the evidence items. DFIR-IRIS (LGPL-3.0-or-later) keeps each case as one record with a full audit trail, logs evidence with SHA-256 verification and chain of custody, and generates reports from case data. Use these records to reconstruct what was known at each reporting step. Confirm that the tool captures the specific facts your criteria rely on, such as loss figures and exfiltration indicators, or that you can hold them in linked fields.

What meeting the significant incident criteria costs

This table compares the cost components of putting the Article 23(3) significant incident criteria into practice, who is paid for each, whether it is one-time or recurring, and what drives it up. Read it as a checklist for scoping a quote: the largest variable costs come from how many entity types, systems and log sources are in scope and how mature existing logging already is.

Cost component	One-time or recurring	What drives it	How to keep it down
Criteria design and legal review	One-time, with periodic updates	Number of entity types covered, turnover basis complexity, and whether Implementing Regulation 2024/2690 applies alongside national rules	Scope the entity types first, document the thresholds once in a shared template, and limit counsel review to the points where interpretation is genuinely open
Engineering time to instrument detection and case tooling	One-time, with ongoing tuning	Number of systems in scope, number of log sources, and how much of the detection and case workflow must be built versus configured	Start from the systems that carry the most financial and service impact, reuse existing SIEM or logging pipelines, and ask the partner to name the tools and configuration deliverables
Tooling and licenses	Recurring for commercial products, often zero license fee for self-hosted open source	Choice of commercial versus open-source components, hosting footprint, and storage retention needed for evidence	Self-hosted open source such as DFIR-IRIS, OpenSearch Security Analytics and Wazuh (each under its own license) removes license spend, but operating effort, hosting and upgrades remain; confirm each component's license terms
Quarterly recurrence review effort	Recurring, every quarter	Volume of incidents, number of near-miss or low-impact events to review, and how well cases are tagged by root cause	Tag each case with an apparent root cause from the start, so the quarterly review under Annex point 3.4.2(b) becomes a query rather than a manual reconstruction
Exercises to test the procedure	Recurring, at a cadence set by the entity	Number of teams involved, number of scenarios, and whether exercises include reporting to authorities	Use one scenario that tests the threshold decision end to end, and reuse the same exercise plan year on year with updated systems
External review of the procedure	Periodic, per review cycle	Complexity of the thresholds, sector-specific rules, and whether a second opinion is needed before a supervisor asks	Limit the external review to the criteria and decision record rather than the whole incident program, and agree the review cycle in writing
Assessor or supervisor queries	Variable, arises when a supervisor or auditor asks	Quality of decision records, completeness of the case timeline, and whether the reasoning for not reporting is documented	Keep a written decision record for every incident assessed as not significant, with the thresholds applied and the evidence used

Who owns the decision, who prepares the evidence and who tests it

Your organization owns the classification decision. The management body approves the criteria and the procedure that applies them, and remains accountable under the governance duties of NIS2 for how the process runs. A named person classifies each incident against the Article 23(3) test and the thresholds in Implementing Regulation 2024/2690, and records the reasoning at the time of the decision. Legal and finance supply the inputs that are hardest to estimate, such as the direct financial loss figure and the turnover base for the 5% limb.

Management body approval: the board or equivalent body signs off the classification procedure and the delegation to the classifier.
Classifier role: a named, trained person or on-call rota makes the first decision and records it in the case.
Loss calculation inputs: finance confirms the direct financial loss method and the annual turnover figure used for the lower of the two thresholds.
Legal review: legal checks exclusions, such as planned maintenance, and how the decision interacts with GDPR breach duties.
Final decision and signature: a senior owner signs the outcome, so the record shows who decided, when and on what basis.

Confirm with your counsel and finance team which person holds each step and how the decision is evidenced if the classifier is unavailable.

Questions buyers ask about significant incident criteria

Can our team classify incidents as significant without outside help?

Yes, in most organizations the internal team can do the classification, provided it has the authority, the criteria written down and a named decision owner. The work is mostly structured judgment: checking the Article 23(3) test, the thresholds in Implementing Regulation 2024/2690 that apply to your entity type, and the recurring incident rule. What usually needs outside help is not the decision itself but the evidence trail and a review of edge cases, such as a root cause that is still unclear or a financial loss estimate that is contested. Ask any partner to show how their classification workflow records the reasoning, not only the outcome.

How long should classification take inside the 24-hour window?

The 24-hour limit for the early warning comes from Article 23(4)(a) of NIS2, and it runs from the moment you become aware of a significant incident. The classification step sits inside that window, so your internal target should be shorter than 24 hours and written into the response plan. Set the target yourself based on how many people must be reached, how quickly your systems can be assessed and how often your on-call roster is staffed. Test the target in exercises before a real incident forces the question.

What does classification need from management and finance?

Management needs to approve the criteria, name who may declare an incident significant, and accept that early warnings may be filed on incomplete information. Finance must provide a method for estimating direct financial loss, including who can confirm figures quickly outside business hours. Both functions are needed in advance: approved thresholds, a delegation of authority and a contact path for turnover data. Without these, the security team ends up deciding financial questions alone, which is hard to defend to a supervisor later.

How is the financial loss threshold calculated, and who signs it off?

Under Article 3(1) of Implementing Regulation 2024/2690, the financial threshold is EUR 500 000 or 5% of annual turnover, whichever is lower, measured as direct financial loss that the incident causes or can cause. Finance should define which costs count as direct loss, how potential loss is estimated while the incident is ongoing, and how the figure is updated as facts change. Sign-off should sit with a named finance officer and be recorded in the case file together with the assumptions used. Ask your advisers to confirm how they treat recovery costs and insurance recoveries in their method.

Do we have to report near misses?

No, near misses are not mandatory reports under the significant incident criteria. NIS2 defines a near miss in Article 6(5) as an event that could have compromised data or services but was prevented or did not materialize. Under Article 30, entities may report near misses voluntarily. Still, recording them matters, because a series of near misses can reveal the same root cause that makes incidents recurring under Article 4 of the implementing regulation. Keep a log with enough detail to support the quarterly recurring incident assessment.

What happens if an incident judged not significant later turns out to be significant?

The classification must be revisited as facts change, and the reporting clock may start from the point you became aware that the incident meets the criteria. Document the original assessment, the new facts and the date of re-assessment in the case record. Incidents that were individually not significant can also become one significant incident under the recurring rule if they occur at least twice within 6 months, share the same apparent root cause and together meet the financial threshold. Check this with your national authority or legal counsel, since timing rules depend on how your Member State applies the Directive.

What can an outside partner do for classification, and what can it not do?

An implementation partner can help define the criteria, build the classification workflow in your incident tooling, prepare case records and run exercises that test the decision path. It cannot make the significance decision for your organization, because the management body and your named decision owner must own it. Nor can a partner issue a determination that an incident is or is not reportable, and it cannot replace the competent authority's view. Get the scope, deliverables and timelines agreed in writing before work starts, since most engagements are fixed-scope.

How DeployOpen scopes and evidences significant incident criteria

DeployOpen works on the Article 23(3) significant incident criteria by first agreeing in writing which entities, services and incident sources the criteria must cover. We then build the detection, case handling and evidence records that let your team show how each incident was judged against the test.

How we scope

Engagements are fixed-scope, with the covered entity types, services and log sources agreed in writing before work starts.
We confirm which entities fall under Implementing Regulation 2024/2690 and which follow the general Article 23(3) test.
The written scope names the deliverables, including the significance decision record and the review cadence for recurring incidents.

How we build

We configure the detection layer on self-hosted tools, such as Wazuh rules and OpenSearch Security Analytics detectors, to surface candidate incidents.
We set up case records in DFIR-IRIS so each candidate carries its assets, indicators, tasks and timeline for the significance assessment.
We document the quantified thresholds, exclusions and recurrence logic in a form your compliance and incident teams can apply consistently.

How we hand over

You receive the configured rules, case templates, decision procedures and an evidence register mapped to each criterion.
We walk your staff through how to record a significance decision, including why an incident was or was not reportable.
Your organization keeps ownership of each reporting decision, and an independent auditor or assessor decides whether the evidence meets the requirement.

How we support

Ongoing support, upgrades and continuous testing are available as retainers for detection rules and criteria documentation.
We can review the quarterly recurring-incident assessment with your team and update rules as your services or threats change.
Confirm with us in the written scope which support tasks are included and how changes to the criteria are approved and logged.