Why OT/IT governance fails
Most OT and IT environments break down in the same places. The problem is usually not a lack of effort. It is a lack of shared rules for how decisions get made.
No shared definition of risk
IT thinks in CVEs and control gaps. OT thinks in downtime, safety, and process impact.
Unclear boundaries
Nobody is fully sure who owns remote access, patch exceptions, logging, or vendor pathways.
Emergency becomes a loophole
OT bypasses controls for uptime. IT bypasses process for speed. Both think they are being practical.
Evidence does not exist
Teams may do the right thing, but without records, audits and incident response turn into chaos.
The practical problem:
without governance, every conflict becomes a negotiation from scratch.
The vCISO model: one operating system, two execution teams
The goal is not to force OT to become IT. The goal is to create a shared governance model while allowing different implementation patterns where needed.
A vCISO sets three things:
- shared policy outcomes — what must be true
- shared decision rights — who approves what
- two implementation playbooks — how OT does it vs. how IT does it
Step 1: Define the boundary
Start with a one-page boundary statement that defines what is OT-owned, what is IT-owned, and what is shared. This is one of the highest-value governance artifacts you can create.
OT-owned systems
- PLCs, RTUs, SCADA/HMI
- engineering workstations
- historians and OT data collectors
- OT networks and field-site connectivity
IT-owned systems
- Entra ID / AD
- email and corporate apps
- corporate network and internet gateways
- SIEM / SOC tooling
- identity lifecycle
Shared systems
- remote access and jump hosts
- patching and vulnerability exceptions
- logging and monitoring for OT events
- vendor access pathways
- incident response and communications
Deliverable:
an OT/IT Responsibility Matrix. This is governance gold because it stops ownership confusion early.
Step 2: Create a joint OT/IT Security Council
This should not be a status-update meeting. It should be a small decision body with the authority to resolve exceptions, tradeoffs, and risk escalations.
| Area |
Recommended model |
| Members |
Engineering/OT lead, Corporate IT lead, Security lead or vCISO, Ops/COO delegate |
| Cadence |
Monthly operating meeting, quarterly risk review for leadership |
| Standing agenda |
critical risks, patch exceptions, vendor access reviews, incident readiness, lessons learned, decisions needed |
The 6 governance agreements that stop OT/IT conflict
1) A shared risk scoring model that includes safety and downtime
IT-only risk scoring rarely works in OT. A vCISO uses a hybrid impact model that includes:
Safety impact
Operational impact
Financial impact
Regulatory / reputation impact
Why this matters:
it allows OT to justify delayed patching without escaping governance, because mitigation, monitoring, owner, and expiry are still required.
2) Compensating controls as a formal path
OT often cannot patch on the same schedule as IT. That is normal. What is not acceptable is leaving that reality undocumented.
vCISO governance rule
If you cannot patch, you must compensate.
Typical OT compensating controls
- network segmentation and firewall restrictions
- allowlisting for protocols and management ports
- jump server access only
- MFA on remote access
- time-bound vendor access
- increased monitoring and review
Every patch exception needs an owner, compensating controls, target date, expiry date, and approver.
3) A controlled remote access model
Remote access is one of the highest-risk OT pathways. The governance model should make it one standard, not a collection of local exceptions.
Minimum controls
- approved jump host or remote access gateway
- MFA
- approval workflow for vendor access
- session logging where feasible
- quarterly access reviews
No unmanaged vendor VPNs. No temporary RDP holes. No permanent “just in case” access.
4) An OT change management fast lane
IT change processes can be too heavy for OT realities. OT ad hoc changes are too risky for governance, auditability, and security.
- standard changes with pre-approved templates
- planned changes with normal approvals
- emergency changes documented after the fact within 24–48 hours
Evidence auditors trust: a record exists, the approver is documented, validation occurred, and emergency changes have post-review notes.
5) A logging and monitoring agreement
OT environments often have legacy devices, fragile systems, and uneven logging support. That does not eliminate the need for visibility. It changes how you define the minimum viable logging model.
Define together:
- minimum OT security events to capture
- where logs go
- how often reviews occur
- which alerts actually matter
Even if you cannot log everything, you can log enough and prove review.
6) Joint incident response runbooks
IT incident response assumptions often do not fit OT reality. OT-specific playbooks are essential because safety, uptime, physical processes, and vendor dependencies change the decision model.
Runbooks should cover scenarios like:
- ransomware in IT with OT proximity
- vendor remote access compromise
- suspicious changes to control systems
- loss of visibility due to monitoring outage
- unsafe command or safety-impacting change scenario
The runbooks should define who can shut down what, when leadership is involved, and how communications work.
The no-drama RACI
The vCISO rule is simple: separate decision rights from execution responsibility.
Decision rights
- risk acceptance for OT exceptions: COO or Engineering Director with Security/vCISO concurrence
- remote access model changes: Engineering + IT + Security sign-off
- production-impacting security changes: Engineering approves the window, IT/Security define minimum controls
Execution
- Engineering executes OT changes with safety controls
- IT executes identity, network, and endpoint controls
- Security or vCISO verifies evidence, trends, and exceptions
The quarterly board pack that keeps OT and IT aligned
Leadership does not need protocol detail. Leadership needs tradeoffs, residual risk, and clear decisions.
A useful OT/IT governance pack includes:
- top 5 OT cyber risks with business and safety impact
- patch exception summary with count, age, and expiry dates
- remote access governance status
- logging coverage and review cadence
- incident readiness and lessons learned status
- decisions required, such as funding, lifecycle replacements, or vendor constraints
Common failure modes and fixes
Failure: OT refuses IT controls
Fix: define outcome-based requirements with OT-tailored implementation.
Failure: IT forces patches that create downtime
Fix: use risk-based patch windows, compensating controls, and exception expiry governance.
Failure: Vendors have permanent access
Fix: require time-bound approvals, quarterly reviews, and session logging.
Failure: Nobody owns exceptions
Fix: maintain an exception register with owners, due dates, and executive approvals.
Failure: We can’t prove anything
Fix: keep quarterly evidence packs for remote access reviews, exceptions, tabletop records, and change samples.
Next steps
If OT and IT are still operating as two separate worlds, the fastest improvement is not another policy. It is a shared governance model with clear decision rights, exception rules, and evidence habits.
Final takeaway
OT and IT do not need the same implementation pattern to share one governance model. That is the mistake many programs make. A strong vCISO model defines common outcomes, common decision rights, and evidence discipline while still respecting the operational reality of engineering environments.
When that model exists, leadership can make tradeoffs clearly, exceptions stop becoming permanent, vendor access becomes controlled, and audits stop turning into debates about who owns what.
In one line
The best OT/IT governance model does not force one side to win. It gives both sides a shared way to manage risk, uptime, and accountability together.
Follow Canadian Cyber
Practical cybersecurity + compliance guidance:
