Most OT security programs fail for the same reason: not missing technology, not missing tools, missing governance. A disciplined team with weak governance loses to an average team with strong governance every single time.

Most OT security programs do not fail because the technology is wrong, or because the team is too small, or because the budget is too low. They fail because nobody owns them.

A disciplined team with weak governance loses to an average team with strong governance every single time.

The three governance questions that separate mature from immature programs

1. Who actually owns OT cybersecurity?

In most organisations, the answer is a shrug. “IT owns IT security, and somehow OT security, because who else would?” That is the most common answer I get, and it is wrong.

A mature program has a named individual (a head of OT security, or equivalent) who:

• Has the budget authority to fund OT-specific controls.
• Has the seniority to push back on operations when necessary.
• Has dual reporting into IT security (for policy alignment) and operations (for physical-world context).
• Is accountable to the board for OT cyber risk.

If this person does not exist in your organisation, your “OT security program” is a project, not a program.

2. Where are the policies, and do they differ from IT?

Most organisations have a cybersecurity policy inherited from IT that mentions OT in a footnote. This policy tells plant operators to “change passwords every 90 days” (which is impossible on most HMIs) and to “apply patches within 30 days of release” (which will trip the plant if you try).

Mature governance writes OT-specific policies that acknowledge:

• Patching cadence is measured in plant shutdowns, not days.
• Password changes are scoped by account type (service accounts, shared operator accounts, engineering accounts).
• Remote access has additional controls over IT remote access.
• Data classification and retention differ between enterprise and industrial data.
• Incident response authority is shared with operations leadership.

These policies need to be signed by both the CISO and the COO. If only one signature is on the document, it is an IT policy with OT in the name.

3. How is OT cyber risk reported to the board?

If your board report on cybersecurity has one line about OT (“our plants are air-gapped, so exposure is limited”), your governance is immature.

A mature board report includes:

• OT-specific risk metrics (number of unsegmented assets, coverage of asset inventory, mean time to patch critical OT, OT-specific incident count).
• Status against the OT security roadmap (not just “investment areas,” actual progress against a named plan).
• Integration with ERM. OT cyber risk as an entry in the enterprise risk register, with a named risk owner, not buried under “IT risk.”
• Forward-looking scenarios. “If this NIS2 obligation passes, here is what it costs us.”

The absence of OT from the board report is the biggest governance failure of all. The board cannot manage what it cannot see.

Three governance frameworks and where they fit

• NIST Cybersecurity Framework (CSF).High-level, flexible, widely understood. Good for overall program communication. Weak on OT-specific controls. Best paired with something more prescriptive for the technical detail.
• IEC 62443.The global OT cybersecurity standard. Zone-and-conduit architecture, Security Levels, Foundational Requirements. Prescriptive at the system and component level. Pair with NIST CSF for the governance wrap.
• NIS2 / sector-specific regulations.The external driver in most jurisdictions. Sets timelines, mandates risk assessments, requires incident reporting. Usually does not tell you how,just that you must.

A common mature stack: NIST CSF for strategy and board communication, IEC 62443 for architecture and controls, NIS2 (or equivalent) as the compliance wrapper.

What to do in the next 90 days

Three concrete governance actions, prioritised:

1. Name the owner.Whoever is already doing the OT security work, make it official. A signed charter, a spot on the org chart, reporting lines to both IT security and operations. This one step unblocks everything else.
2. Write the OT-specific policy addendum.You do not need to rewrite your entire cybersecurity policy. You need a 5 to 10 page addendum that specifies how each IT policy applies (or does not) in OT environments.
3. Add OT metrics to the board pack.Three metrics are enough to start: coverage of asset inventory, number of critical OT vulnerabilities with active mitigations, and OT incident count. Trend them every quarter.

These three steps do not cost much. They do not require new tools. But they move your program from “project” to “program,” and that is the transition that matters.

RelyBlue helps organisations design OT security governance aligned to IEC 62443, NIST CSF, and local regulation. Contact us for a governance review.