OT Governance Has to Cross Security, Engineering, Operations, and Safety

The real OT problem lives in the seams.

That is where standards collide with uptime. That is where safety collides with cyber urgency. That is where a clean enterprise control meets a dirty plant reality and nobody wants to own the tradeoff.

Most manufacturers understand this at a gut level. Few structure around it.

They create a reporting line. They assign a program lead. They launch a steering committee. Then they assume the organization has solved OT governance. It has not. The question is never whether a box sits under the CISO, the COO, engineering, or some hybrid model. The question is whether security, engineering, operations, safety, risk, and the enabling functions can make a hard decision together before a production-impacting event makes the decision for them.

That is where OT governance fails.

The source set behind this series is unusually clear on one point: OT governance has to be cross-functional.[1][2][3] NIST describes OT cybersecurity work as spanning IT, control engineering, operators, security experts, and enterprise risk management.[1] ASD/ACSC supports formal steering-committee or advisory-board structures to coordinate cyber and business leadership.[2] SANS reinforces the same lesson from incident and tabletop practice: roles and responsibilities have to be worked out across engineering, operations, safety, and IT/security before an incident tests them.[3]

That conclusion matters because a lot of manufacturing organizations still behave as if OT risk can be solved inside one silo.

Security thinks the problem is standards.

Engineering thinks the problem is unrealistic policy.

Operations thinks the problem is downtime.

Safety thinks the problem is late engagement.

Procurement thinks the problem is vendor contract language.

Everybody is partly right. That is why no single group can solve it alone.

A clean reporting line does not settle a real OT decision

This is where many OT programs stall after the first governance redesign.

The company picks a home for OT cybersecurity. Good. Somebody now has formal accountability. Better than before.

Then a real issue arrives.

A site needs a production-season exception on segmentation work because the packaging line cannot absorb a restart risk before quarter close.

The OEM still needs remote access for break-fix support because the new format conversion has been unstable.

The plant manager will not take a line outage without operations coverage.

The safety lead wants a hazard review before any network change that could affect system behavior.

Corporate security says the current path violates the standard.

Who decides.

The org chart does not answer that.

The org chart tells you who gets invited first. It does not tell you how the tradeoff gets settled. That is why OT governance becomes cross-functional the moment the issue stops being theoretical.

The evidence points the same way. Even if the reporting line is clean on paper, OT cybersecurity still fails if cross-silo decisions remain informal, contested, or slow.[1][2][3]

That is worth sitting with for a minute. It explains why some organizations look mature in charts and weak in practice. They assigned responsibility at the top. They never built a mechanism for resolving conflicts below it.

No single function owns the full problem

You can see the problem clearly when you break down what each group actually brings.

Security brings standards, threat logic, incident structure, and the discipline to push recurring issues into enterprise view.

Engineering brings system behavior, fragility, control logic, restart risk, and the local knowledge that stops a clean security plan from turning into a bad plant decision.

Operations brings uptime, throughput targets, change timing, shift realities, and the business consequences of getting the sequence wrong.

Safety brings consequence thinking. Not generic compliance language. Real judgment about what happens when a control change, outage sequence, or degraded mode creates process risk.

Risk and compliance bring escalation language, tolerance boundaries, formal ownership expectations, and the discipline to decide whether the organization is accepting a business risk or merely delaying it.

Procurement and vendor management bring contract leverage, third-party terms, service expectations, and visibility into how external access models spread across the footprint. In manufacturing this is rarely a side concern. Procurement signs the master service agreement, engineering accepts the OEM access pattern that comes with it, and security finds out eighteen months later when the same remote-support tunnel has been replicated across six plants. If procurement is not in the governance forum, the trust boundary is being set somewhere the forum cannot see.

Infrastructure and architecture teams bring shared services, identity models, remote access patterns, network design, and the enterprise consequences of one plant’s local workaround becoming standard practice somewhere else.

Leave out any one of those groups at the wrong time and you distort the decision.

Security without operations produces standards that plants route around.

Operations without security produces short-term continuity and long-term exposure.

Engineering without safety can miss consequence pathways. Safety without engineering can block changes without understanding what is technically feasible. Procurement without security can normalize vendor arrangements that nobody would approve if they saw the full trust boundary.

That is why OT governance has to cross functions. The work is not political because people enjoy meetings. The work is political because the decision surface is shared.

What a cross-functional OT governance model actually does

Bad governance models sound busy. Good ones move decisions.

That is the distinction.

A real OT governance mechanism should do five things.

First, it should review major exceptions and force them into the open before they become normal operating habit.

Second, it should resolve recurring cross-site issues, especially the ones no single plant can solve alone.

Third, it should prioritize shared initiatives where the enterprise has to choose between competing needs, limited shutdown windows, and limited budget.

Fourth, it should surface operational conflicts early, while there is still time to change the decision path instead of waiting for an incident or outage.

Fifth, it should sponsor exercises, post-incident reviews, and lessons learned that expose governance weakness before the same problem repeats.

The evidence base supports an OT cyber steering committee or equivalent governance forum. ASD/ACSC explicitly supports a cybersecurity steering committee or advisory board. NIST and practitioner material support cross-functional OT governance more broadly.[1][2][3]

The point is not the committee name. The point is whether the forum has enough range and authority to settle issues that cut across security, operations, engineering, safety, and risk.

If the forum cannot do that, it is not governance. It is scheduling.

What an exception path actually looks like

Take a common one. Plant X requests a ninety-day deferral on Phase 2 segmentation because the new SKU launch consumes every available shutdown window through the end of the quarter.

The exception arrives in the forum with five things on the page.

The security standard being deferred and the specific control objective it serves.

The operational driver — what production outcome justifies the deferral.

The compensating control in place during the deferral window.

The date and trigger for re-evaluation.

The named risk owner if a cyber event occurs in the deferral window.

The forum decides. The decision is logged. The risk owner signs.

That is the difference between governance and email. The exception still happens. The standard does not get quietly abandoned. The risk does not float without an owner. And the next plant requesting the same deferral arrives with a precedent, not a negotiation.

If your forum cannot handle an exception this way, the problem is not the standard. The problem is the forum.

What this is not

This needs to be said because OT leaders have all seen the fake version.

Cross-functional governance is not a monthly status theater where each function reads out updates and nobody changes a decision.

It is not a parking lot for site complaints.

It is not a place where security presents the standard after it has already been decided and operations gets to react too late.

It is not a meeting where safety is invited for one slide at the end.

It is not a board report in disguise.

It is a place where decisions move.

That means a few practical things.

Issues arrive with enough fact pattern to decide something.

Local constraints get represented by somebody who actually knows the plant.

Enterprise standards get represented by somebody who can explain the rationale and the boundary conditions.

Safety gets involved before the proposed action affects process behavior.

Risk ownership is explicit when the standard cannot be met.

Follow-up is tracked until the issue closes, escalates, or turns into a funded enterprise change.

That is not bureaucracy. That is the minimum structure needed to stop cross-silo OT decisions from dissolving into email and habit.

Who needs to be in the room

This part is usually more important than the meeting calendar.

A manufacturing enterprise OT governance forum should include the people who can change the outcome.

That usually means the CISO or a delegate with real authority.

It means the OT security leader or program lead.

It means operations leadership, not just a local engineer borrowed for one meeting.

It means engineering leadership or control-system ownership from the affected environment.

It means a safety representative when process behavior, degraded mode, or recovery sequence could create safety consequences.

It means enterprise architecture or infrastructure leadership when the issue affects shared remote access, identity, segmentation patterns, or common services.

It means risk or compliance when the issue requires formal risk acceptance, escalation, or board-facing logic.

It often means procurement or vendor management when the problem involves OEM support, integrator access, or a service model spreading across sites.

The exact titles will change by company. The principle does not. The forum has to include the functions that own the decision surface.

This is where many enterprises make a cheap mistake. They invite too much security and not enough operations. Or they invite plant leaders after the standard is already built. Or they bring executive sponsorship at the top but no decision-capable operators underneath it. Then they wonder why the committee exists on paper but not in the real work.

What makes this harder in manufacturing specifically

OT governance is hard everywhere. Manufacturing has its own texture that makes it harder.

Multi-plant heterogeneity from M&A. A company that grew through acquisition rarely has a single OT stack. One plant runs Rockwell. The next runs Siemens. The third runs an integrator’s custom HMI on top of equipment the OEM no longer supports. Enterprise standards have to land on all of them, and the governance forum has to absorb that variance without pretending it does not exist.

OEM and integrator dependency. Production lines are built around OEM relationships that often include remote support, periodic firmware updates, and integrator change windows that nobody renegotiated when the security standard was written. Removing that access is not a configuration change. It is a commercial conversation. The forum has to be able to have that conversation.

Campaign and seasonal production cycles. Food, beverage, CPG, and chemicals run on production campaigns where the change window is not next maintenance Sunday. It is the four hours between the cleanout and the next SKU. Security work that does not fit that window gets deferred. Governance has to surface those deferrals before they become permanent.

Co-manufacturers, co-packers, and contract relationships. The trust boundary is not the plant fence. It is the network of partners running portions of the supply chain on your label. Their OT exposure is your OT exposure. Almost no governance forum represents them at the table.

Customer audits and insurance pressure. Manufacturing CISOs are increasingly governed by external forcing functions — automotive OEM audits of Tier 1s, retailer audits of CPGs, pharma audits of CMOs, and cyber insurance questionnaires that have moved from checkbox to substantive. These are not governance theory. They are deal terms and renewal conditions. Your forum either produces evidence that satisfies them or it does not.

None of these are reasons to weaken the model. They are reasons to make sure the people in the room actually understand the operating environment the model has to survive.

Where companies get this wrong

The failures repeat often enough that they are worth naming directly.

The first failure is too much security, not enough operations.

Security teams often build the strongest governance language and the weakest operational legitimacy. They know the standard. They do not own the restart sequence. If the plant sees the governance forum as a one-way policy engine, it will route around it.

The second failure is leaving safety out until late.

This is one of the clearest blind spots in OT programs. A cyber control change may look rational until someone asks what happens if the process enters a degraded state halfway through execution or if recovery requires manual intervention under pressure. Safety does not fix bad security design after the fact. Safety changes the decision before the design lands.

The third failure is inviting plant leaders only after standards are already set.

That creates resentment for a reason. The plant becomes the place where abstract enterprise logic meets physical consequence. If local leaders show up too late, the conversation stops being collaborative. It becomes compliance theater followed by exception handling.

The fourth failure is executive sponsorship with no authority below it.

Some programs look strong because the steering committee has senior names attached. Then every real decision gets pushed back down into unresolved middle layers. Executive support matters. It does not replace decision rights close to the work.

The fifth failure is cadence without closure.

The meeting happens. Notes get captured. Actions get assigned. The same issue comes back a month later because nobody had authority to settle it, fund it, or elevate it. That is how cross-functional governance becomes overhead instead of leverage.

Treat those five failure modes as diagnostics. If your forum has them, the org model is not wrong in theory. It is weak in practice.

A scene most OT leaders have lived through

Picture a ransomware event that starts in IT and raises immediate concern about OT spread. Pick your reference incident — Norsk Hydro, Colonial Pipeline, JBS, Clorox, Dole, MKS Instruments. The pattern repeats.

Security wants to isolate fast.

Operations wants to keep the line running because a sudden stop creates scrap, delay, and downstream disruption.

Engineering wants to understand whether the control network actually has exposure before anyone pulls a connection.

Safety wants to know what happens if isolation changes process behavior or disables a monitoring dependency tied to operator action.

Communications wants to know what to tell the business unit.

The site leader wants one answer, not five competing theories.

Now imagine those groups have never had to make this decision together before.

The problem will look technical at the surface. It is not. The real failure is that the organization never built the governance path for a production-impacting cyber decision.

SANS makes this point from the field side. Roles and responsibilities need to be worked out across engineering, operations, safety, OT security, and IT security before an incident tests them.[3]

That is why exercises matter so much.

They do not just test incident response. They test whether the governance model is real.

Exercises expose weak governance faster than policies do

A written policy can hide confusion for months.

A tabletop exposes it in thirty minutes.

Who can authorize isolation.

Who can accept degraded operations.

Who can say the plant cannot absorb the change.

Who can overrule the local preference when the risk pattern is bigger than one site.

Who owns the external vendor call if OEM remote access is part of the recovery path.

These are not documentation questions. They are governance questions.

That is why incident governance and role clarity need to sit near the center of the model, not at the edge.[1][3] If an organization wants to know whether its cross-functional OT model works, it should run exercises that force security, operations, engineering, and safety into the same decision chain.[1][3]

A good exercise does not end with, “We need better communication.”

It ends with something sharper.

We do not know who owns the risk acceptance when the line cannot meet the standard.

We do not have a clear sponsor for third-party access in outage conditions.

We have no enterprise rule for how repeated plant exceptions escalate.

We let safety in too late.

We do not know who can choose isolation over production continuity.

Those are governance findings. They matter more than whether the tabletop deck looked polished.

Cross-functional governance keeps local tradeoffs from becoming enterprise accidents

This is the part boards and executive teams need to hear.

Cross-functional OT governance is not overhead. It is the mechanism that prevents local operational tradeoffs from becoming unmanaged enterprise risk.

A plant can make a reasonable short-term choice under pressure. That does not mean the enterprise should allow the same short-term choice to multiply silently across the footprint.

A security team can push a reasonable standard. That does not mean the standard survives contact with process reality unless operations, engineering, and safety shape the path.

A business unit can push a modernization project. That does not mean the connectivity, vendor access, and recovery implications have been governed at the right level.

Cross-functional governance exists to make those collisions visible early enough to act on them.

That is the real value.

Not a meeting.

Not a committee slide.

A mechanism that forces the right conflict into the room before the wrong event forces it into the plant.

Acknowledge the political cost

Building a real cross-functional forum is not a free move for you.

Naming functions that have been making OT decisions informally will threaten existing balances. Engineering may hear it as security overreach. Operations may hear it as another corporate meeting. Plant leadership may hear it as a loss of local autonomy. Safety may hear it as cyber pulling them into work they are not staffed for. Procurement may not want the scrutiny on existing vendor arrangements.

None of those reactions are wrong. They are predictable.

Pretending the forum will be welcomed because it is good practice will get you eaten.

The defense is the same as in the earlier articles. Shared ownership. Before you stand up the forum, bring in the executives who should co-own it. The COO or VP Manufacturing for operational tradeoffs. The General Counsel for regulatory and disclosure exposure. The CFO for capital allocation tied to repeated exceptions. Internal Audit for governance integrity. Safety leadership if process consequence is in scope.

Make the forum theirs, not just yours. A CISO who tries to convene a cross-functional governance body alone gets read as expanding territory. A CISO who builds the coalition first gets read as doing the company’s work.

That distinction matters more than the charter, the cadence, or the slide template.

What this means for manufacturing CISOs

If you are leading OT cyber governance, do not ask first whether you have a committee. Ask whether you have a place where security, engineering, operations, safety, and risk can make a hard call together.

If the answer is no, build that before you build more reporting.

If the answer is yes, test whether the forum can actually move decisions.

Bring a real exception.

Bring a real vendor access issue.

Bring a real sequencing conflict between security work and production demand.

Bring a real recovery scenario where isolation timing matters.

See what breaks.

If the room cannot settle those issues, the governance model is still too shallow.

That matters because cross-functional governance is not the last layer. It is the layer that makes the next layer possible.

Your Monday move

Before your next operations review, do one thing. Pull the last three major OT exceptions your organization granted. For each, write down who actually decided, what the compensating control was, and whether a re-evaluation date exists.

If any of the three are unclear on any of those points, you do not have a forum yet. You have meetings.

That is your starting point. From there, score your current forum against the five failure modes in this article. Map your seats against the seven functions named earlier. Pick one upcoming production-impact decision and route it through the forum on purpose — not as a ceremony, as a working session under real constraints.

None of that requires new budget or a reorganization. It requires the discipline to use the forum you already have for the decisions it was meant to handle.

And once the forum can actually settle real issues, the next question gets harder. How do you assign actual decision rights instead of general responsibility. That is where most OT RACIs fall apart. That is the next article.

Sources

NIST, Guide to Operational Technology (OT) Security (SP 800-82 Rev. 3) — https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=956505

ASD/ACSC, Guidelines for cyber security roles — https://www.cyber.gov.au/business-government/asds-cyber-security-frameworks/ism/cyber-security-guidelines/guidelines-for-cyber-security-roles

SANS Institute, ICS/OT Cybersecurity Leadership: The Mission is Safety and Fundamentals First — https://www.sans.org/blog/icsot-cybersecurity-leadership-mission-safety-fundamentals-first