Accountability should sit with both security and operations leadership because segmentation affects cyber risk and production continuity at the same time. The right owners are the people who understand the business process, the controllers, and the incident response trade-offs. If those groups are not aligned before an event, containment decisions will be made under pressure.
Why This Matters for Security Teams
Segmentation is not just a network design choice. In IT/OT environments it determines what can be isolated during an incident, what can continue running, and how far malware or misuse can move across zones. That makes accountability a governance issue, not a ticketing detail. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that access control, boundary protection, and incident response must be coordinated across owners, not treated as separate technical silos.
Security teams often focus on architecture diagrams, while operations teams focus on uptime and process safety. Both are necessary, but neither can approve segmentation in isolation. When segmentation changes affect vendor access, remote maintenance, or safety-related controllers, the decision also touches resilience, change control, and recovery objectives. NHIMG’s research on the Ultimate Guide to NHIs shows how often organisations underestimate identity and access sprawl in environments that were assumed to be “internal.” That same blind spot appears in IT/OT boundary design, where temporary exceptions become standing access paths.
In practice, many security teams discover segmentation gaps only after an outage, a vendor incident, or an engineering exception has already created a permanent exposure path.
How It Works in Practice
The most workable model is shared accountability with explicit decision rights. Security leadership should own the risk criteria, control baseline, and exception process. Operations leadership should own production continuity, safety impact, and maintenance feasibility. Plant managers, network architects, and incident responders should be part of the approval chain when segmentation affects controllers, historians, jump hosts, or remote support channels.
Current guidance suggests using a documented boundary model that defines zones, conduits, trust levels, and recovery paths. That model should state what traffic is allowed, what requires brokering, and what must never cross the segment. The decision should also reflect how identities are handled at the boundary, especially service accounts, vendor credentials, and privileged remote access. NHIMG’s Schneider Electric credentials breach is a useful reminder that segmentation failures and credential misuse often reinforce each other rather than appearing as separate problems.
Practitioners usually get better outcomes when they assign three distinct responsibilities:
- Risk owner: approves the business risk of the segmentation design.
- Control owner: implements routing, firewall, and access enforcement.
- Operational owner: validates that maintenance, monitoring, and failover still work.
That separation matters because IT/OT segmentation is usually revised through change windows, emergency fixes, and vendor interventions. Each path needs a clear sign-off trail and a rollback plan. If the organisation uses zero trust concepts, the same logic applies to identities and sessions crossing the boundary, not only to IP ranges and VLANs. These controls tend to break down when legacy controllers cannot support modern authentication or when plants depend on undocumented vendor tunnels, because exception handling then becomes the real architecture.
Common Variations and Edge Cases
Tighter segmentation often increases operational overhead, requiring organisations to balance containment benefits against maintenance speed and safety constraints.
There is no universal standard for this yet. In greenfield environments, security may drive the design more directly, but in brownfield plants the operations team often has to preserve process stability while security narrows pathways over time. In highly regulated sectors, legal, safety, and compliance stakeholders may also need formal approval because segmentation changes can affect auditability and incident reporting.
The hardest edge case is remote vendor support. If a supplier still needs access to patch or troubleshoot equipment, current guidance suggests replacing broad connectivity with time-bound, brokered, and monitored access. Another common exception is shared infrastructure where IT and OT traffic converges on historians, backup systems, or data replication links. In those cases, the accountability question should include who can accept residual risk if isolation is technically possible but operationally disruptive. NHIMG’s research on the Ultimate Guide to NHIs also highlights how frequently secrets and service accounts are mishandled, which matters because segmentation cannot compensate for weak credential governance at the boundary.
In practice, the best accountability model is the one that names a single risk decision maker, while requiring both security and operations to validate the design before anything reaches production.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-1 | Segmentation accountability is a risk governance decision, not only a technical control. |
| MITRE ATT&CK | T1021 | Remote services and admin paths are common IT/OT crossover points for abuse. |
| NIST SP 800-53 Rev 5 | SC-7 | Boundary protection maps directly to IT/OT segmentation design and enforcement. |
Assign a named risk owner who approves segmentation trade-offs against continuity and safety.
Related resources from NHI Mgmt Group
- What is the difference between OT network segmentation and identity-based access control?
- Who is accountable when cyber crisis decisions stall across teams?
- Who is accountable when vendor sessions on OT systems are not fully logged?
- Who should be accountable for access review decisions under SOX or ISO 27001?
