NIS2 OT Incident Reporting: Why the 30-Minute Thresholds Don’t Apply to Your Plant — and What Does

Every quantified threshold the European Commission has published for when a cyber incident becomes reportable — 30 minutes of complete unavailability, 20 minutes for trust services, a 10-second average response time, five per cent of users — shares one property. Not one of them applies to a factory, a substation, a water treatment works, or a pipeline compressor station.

That gap is not something you can wait out. Article 23 of the NIS2 Directive obliges every essential and important entity to file an early warning within 24 hours of becoming aware of a significant incident, and industrial operators have to make that call with no threshold table to point at. This guide sets out what actually governs the decision in an OT or ICS environment, how to measure a process disruption so the number survives an audit, and why an incident that causes no downtime at all can still be reportable.

Which Systems the Reporting Duty Actually Covers

In plain terms: your PLCs, RTUs, DCS controllers and SCADA servers are "network and information systems" in the legal sense, and because they are the systems your regulated service runs on, they sit at the centre of the reporting duty rather than at its edge.

Article 6(1)(b) of the NIS2 Directive defines a network and information system as "any device or group of interconnected or related devices, one or more of which, pursuant to a programme, carry out automatic processing of digital data" [1]. A ladder-logic controller executing a scan cycle meets that definition as squarely as a domain controller does. There is no OT carve-out anywhere in the text.

Which systems the duty attaches to matters more. The Centre for Cybersecurity Belgium, in its NIS2 Notification Guide (v1.2, October 2024), reads it this way: "The mandatory notifications therefore only concern the networks and information systems on which the entity concerned depends to provide the service(s) listed in the annexes of the law" [9]. For an IT-centric organisation that rule mostly excludes things; for an industrial operator it does the opposite. A ransomware event that takes out the corporate ERP at a drinking water utility may fall outside the notification duty entirely, while a far smaller event on the SCADA network supervising the distribution mains almost certainly does not.

Entity example	"The service" for scoping purposes	OT systems in scope
Electricity DSO (Annex I)	Electricity distribution	Substation automation, RTUs, distribution SCADA, teleprotection
Drinking water supplier (Annex I)	Supply of water for human consumption	Treatment PLCs, dosing control, telemetry, reservoir level control
Chemicals producer (Annex II)	Manufacture and distribution of chemicals	DCS, batch control, safety instrumented systems, tank farm control
Component manufacturer (Annex II)	Manufacture of the listed product category	Line PLCs, robot cells, MES where it drives production, quality gating

Whether your organisation is in scope at all is a separate exercise — our NIS2 OT compliance guide covers the Annex I and Annex II size and sector tests.

There Is No OT Significance Threshold — and That Is the Finding

In plain terms: the quantified thresholds everyone quotes were written for eleven categories of digital provider, and no equivalent has ever been adopted for industry. Article 23(3) plus your own documentation is the whole test.

Article 23(11) is explicit about the limits of the Commission’s mandate. It required implementing acts specifying significance for DNS providers, TLD registries, cloud and data centre providers, CDNs, managed service and managed security service providers, online marketplaces, search engines and social networking platforms — and then adds that the Commission "may adopt such implementing acts with regard to other essential and important entities" [1]. May, not shall. It has not done so.

The act that resulted, Commission Implementing Regulation (EU) 2024/2690, names eleven categories of entity in Article 1 and binds no one else [2]. Searching its full published text returns zero occurrences of "manufacturing", "industrial", "operational technology" or "SCADA", and the only duration phrases anywhere in it are "more than 20 minutes" and "more than 30 minutes". The per-category outage thresholds are real and genuinely binding — on cloud, DNS and CDN providers.

This matters because invented industrial thresholds circulate widely — one OT compliance guide states that significance turns on "the number of users affected, the duration of service disruption, geographic scope, and financial impact", and offers a four-hour production stoppage as the bar. None of those four factors appears in Article 23(3), and no four-hour figure exists anywhere in the Directive or the Implementing Regulation.

Instrument	Binds an industrial operator?	What it gives you
NIS2 Article 23(3) two-limb test	Yes, directly	The only binding test: severe operational disruption or financial loss to you, or considerable damage to others
CIR 2024/2690 Articles 5-14	No	Nothing. These are digital-provider criteria under Art. 3(1)(g)
CIR 2024/2690 Article 3(1)(a)-(f)	Not legally, but see below	A structured benchmark some national authorities treat as a presumption
National competent authority guidance	In that member state	The practical test your regulator will actually apply

Germany’s BSI is the clearest example of that last row. Its official reporting guidance states that for entities in other sectors it can be assumed a significant incident exists where at least one of the criteria in Article 3(1) of the Implementing Regulation is met, and adds a national rule of its own: a significant incident is always to be assumed where the provision of critical services has failed or been impaired [5]. That second sentence carries no duration element and no user threshold. It is national guidance for German entities rather than Directive text, and the direction of the logic matters — meeting a CIR criterion is sufficient, but failing to meet one is not a defence, because Article 23(3) still sits underneath.

Process Disruption Is Not IT System Disruption

In plain terms: the same minutes of outage mean different things in a plant than in a data centre, and the most serious OT incidents may not involve an outage at all.

NIST’s Guide to Operational Technology (OT) Security puts the divergence in one pair of lines. For IT: "Fault tolerance is less important; momentary downtime is not a major risk." For OT: "Human safety is paramount, followed by protection of the process. Fault tolerance is essential; even momentary downtime may be unacceptable" [3]. Read against Article 23(3)(a) — "severe operational disruption of the services" — the consequence is direct: severity is a property of the process, not of the clock. A twenty-minute loss of supervisory control over a continuous process that then needs eight hours to restart is a more severe operational disruption than a six-hour outage of a historian no physical process depends on.

The second divergence is subtler. Article 6(6) defines an incident as "an event compromising the availability, authenticity, integrity or confidentiality" of data or of the services provided [1]. Integrity is co-equal with availability. In IT estates availability dominates in practice, because that is where visible harm lands. In OT, an integrity compromise with full uptime is the classic serious case: a modified setpoint, altered controller logic, or a suppressed alarm, with production continuing throughout.

The NSA and CISA joint advisory Control System Defense: Know the Opponent (AA22-265A, cisa.gov) describes exactly this. Adversaries "could open or close breakers, throttle valves, overfill tanks, set turbines to over-speed, or place plants in unsafe operating conditions", and can "manipulate the control environment, obscuring operator awareness and obstructing recovery, by locking interfaces and setting monitors to show normal conditions". They "can even suspend alarm functionality, allowing the system to operate under unsafe conditions without alerting the operator" [4]. An availability-first significance policy classifies all of that as a non-event.

Mapping the recognised ICS impact categories in MITRE ATT&CK for ICS onto the two limbs of Article 23(3) makes triage concrete [7].

ICS impact	What the plant experiences	Art. 23(3) limb	Typical reading
Loss of View (T0829)	Sustained loss of process visibility; equipment needs hands-on intervention	(a), and (b) where supply is affected	Significant in most continuous processes, even with the plant still running
Loss of Control (T0827)	Operators cannot issue commands; runaway condition possible	(a) and (b)	Significant
Manipulation of Control (T0831)	Setpoints or logic altered; output continues, possibly out of spec	(a) via integrity; (b) if product or supply is affected	Significant despite zero downtime
Loss of Safety (T0880) / Loss of Protection (T0837)	Safety instrumented or protective functions compromised	(a) and (b)	Treat as significant; escalate immediately
Denial of View (T0815), short-lived	Brief HMI blackout, process unaffected, full recovery	Possibly neither	Judgement call — document the reasoning either way

Two CIR Article 3(1) criteria deserve specific mention because they are near-dead letters in most IT estates and live risks in OT: 3(1)(c), death of a natural person, and 3(1)(d), considerable damage to a natural person’s health [2]. Where a national authority applies the CIR criteria as a presumption, a safety-relevant OT incident can reach the bar through consequence alone. A third, 3(1)(e), turns on "a successful, suspectedly malicious and unauthorised access to network and information systems" that is "capable of causing severe operational disruption" — no disruption need actually occur. An intruder confirmed on an engineering workstation with project files and controller download rights fits that description on the day they are found.

How to Measure an OT Disruption So the Number Survives an Audit

In plain terms: measure the disruption as time to restored service, not time the attacker was present — and the yardstick is your own recovery objectives, which cuts both ways.

Because there is no external threshold, the "severe" in Article 23(3)(a) is assessed against your own baseline — and that baseline is already a documented artefact. CIR Annex point 4.1.2(f) requires business continuity plans to include "recovery plans for specific operations, including recovery objectives"; 4.1.3 requires a business impact analysis; and 4.2.2(a) requires backup plans to state recovery times [2]. Even where the Annex is only an interpretive benchmark for your sector, the underlying Article 21(2)(c) duty binds everyone.

A defensible measurement runs across four points rather than one:

1. Detection to safe state — first anomaly to the process being held in a controlled condition, including any protective trip.
2. Safe state to restored control — controllers verified, logic checksums confirmed clean, supervisory control returned to operators.
3. Restored control to process restart — the physical restart, which for a continuous process may dominate everything before it.
4. Restart to qualified output — the point at which output again meets specification and can be released.

A worked example: an intrusion on a supervisory network is contained in 25 minutes, operators hold a safe state for 40 minutes while controller integrity is verified, restart takes 6 hours, and the first two batches are scrapped on quality grounds. The intrusion lasted 25 minutes; the operational disruption lasted the better part of a day — and the scrapped batches also feed the financial calculation where Article 3(1)(a) is used as a benchmark.

The reciprocal is the part most guides omit. That same recovery-objective document is what an auditor reads back to you. If your BIA sets a four-hour recovery objective for the DCS and you did not report an eleven-hour outage of it, you have written the regulator’s opening question yourself. Reviewing continuity documentation and incident escalation criteria together, rather than as separate projects, is the practical fix — our NIS2 business continuity policy guide covers the recovery-objective side of that pairing.

The 24-Hour Clock, and Why OT Environments Miss It

In plain terms: the clock starts when someone in your organisation has reasonable grounds to believe a significant incident has occurred — and in OT the first sign is usually a process anomaly noticed by an operator, not an alert raised by security.

Two national authorities have put the awareness trigger in writing, and both set the bar lower than teams expect. The Belgian CCB states that 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" [9]. Germany’s BSI defines the equivalent moment as the point at which any employee of the entity, during working hours, learns of a significant incident [5]. Neither test waits for the security team to confirm anything.

Against that, the detection data is uncomfortable. The SANS 2025 State of ICS Security Report, drawing on more than 330 ICS security professionals across energy, manufacturing, water and transportation, found that "more than one in five organizations (21.5%) reported experiencing a cybersecurity incident over the past year", that "four in 10 of those events caused operational disruption", and that "nearly half (49%) of all incidents were detected within 24 hours" [6]. Read the last figure the other way: for roughly half of ICS incidents, the early-warning window closes before anyone knows there is an incident to warn about.

Article 23(4)(a) then asks for something harder still — the early warning must, where applicable, indicate "whether the significant incident is suspected of being caused by unlawful or malicious acts or could have a cross-border impact" [1]. In an OT environment that is genuinely difficult inside 24 hours, because a pressure transient, a spurious trip or a drifting setpoint reads identically whether the cause is a failing sensor or a manipulated command. The Directive asks only for suspicion, not attribution; the BSI’s guidance is that speed takes priority over completeness, with corrections made later through a follow-up report [5]; and Article 23(1) states that "the mere act of notification shall not subject the notifying entity to increased liability" [1]. Filing on suspicion and correcting later is the designed behaviour, not a failure mode — and under Article 23(5) the CSIRT must respond within 24 hours of the early warning where possible, with initial feedback and, on request, guidance on mitigation [1]. For a plant team without in-house ICS forensics, that channel opens the moment you file.

Preserving Evidence When Containment Is a Safety Decision

In plain terms: you cannot image a running PLC or pull the network from a live process, so decide in advance which evidence you will sacrifice to safety, and record why.

CIR Annex point 3.5.2 sets the response stages as containment, eradication and recovery, and 3.5.4 requires entities to log incident response activities and record evidence [2]. Neither contemplates the OT conflict: the first containment action is a physical-safety decision, and several standard IT collection steps are unavailable or unsafe. NIST notes that OT outages "must be planned and scheduled days or weeks in advance" and that OT system lifespans can exceed 20 years — which is why so many controllers cannot support an agent or a memory capture at all [3].

What can realistically be preserved, and should be identified before an incident rather than during one:

• Passive network capture from taps or span ports on the control and supervisory layers — the only forensic record of controller traffic that exists if it was not already running.
• Historian, alarm and event logs, exported with timestamps aligned to a common clock, including alarm suppression and acknowledgement records.
• Engineering workstation artefacts — project files, download and change history, and controller logic checksums that prove whether logic was altered.
• Operator logbooks and shift handover notes, which often carry the first observation and therefore fix the awareness time.
• Process data — flows, pressures, temperatures and quality results across the event window, frequently the only evidence distinguishing manipulation from equipment failure.

Where evidence has to be destroyed to keep the process safe, write down the decision and the reason at the time. The Implementing Regulation models this discipline elsewhere: Article 2(2) requires an entity that judges a qualified requirement inapplicable to "in a comprehensible manner document its reasoning to that effect" [2]. Applying the same habit to containment trade-offs converts an unavoidable evidentiary gap into a documented engineering judgement. Pre-authorising those trade-offs in the incident plan, with named sign-off from operations and safety, is faster than negotiating them at three in the morning — the structure in our NIS2 crisis management plan guide applies directly.

The One-Month Final Report Meets a Multi-Month Recovery

In plain terms: OT recovery routinely outruns the final-report deadline, and Article 23(4)(e) is the provision that resolves it.

Article 23(4)(d) requires a final report "not later than one month after the submission of the incident notification under point (b)" — one month from the 72-hour notification, not from the incident [1]. The counter-intuitive consequence is that filing your 72-hour notification early shortens your own final-report window.

Set that against recovery reality: the SANS survey found that "nearly one in five incidents required more than a month to remediate" [6]. For a meaningful share of OT incidents, the final report falls due while the incident is still being handled. Article 23(4)(e) covers exactly this — where the incident is ongoing when the final report would be due, the entity provides a progress report then, and a final report within one month of completing its handling of the incident [1]. Note that the Directive sets no content list for a progress report, so any guidance on what one should contain, including this paragraph, is practical rather than legal.

Roles, Accountability, and Reporting-Failure Exposure

In plain terms: the person who first sees an OT incident is rarely the person who owns the notification, and that handover is where 24-hour deadlines are lost.

Role	What this changes for them
Plant / operations manager	You are usually the awareness trigger. A process anomaly you cannot explain by equipment or procedure needs a documented, time-stamped escalation path — not a verbal mention at handover.
OT security lead / CISO	Set significance criteria in advance, per CIR Annex 3.4.2(a)’s "predefined criteria laid down in advance" approach, and include integrity-only and access-only cases, not just outage duration.
Compliance officer / legal	Confirm your national authority’s position on whether CIR Article 3(1) is treated as a presumption in your sector. It varies by member state, and it changes the test you apply.
Board / C-suite	Approve the escalation authority and the pre-authorised evidence-versus-safety trade-offs. Under Article 20(1), management bodies approve and oversee the Article 21 measures and can be held liable for infringements.

On exposure, one detail is worth reading precisely. Article 34(4) obliges member states to provide for administrative fines of "a maximum of at least EUR 10 000 000 or of a maximum of at least 2 % of the total worldwide annual turnover", whichever is higher, for essential entities, with EUR 7,000,000 or 1.4% for important entities under Article 34(5) — and both apply to infringements of Article 21 or Article 23 [1]. Two things follow. A reporting failure is exposed on the same scale as a risk-management failure. And because the Directive sets a floor for the national ceiling rather than the ceiling itself, a member state may go higher — so confirm the figures, and the reporting portal, with your national competent authority.

OT Incident-Reporting Readiness Checklist

• Write significance criteria covering integrity-only and access-only cases, not just outage minutes, and lay them down in advance.
• Map your ICS impact categories — loss of view, loss of control, manipulation of control, loss of safety — to the two Article 23(3) limbs, and record the reasoning.
• Confirm with your national competent authority whether CIR Article 3(1) is a benchmark or a presumption for your sector.
• Define the disruption measurement as time to qualified output, and reconcile it against the recovery objectives already in your BIA.
• Give operations staff a named, time-stamped escalation route to whoever owns the Article 23 filing.
• Ensure passive OT network monitoring is running now — after the incident is too late to create the forensic record.
• Pre-authorise which evidence may be sacrificed for safety, with operations and safety sign-off.
• Rehearse an escalation in which the plant is still running and only the data is wrong.

Detection and reporting cannot be separated from the underlying control set. For the Article 21 side in an industrial environment, see our OT and SCADA security guide, the ICS security compliance guide, and the IEC 62443 control mapping. The general NIS2 incident reporting guide covers the mechanics common to every sector.

Frequently Asked Questions

Our plant kept running throughout the incident. Is it still reportable?
It can be. Article 6(6) defines an incident by compromise of availability, authenticity, integrity or confidentiality, so a manipulated setpoint, altered controller logic or a suppressed alarm is an incident even with full uptime [1]. Whether it is significant depends on Article 23(3): if the manipulation caused or was capable of causing severe operational disruption, or considerable damage to others, the answer is yes.

Is there a minimum downtime before an OT incident becomes significant?
No. The 20 and 30-minute figures in CIR 2024/2690 apply only to the eleven categories of digital provider named in its Article 1 [2]. For an industrial operator there is no duration bar in EU law, and no four-hour rule despite what several vendor guides claim.

Does an intrusion with no process impact have to be reported?
Under Article 23(3) it depends on whether it was capable of causing severe operational disruption. Where a national authority applies CIR Article 3(1) as a presumption, criterion (e) is more direct: successful, suspectedly malicious and unauthorised access capable of causing severe operational disruption is sufficient on its own [2]. Confirmed access to an engineering workstation with controller download rights is a strong candidate.

What if we cannot tell within 24 hours whether it was an attack or an equipment failure?
Article 23(4)(a) asks whether the incident is suspected of being caused by unlawful or malicious acts, not whether it has been confirmed [1]. File on the suspicion, mark it as unconfirmed, and correct it in the 72-hour notification. For the general threshold question, see our guide to the Article 23(3) significance test; energy operators should also read the sector overlay in our energy incident response guide.

Across the EU threat picture, ENISA analysed 4,875 incidents between 1 July 2024 and 30 June 2025 and found that 53.7% concerned entities that are essential under NIS2 [8]. The reporting duty is not a theoretical one.

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.

Sources

1. Directive (EU) 2022/2555 (NIS2), Articles 6, 20, 21, 23 and 34 — EUR-Lex, CELEX 32022L2555.
2. Commission Implementing Regulation (EU) 2024/2690, Articles 1-4 and Annex — EUR-Lex, CELEX 32024R2690.
3. NIST SP 800-82r3, "Guide to Operational Technology (OT) Security", September 2023 — National Institute of Standards and Technology.
4. "Control System Defense: Know the Opponent" (AA22-265A) — joint advisory, National Security Agency and Cybersecurity and Infrastructure Security Agency.
5. "#nis2know: NIS-2-Meldepflicht" — Bundesamt fur Sicherheit in der Informationstechnik (BSI), Germany. National guidance for German entities.
6. "The SANS 2025 State of ICS Security Report: Progress, Pressure, and the Path to Resilience" — SANS Institute.
7. "Impact" (ICS tactic TA0105) — MITRE ATT&CK for ICS.
8. "ETL 2025: EU consistently targeted by diverse yet convergent threat groups" — ENISA.
9. "NIS2 Notification Guide", version 1.2, October 2024 — Centre for Cybersecurity Belgium (ccb.belgium.be). National guidance for Belgian entities; a later version 1.3 was published in August 2025.