Ownership should sit with a shared governance model rather than one side alone. IT and OT teams need clear accountability for segmentation, monitoring, incident response, and change management, because the risks span both domains. The article suggests that as organisations scale, the roles bifurcate, but coordination still depends on common processes, communication, tooling, and an agreed understanding of safety and continuity priorities.
Shared ownership works better than an IT-only or OT-only model
Industrial environments create coordination problems that neither IT nor OT can solve alone. IT teams usually own identity, endpoint, network, and enterprise monitoring; OT teams usually own safety, process availability, engineering constraints, and vendor-specific operational knowledge. When ownership is split badly, organisations either over-centralise and miss plant realities, or over-localise and leave security decisions disconnected from enterprise governance. The right answer is a shared governance model with a clear decision owner for each control domain, especially where security changes can affect safety or uptime. In practice, many security teams encounter failures only after a plant change, outage, or incident exposes that no one was explicitly accountable for the handoff.
For that reason, coordination should be governed as a joint operating model, not an informal collaboration habit. The most effective arrangements define who approves access, who validates impact on control systems, and who is accountable when conflicting priorities arise. For broader guidance on control ownership and governance, the NIST control family structure is a useful reference point, especially for separating policy, monitoring, incident handling, and recovery responsibilities.
How coordination actually works across enterprise and plant layers
Coordination between IT and OT security teams is less about merging teams and more about defining where each team’s authority begins and ends. IT typically leads on enterprise identity, remote access, email, cloud, vulnerability processes, and central logging. OT typically leads on asset criticality, process impact, engineering windows, vendor maintenance constraints, and any security action that could change controller behaviour or disrupt production. The shared layer is where both domains must agree on segmentation, asset visibility, alert triage, incident escalation, and change control.
A practical model usually includes a named coordinator or governance forum that resolves disputes and keeps the two operating views aligned. That coordinator does not need to replace either team; the role is to make sure that a network change, patch decision, or incident response step is judged against both cyber risk and operational consequence. This is particularly important where a control action that is routine in IT, such as aggressive scanning or endpoint quarantine, can be unsafe or destabilising in OT.
- Jointly define which actions are pre-approved, which require consultation, and which require explicit operational sign-off.
- Use common asset and service inventories so both teams are working from the same picture of exposure.
- Separate technical ownership from accountability for coordination, because a control can be implemented by one team but governed by both.
- Align incident response so that cyber containment does not override process safety or recovery sequencing.
The model breaks down when coordination depends on personal relationships, undocumented exceptions, or ad hoc escalation paths rather than a stable process with defined decision rights.
Where the model gets harder: safety, legacy systems, and emergency change
Tighter coordination often increases approval overhead, requiring organisations to balance faster security action against the risk of interrupting industrial operations. That tradeoff becomes more visible in environments with legacy equipment, limited patch windows, vendor lock-in, or strict safety interlocks. In those settings, the cleanest IT security practice may be the wrong OT decision if it creates downtime, trips a process, or interferes with validated engineering states.
The biggest edge case is emergency response. During an active incident, teams may need to isolate systems quickly, but the isolation method itself can create safety or recovery risk if OT dependencies are not understood. Another common variation is mixed ownership of remote access for integrators and OEMs, where the business may think IT owns the control while OT bears the operational consequences. Industry guidance is not fully consistent on organisational structure, but it does agree that accountability must be explicit when security choices cross cyber and physical boundaries.
If the organisation cannot say who can approve segmentation changes, who can suspend remote access, and who can authorise recovery steps during an incident, the coordination model is too weak to rely on.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.1 — Organizational Context | IT-OT coordination depends on agreed governance and decision boundaries. |
| PR.AC-1 — Identity and Access Management | Cross-domain access and remote maintenance require controlled authorization. | |
| RS.CO-2 — Incident Reporting | Coordinated incident escalation is central where cyber and plant impacts overlap. | |
| Recommendation — Define IT-OT governance roles and decision rights for shared security outcomes. Restrict cross-domain access to approved users and maintenance paths. Establish shared escalation paths for incidents that affect OT operations. | ||
| CIS Controls v8 | 12.1 — Network Infrastructure Management | Segmentation and shared network changes are core IT-OT coordination points. |
| Recommendation — Manage segmentation changes through a controlled process with both teams involved. | ||
Practitioner Guidance
What to prioritise: Assign one named coordination owner for the IT-OT interface, then define decision rights for access, segmentation, monitoring, and incident response. The owner should manage the process, not absorb every technical task.
What to verify: Confirm that each recurring cross-domain decision has an agreed approver, a fallback approver, and a documented escalation path. If a decision depends on informal phone calls or tribal knowledge, it is not yet governed.
Decision rule: If a control change can affect uptime, safety, or validated process behaviour, OT must have approval authority or veto input. If the change is enterprise-only and cannot affect production, IT can usually lead.
Common mistake: Treating “joint ownership” as shared ambiguity. Effective coordination needs one accountable owner for the relationship, even when execution remains distributed across teams.
Practitioner takeaway: The best ownership model is the one that makes cross-domain decisions auditable before an outage forces the organisation to discover who was supposed to decide.
Related resources from NHI Mgmt Group
- What is the difference between IT and OT security priorities when assessing ransomware exposure in industrial environments?
- How should security teams govern machine identities in OT environments?
- How should security teams govern machine identities in industrial environments?
- How should security teams govern machine-to-machine MFA in industrial environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
