When Confidentiality Isn't the Point: Board Governance of Operational Technology Risk

Most cyber reporting that reaches a UK board is shaped by one question: what would happen if the wrong people obtained the wrong data? That framing is appropriate for a customer database or a finance system, but it translates poorly to the estate that runs the plant. In operational technology (OT) — the control systems behind production lines, water and energy assets, distribution centres, laboratories and building services — confidentiality is rarely the dominant concern. Availability and integrity come first, and in many settings safety sits above both.

The distinction matters because it changes the shape of the risk, the cost of the remedy and the questions a director should be asking. A patching programme that a board would rightly demand for its ERP estate may be technically impossible on a control system certified to a fixed software build, and attempting it may create more operational risk than it removes. Clear-headed governance starts by recognising that the shop floor is not a branch of the server room.

Why the familiar security arithmetic fails

Information security practice has been built around the relative cheapness of downtime. A retail website can be restored, a mailbox can be recreated, a laptop can be rebuilt. In OT, the asset at the end of the network is often a physical process that cannot be rebooted without consequence. Restarting a kiln, a pasteuriser, a chemical line or a chilled distribution hall carries cost, delay and, in some cases, a genuine safety hazard.

Add three further complications. First, the equipment lifecycle is measured in decades, not years, so estates accumulate human-machine interfaces running operating systems that the vendor no longer supports. Second, change control is owned by engineering and maintenance functions rather than by the IT department, and rightly so — a security team that patches without the plant's consent is a liability. Third, connectivity has crept in quietly. What was described as an air gap in a 2015 architecture diagram is frequently bridged today by a reporting link, a remote support tool or a historian feeding a cloud analytics platform.

The consequence is that the usual assurance artefacts — vulnerability counts, patch compliance percentages, endpoint coverage — describe the OT estate poorly, and can give a false impression of either comfort or crisis.

Who can reach the plant, and on whose authority?

For most UK organisations the largest realistic OT exposure is not a hostile actor plotting a bespoke attack on a control system. It is a third party with legitimate, standing access: the original equipment manufacturer supporting a line, the systems integrator that built the plant, the maintenance contractor that dials in when a bearing fails at two in the morning.

Boards should insist on a plain inventory of every remote path into an OT environment, however it is described. That means the always-on vendor connections established years ago against a contract that has since expired, the shared local administrator account known to a departed contractor, and the support laptop that lives in a drawer at the supplier's office.

Useful questions are deceptively simple. Which organisation authorises a remote session, and how quickly can it be refused? Is access time-boxed and logged, or does it sit open indefinitely? Are sessions brokered through a controlled jump host, or does a supplier connect directly to an engineering workstation? Who notifies the OT lead when a session begins? And what happens on the day a contract ends — is the account revoked as a scheduled step, or does it linger?

A defensible position is rarely secured by technology alone. It rests on a register, a contractual right to audit and revoke, and a named individual in engineering who owns the relationship.

The legacy estate as a governance question

Directors are sometimes told that a control system cannot be patched, and are invited to accept that as a fact of life. It is more accurate to say that the risk has been accepted without being formally recorded, or that compensating controls have never been tested.

Where patching is genuinely constrained, the expectation should be segmentation built to a recognised standard — the zones and conduits model set out in IEC 62443 is the common reference — supported by monitoring that can see inside the OT network rather than only at its perimeter. That requires passive sensing, because active scanning can unsettle fragile devices, and it requires people who can interpret what the sensors report.

The board's role is not to select the architecture. It is to ensure the compensating controls are documented, owned, funded and reviewed, and that the residual risk is carried knowingly rather than by default. The National Cyber Security Centre's guidance and its Cyber Assessment Framework give the public and regulated sectors a vocabulary for this; private operators can borrow it usefully.

Rehearsing the manual fallback

A question that rarely appears in a cyber paper but consistently reveals maturity is this: if the control system were unavailable for a shift, could the operation continue in a reduced, manual mode? Who holds the skills, where are the paper procedures, and when were they last exercised?

Many sites discover during an incident that the expertise to run manually retired several years ago, or that the fallback procedure exists only in a document nobody has opened since commissioning. Tabletop exercises that involve only the IT function and the executive team will not surface this. The exercise must include plant managers, shift supervisors and maintenance engineers, and it should test the awkward interface between a cyber incident response plan and a safety case.

Regulation, insurance and the paper trail

Obligations are converging on the same assets. Operators designated under the Network and Information Systems Regulations 2018 in the energy, water, transport, health and digital infrastructure sectors already report to a competent authority, and those expectations are tightening. Where OT affects safety, the Health and Safety Executive's view of the process will not be confined to mechanical failure. Owners of higher-risk buildings must also consider building management systems under safety management duties. Alongside this, cyber insurers have become noticeably more precise about physical consequence and business interruption arising from control systems, and a renewal submission that mischaracterises OT exposure is an avoidable argument at the point of claim.

Questions for the next board meeting

• Which of our operations cannot run without a control system, and what is the documented recovery time for each?
• Who can reach those environments remotely, authorised by whom, logged where, and revoked how?
• Where patching is not possible, what compensating controls are in place and who owns them?
• When did we last exercise a manual fallback, and who attended?
• Does our incident response plan distinguish clearly between an IT outage and a safety event?
• Does our cyber insurance wording contemplate physical consequence, and have we described our OT estate accurately to underwriters?

The point is not to treat OT as an ungovernable exception. It is to govern it on its own terms — where the measure of a good day is a line that keeps running, a process that stays within its limits, and a workforce that goes home unharmed.