Who is accountable when a water utility loses control of OT systems?

Why This Matters for Security Teams

When a water utility loses control of OT systems, accountability is not a paperwork exercise. It determines who can isolate affected assets, who can suspend remote operations, and who has authority to prioritise public safety over uptime. In critical infrastructure, unclear ownership often turns a manageable incident into a prolonged operational disruption, especially when engineering, security, and third-party support teams all believe another group is “handling it.”

For security leaders, the immediate concern is control over privileged pathways: remote access, vendor access, engineering workstations, and service accounts that can reach PLCs, HMIs, historians, and safety-related components. The governance question is also legal and regulatory, because regulators and sector oversight bodies expect clear decision-making, escalation, and evidence of control. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it ties accountability to defined controls, not informal assurance.

In practice, many security teams encounter accountability gaps only after an outage, when the first hour has already been lost to confusion over who could act, who had credentials, and who was authorised to make the shutdown decision.

How It Works in Practice

Accountability in OT environments should be defined across three layers: operational ownership, security oversight, and executive authority. Operational ownership covers the people who understand process stability, asset dependencies, and safe shutdown procedures. Security oversight covers identity, access, monitoring, and incident coordination. Executive authority covers business risk acceptance, emergency declarations, and external reporting. The point is not to merge these roles, but to make the handoffs explicit before an event.

Practically, this means mapping each critical OT access path to a named owner and an approved response path. That includes remote access gateways, vendor support channels, shared engineering accounts, break-glass credentials, and any privileged path that can alter controller logic or disable monitoring. Where possible, privileged access should be time-bound and reviewed, and access approval should be traceable to a specific role rather than a generic team name. Guidance from CISA defensive measures for OT environments reinforces the need for segmentation, access restriction, and recovery planning around control systems.

• Assign a primary owner for each OT asset class, including controllers, remote access, and safety-adjacent systems.
• Document who can approve emergency access, who can revoke it, and who validates the revocation.
• Separate operational decision-making from administrative access so that “having access” is not confused with “having authority.”
• Test containment workflows so that security and operations can act without waiting for an unavailable manager.

Governance should also extend to logging and evidence. If a utility cannot show who approved privileged access, who used it, and when it was withdrawn, accountability will be disputed after the fact. That matters for incident response, post-incident review, and regulatory reporting. These controls tend to break down in utilities that rely on legacy OT estates with shared accounts, undocumented vendor pathways, and informal weekend support arrangements because authority is dispersed faster than it is recorded.

Common Variations and Edge Cases

Tighter control often increases operational overhead, requiring organisations to balance rapid restoration against separation of duties and auditability. In small utilities, the same person may wear multiple hats, which is workable only if approvals, emergency roles, and compensating controls are documented in advance. Best practice is evolving for environments where OT and IT teams are deeply converged, so current guidance suggests formalising accountability at the process level even when staffing is limited.

There are also important edge cases. If a managed service provider administers part of the OT estate, accountability still stays with the utility for risk acceptance and incident oversight, even if some technical actions are outsourced. If the affected systems support water treatment safety functions, the incident owner may shift from IT-style containment to process safety leadership very quickly. In cloud-connected monitoring or analytics platforms, responsibility may also extend to third-party identity governance, because a compromised non-human identity can become the path into OT-relevant environments.

For audit and governance purposes, it is useful to align accountability with NIST Cybersecurity Framework 2.0 functions for governance and response, while keeping a separate OT-specific incident command model. Where remote access is involved, the answer increasingly depends on whether privileged access was issued to a human operator, a vendor account, or an NHI that was not sufficiently governed. That distinction is often decisive in post-incident investigations, but it is not always captured in older OT policies.

Related resources from NHI Mgmt Group

• How should security teams control vendor access in water utility OT environments?
• Who is accountable when vendor sessions on OT systems are not fully logged?
• Who is accountable when vendor access reaches OT systems through convergence?
• Who is accountable when a SaaS identity service loses FedRAMP-aligned control?