What should teams do when OT and IT security ownership is split?

Teams should create a shared access and response model with named ownership for every path that can reach operational systems. OT, IAM, and incident response functions need the same visibility into sessions, approvals, and containment steps. Without that shared accountability, response gaps appear exactly when a fast decision is most needed.

Why Split Ownership Between OT and IT Becomes a Control Problem

When OT and IT security are owned separately, the issue is rarely just organisational friction. It becomes a control problem because the teams that approve access, monitor activity, and execute containment may not be working from the same view of the environment. That can leave privileged pathways into operational systems with unclear ownership, delayed escalation, and inconsistent decisions during live incidents. The strongest way to think about this is through shared governance rather than shared tooling. NIST Cybersecurity Framework 2.0 remains useful here because it frames cyber risk as an enterprise responsibility, not a siloed technical task. In practice, many security teams discover the cost of split ownership only after a real outage or incident has already exposed the missing decision path.

What Shared Ownership Actually Needs to Cover

Shared ownership does not mean merging OT and IT teams into one reporting line. It means defining who owns access decisions, who sees session activity, who can suspend a pathway, and who is authorised to make containment calls when operational impact is at stake. In environments where OT systems support physical processes, those answers must be explicit before an incident starts, not negotiated during one.

A workable model usually covers four things:

Named owners for each access path into OT, including remote support routes, jump hosts, privileged accounts, and vendor connections.
One approval path for access changes, with OT and IAM both able to validate whether the request is safe for operations.
Joint visibility into session records, alerts, and change windows so one team is not acting on stale or partial information.
A pre-agreed response sequence that states who can isolate, revoke, or continue access when safety and availability are both in play.

This matters because the failure mode is often procedural, not technical. If OT can see a problem but cannot revoke access, or IT can revoke access but does not understand the process impact, containment may be delayed or overcorrected. The guidance breaks down when ownership is split but authority is not formally mapped to each operational decision.

Where the Model Gets Complicated in Real OT Environments

Tighter control over shared access often increases operational overhead, requiring organisations to balance faster containment against the risk of disrupting production systems. That tradeoff is especially visible when the environment includes third-party maintenance, legacy protocols, or safety-critical processes where a standard IT response may be too blunt. The question is not whether one team should dominate the other. It is whether the organisation can prove that both sides understand the same access path and can act without waiting for informal escalation.

There is also a governance issue where consensus is not always present. Some organisations treat OT as an exception to enterprise identity and response processes, while others force everything into central IT workflows. Both extremes can fail. The first creates blind spots, and the second can create response actions that are technically correct but operationally unsafe. The practical middle ground is a documented decision model that reflects the real dependency between access control, process continuity, and incident handling. That is where ownership split becomes manageable instead of fragile.

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 provides the primary governance reference for this topic.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.RM	Split OT-IT ownership needs enterprise risk ownership across functions.
Recommendation: Assign cyber decisions to a shared risk model across operational domains.

Risk and Threat Considerations

Split OT and IT ownership can create a governance gap where privileged access and containment authority are unclear. That gap gives attackers or insiders more room to use approved pathways before either team can intervene decisively.

Failure mechanism: The failure chain usually involves fragmented visibility into sessions, approvals, and exception handling, so one team assumes the other owns the response. That delay can let credential abuse, remote access misuse, or lateral movement persist until the operational process is affected.

Impact: The result can be slower isolation of compromised access, inconsistent containment decisions, and wider operational disruption. In OT, that can also make it harder to protect availability and safety while still stopping an active intrusion.

Practitioner Guidance

Teams often assume that a shared procedure is enough, but split ownership fails when decision rights are still ambiguous. If OT, IAM, and response leads cannot act on the same evidence set, the process will fail at the first urgent exception.

Map every OT-reachable access path to a single named business owner, a technical owner, and an incident decision owner, and make the three roles explicit in the response runbook.
Define one escalation path for session review, approval revocation, and containment that OT and IT both rehearse, including who can act when the primary owner is unavailable.
Test vendor and remote-support access separately from employee access, because third-party paths are where split ownership most often leaves approval and revocation gaps.
Run joint tabletop exercises against a live OT use case, then fix any step where the teams need informal messaging or executive intervention to decide who can isolate access.