NIS2 Incident Response for Water Utilities: When Modbus/DNP3 Attacks Cross the Art. 23 Notification Line

On 5 February 2021, an attacker used TeamViewer — remote desktop software installed for engineering access — to reach a water treatment plant in Oldsmar, Florida. Within minutes they had raised sodium hydroxide concentration from 100 parts per million to 11,100 ppm: 111 times the normal dosing level. A plant operator saw the cursor moving without authorisation, watched the HMI controls open, and reversed the change before it propagated to the distribution network. No contamination reached consumers.

That incident falls outside NIS2’s jurisdiction — it happened under EPA regulations in Florida. But it has become the reference case for a question every European water utility CISO now faces: if this had happened to our plant, would we have had to notify our CSIRT within 24 hours?

The answer is yes — and understanding why is the foundation of NIS2 incident response for water sector entities. Article 23 of Directive 2022/2555 does not require harm to materialise. It requires the capability for considerable damage to persons. A chemical dosing manipulation to 111 times the safe level meets that test the moment the attacker executes the command. This article maps that analysis in full, then works through the OT-specific incident response obligations that make water sector IR different from every other NIS2 sector.

Is Your Water Utility in Scope Under NIS2?

Drinking water suppliers and wastewater operators are classified as essential sectors under Annex I of Directive 2022/2555 — sector 6 (drinking water) and sector 7 (wastewater). This places them alongside energy, banking, and digital infrastructure under the directive’s most demanding compliance regime. For a full breakdown of obligations at the sector level, see our NIS2 guide for water utilities.

The scope test has two gates.

Gate 1: Sector classification. Suppliers and distributors of water intended for human consumption fall under sector 6. Urban wastewater collection, treatment, and discharge falls under sector 7. Both are Annex I sectors — the highest criticality tier, carrying the strictest Art. 21 security obligations and the full Art. 23 notification regime.

Gate 2: Size and significance.

Entity Type	Employee Threshold	Annual Turnover	Key Obligations
Essential	250+	>€50M	Art. 21 security measures + Art. 23 notification + proactive supervisory audits
Important	50–249	€10M–€50M	Art. 21 security measures + Art. 23 notification + reactive supervisory oversight
Sole-provider (any size)	Any	Any	Member state may designate as Essential regardless of size threshold

The sole-provider exception is material for water infrastructure. A small municipal utility serving an isolated rural area may employ 30 people and turn over €5M annually — but if it is the only drinking water provider for its catchment, the national competent authority can designate it as an essential entity. NIS2’s size thresholds are a floor, not a ceiling. Consulting your national transposition law is the only definitive test: several member states have extended scope to smaller operators in sectors with direct public health impact.

The Oldsmar Test: Would a 2021 SCADA Attack Trigger Art. 23?

Article 23(3) of Directive 2022/2555 defines a significant incident as one that has caused, or is capable of causing, either:

• Limb (a): Severe operational disruption of the services the entity provides, or financial loss for that entity
• Limb (b): Considerable material or non-material damage to other natural or legal persons

The Oldsmar attack meets both limbs.

Limb (a) — operational disruption: Raising NaOH concentration to 11,100 ppm would render water treatment unsafe and require an emergency shutdown of the distribution system. That is severe operational disruption. Critically, Art. 23(3) uses the phrase capable of causing — the disruption does not need to materialise. The moment the attacker’s command executes and the setpoint changes from 100 ppm to 11,100 ppm, the capability for severe disruption exists and the threshold is met.

Limb (b) — damage to persons: Sodium hydroxide at 11,100 ppm causes chemical burns to soft tissue on contact with drinking water. Contaminated water would have reached consumers within 24 to 36 hours, causing physical injury across the service area. That constitutes considerable material damage to a defined population of natural persons. Again, the directive’s capable of causing language means this threshold is met at the moment the setpoint is manipulated — not when the first consumer is harmed.

The attack also triggers the mandatory 24-hour early warning pathway under Art. 23(4). Early warning must be filed within 24 hours of awareness when the incident involves suspected unlawful or malicious acts, or could have cross-border impact. The TeamViewer intrusion — external remote access via a tool running with a shared single password and no firewall — is clearly a suspected malicious act. The 24-hour clock starts at awareness, not at containment. An operator who neutralises the attack in minutes still has a notification obligation running from the moment they recognised the intrusion.

One implication matters for European operators drawing lessons from Oldsmar: the attack vector — unsecured remote desktop access — also constitutes a failure of Art. 21(2)(i) access control policies and Art. 21(2)(j) multi-factor authentication requirements. That creates dual regulatory exposure visible through the final incident report: the notification obligation under Art. 23, and the risk management failures under Art. 21. Both are visible to the competent authority. Our Art. 23 notification guide covers the documentation requirements for each stage in full.

Why SCADA Protocols Slow Down Detection

The Oldsmar attack succeeded in reaching the HMI because the underlying protocols — standard across European water utilities — provide no mechanism to distinguish a legitimate operator command from a malicious one. This detection gap directly affects when the Art. 23 clock starts.

Modbus TCP, the de facto SCADA communication standard in water treatment, transmits all commands in plaintext with no authentication and no encryption. An attacker writing register address 8 — the NaOH dosing setpoint — generates a network packet byte-for-byte identical to the same write by an authorised process engineer. The protocol records the register change; it does not record who made it, from what source address, or whether that source is authorised. The FrostyGoop malware (2024) exploited exactly this characteristic, using Modbus to manipulate industrial controllers without triggering any authentication failure — because Modbus has no authentication to fail.

DNP3, used for remote telemetry between treatment plants and unmanned pumping stations, adds CRC-based integrity checking but historically lacks authentication. Legacy DNP3 deployments — the majority of operational European installations — are vulnerable to master station impersonation, replay attacks, and function code alteration. An attacker positioned on the operational network can inject a DNP3 ANALOG_OUTPUT_BLOCK command to a remote pump controller with no valid credential. The Veridify security assessment of DNP3 documents attack methods that include forcing device restarts, disabling alarm messages, resetting operational data, and halting services — all without leaving an authentication failure in any log.

IEC 60870-5-104, which dominates European telecontrol networks, has no native authentication mechanism and transmits application-layer data in plaintext. Man-in-the-middle attacks and command injection are documented attack patterns against this protocol in both published research and real incident reports.

Secure variants exist — Secure DNP3 (SAv5/SAv6) adds challenge-response authentication; Modbus/TCP Security adds TLS — but both require deliberate implementation and create processing overhead that many legacy PLCs cannot handle. In practice, most European water utilities are running legacy protocol versions with no authentication layer.

The Art. 23 implication of the detection gap: If your detection mechanism is a process alarm — NaOH setpoint exceeds 500 ppm — rather than a behavioural anomaly detector — setpoint changed from an unrecognised source IP at 14:30 on a Friday — you are relying on the attacker making a change large enough to cross a threshold. A more subtle manipulation — a 20% chlorine reduction that gradually degrades treatment efficacy over 48 hours — may never trigger a process alarm. Detection then falls to routine lab sampling, which occurs hours or days after the change. That delay directly compresses your Art. 23 notification window: the clock starts at awareness, and awareness is delayed when your detection depends on downstream evidence rather than network monitoring.

Art. 23 Timeline and Penalty Exposure for Water Utilities

The three-stage notification cascade under Art. 23(4) applies to water utilities on the same terms as any other essential entity. The OT environment creates water-specific complications at each stage. For a detailed walkthrough of the general notification framework, see our NIS2 incident reporting guide.

Stage	Timeline	Required Content	Water Utility Challenge
Early warning	Within 24h of awareness	Suspected malicious act? Cross-border impact?	Defining “awareness” when detection comes from an operator watching an HMI, not an automated security alert
Incident notification	Within 72h	Severity, impact, indicators of compromise	OT-specific IoC collection without disrupting active plant operations or triggering chemical safety alarms
Final report	Within 1 month	Root cause, mitigation, recurrence prevention	OT forensics requires specialist vendors; SCADA historian logs must be snapshot-preserved within the first hour or they overwrite

The awareness moment problem

Art. 23’s 24-hour clock starts when the entity becomes aware of a significant incident. In water utility operations, this moment is rarely clean. Consider a realistic scenario:

• 14:30 — Process alarm fires: NaOH setpoint exceeds 500 ppm
• 14:35 — On-call operator assumes sensor fault and resets the setpoint manually
• 15:10 — Alarm fires again; the setpoint has been re-written from the same unauthorised session
• 15:30 — Operator escalates to plant manager
• 15:45 — Plant manager recognises the repeating pattern as probable SCADA manipulation and opens the incident response protocol

Awareness of a significant incident is defensibly 15:45 — the point at which someone with authority recognised the pattern as a security event, not a sensor fault. But a competent authority reviewing the incident log may argue that 14:30’s repeated alarm, coupled with two manual resets, was sufficient for recognition by a trained operator. The burden of proof lies with the entity, not the regulator.

The safest position: define your awareness moment explicitly in your incident response plan. Establish that the clock starts when any escalation above first-line operator is triggered, regardless of whether the underlying cause has been confirmed as malicious. Document the escalation with a timestamp. That timestamp is your compliance evidence for the 24-hour early warning window.

Penalty exposure

Failure to meet Art. 23 notification timelines is a direct supervisory compliance failure. Essential water utilities that miss the 24-hour or 72-hour windows, or cannot document the awareness moment, face administrative fines up to €10 million or 2% of total global annual turnover under Article 34, whichever is higher. Verbal notification chains without timestamped incident logs cannot demonstrate compliance — and that documentation gap is common in utilities where incident response has historically been handled as an operational matter rather than a regulatory one.

Water-Specific OT Incident Handling Under Art. 21(2)(b)

Article 21(2)(b) requires entities to implement incident handling measures. For water utilities, this obligation covers capabilities that IT-centric IR frameworks do not address — and the most critical difference is what happens before a network is isolated.

Safe-state determination before isolation

In IT incident response, containing a compromised server means taking it offline — a decision that typically takes seconds. In water treatment, isolating the SCADA network without first achieving a defined safe state can disable automated chemical dosing, halt pressure regulation across the distribution network, and trigger alarm cascades at unmanned pumping stations. The isolation decision that takes 30 seconds in an IT environment can require 60 to 90 minutes of preparation in an OT environment. Rushing it creates a public health risk worse than the original incident.

Your Art. 21(2)(b) incident handling procedure must include a safe-state trigger clause: before any SCADA segment is isolated, a certified process engineer must confirm that chemical dosing is in manual backup mode, all automated setpoints are verified at safe levels, and pressure regulation across the distribution network is confirmed stable. That confirmation must be documented with a timestamp — it is part of the incident evidence chain for the Art. 23 final report and demonstrates that the utility prioritised public safety during containment.

Role responsibilities for water sector incident response

Role	Art. 23 Responsibility	Water Sector Authority
CISO	Overall IR leadership; files Art. 23 notifications	IT isolation decisions; CSIRT liaison
OT Safety Lead	Advises on SCADA impact; reviews OT sections of incident report	Can block SCADA isolation pending safe-state confirmation; independent escalation authority
Process Engineer	Provides technical details for incident notification	Executes safe-state protocol; activates manual dosing controls
Compliance Officer	Prepares notification documentation; records awareness moment with timestamp	Coordinates with national competent authority; manages Art. 34 exposure
Communications Lead	Manages external communications if service disruption is announced	Coordinates with local health authority if contamination risk exists

The OT Safety Lead’s authority to block SCADA isolation is the critical difference from a standard IT IR RACI. In practice, this role must be reachable 24/7, must hold independent escalation authority not subordinate to the CISO in safety-critical decisions, and must have participated in tabletop exercises that specifically include the safe-state decision point. Generic NIS2 IR templates that assign an “OT representative” without specifying this authority level are insufficient for Art. 21(2)(b) compliance in a water utility context.

For a full six-phase IR model with Art. 23 notification gates embedded at each phase, see our NIS2 incident response playbook guide.

Documentation Requirements for the One-Month Final Report

The Art. 23 final report must document the full incident lifecycle: root cause, remediation steps, and recurrence prevention. For water utilities, the evidential chain has OT-specific elements that generic IR checklists miss.

OT log preservation — act within the first hour

SCADA systems — particularly legacy Modbus and DNP3 installations — often overwrite process historian logs on a rolling 7-day or 30-day cycle. Configuring adequate log retention is Art. 21 compliance work that must happen before any incident occurs. After an incident is identified, the first OT action — before any isolation decision, in parallel with the safe-state protocol — must be to snapshot the historian log and preserve it to an isolated, write-protected storage location. If historian snapshots are not taken within the first hour, the pre-incident baseline for setpoint changes may be lost, making root cause analysis impossible and the final report materially incomplete.

Cross-correlating network and process data

For a chemical dosing attack, the Art. 23 final report should demonstrate that the setpoint change was externally induced rather than operator error. This requires cross-correlation of three data sets: SCADA historian exports showing setpoint changes over time; network traffic logs from the boundary between IT and OT networks (if a SCADA DMZ is in place); and remote access logs — TeamViewer session records, VPN logs, or equivalent — showing sessions active at the time of the change. Without this cross-correlation, the competent authority cannot confirm the incident classification as a malicious act, which affects both the regulatory response and any potential criminal referral to national law enforcement.

Pre-contracting OT forensics capability

OT forensics requires specialist vendors with proprietary protocol parsers and SCADA historian format expertise. Most water utilities do not hold standing OT forensics contracts. The one-month final report window is frequently compromised when vendor engagement begins at Day 10 instead of Day 1. Pre-contracting an OT forensics vendor — or explicitly documenting escalation to your national CSIRT’s OT capability — is an Art. 21(2)(b) incident preparedness requirement. Including the vendor contact, contract reference, and response SLA in your incident response plan closes this gap before it matters.

FAQ: Water Sector NIS2 Incident Response

Does an OT-only SCADA attack require simultaneous GDPR notification?

Only if personal data is compromised. A SCADA attack that manipulates chemical dosing setpoints without accessing customer billing or metering systems is not a GDPR personal data breach — the two regimes run on separate tracks. Ransomware that hits both OT and IT systems simultaneously may trigger both Art. 23 and GDPR Article 33 notifications, running concurrently on different timelines (72 hours each, to different authorities).

Which CSIRT should a water utility notify?

Notification goes to the competent authority or national CSIRT designated in your member state’s NIS2 transposition law. Germany routes water sector notifications through the BSI (Bundesamt fur Sicherheit in der Informationstechnik); France through ANSSI; Ireland through the NCSC. Some member states designate a sector-specific competent authority separate from the general NIS2 CSIRT. Verify your national transposition before an incident — not during one.

How does the Aliquippa 2023 attack compare to Oldsmar in NIS2 terms?

The Aliquippa, Pennsylvania attack (November 2023) targeted internet-exposed Unitronics PLCs running default passwords, causing a pressure-boosting pump to shut down. Under NIS2, this would have triggered Art. 23 notification on Limb (a) — severe operational disruption from loss of pressure regulation — and raised Art. 21(2)(d) supply chain security questions about the Unitronics PLC as a compromised vendor component. Oldsmar enters via Art. 21(2)(f) (remote access controls absent) and Limb (b) (public health impact from chemical dosing). Different attack vectors, different Art. 21 failure modes, identical Art. 23 notification obligation.

Do wastewater operators face the same Art. 23 obligations as drinking water utilities?

Yes. Both are Annex I sectors and face identical Art. 23 reporting timelines and penalty exposure. The significant incident threshold analysis differs: a SCADA attack on a wastewater plant that bypasses treatment and releases untreated effluent into a waterway meets Limb (b) — considerable material and environmental damage — and likely triggers both Art. 23 notification to the NIS2 competent authority and separate notification obligations to the environmental regulator under national law.

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. Article 23: Reporting Obligations — NIS2 Directive (EU) 2022/2555 — nis-2-directive.com
2. Compromise of U.S. Water Treatment Facility — CISA Advisory AA21-042A, cisa.gov (February 2021)
3. NIS2 SCADA Security for Water Utilities 2026 — Jimber
4. Top 20 ICS Protocols and Their Security Risks — CyberSec Magazine
5. DNP3 Cybersecurity Risks: How to Protect ICS & SCADA Systems — Veridify Security