A quiet shift in what “secure” means for industrial operators
For most of its history, operational technology sat apart from the conversations happening in the security office. Control systems ran on their own networks, used proprietary protocols, and were maintained by engineers rather than IT teams. The prevailing assumption, rarely stated but widely held, was that isolation was protection enough. An attacker would need physical access, specialist knowledge of obscure control system protocols, and a reason to bother.
That assumption has not aged well. Industrial control systems are now routinely connected to corporate networks for remote monitoring, predictive maintenance, and vendor support. Programmable logic controllers sit on IP networks. Historians feed data to cloud dashboards. The isolation that once justified a relaxed security posture has eroded, often without anyone deciding it should.
At the same time, the threat landscape aimed at OT has matured. Stuxnet demonstrated in 2010 that industrial processes could be manipulated directly through malicious code. The TRISIS attack on a Saudi petrochemical facility in 2017 targeted safety instrumented systems specifically, the layer of protection designed to prevent catastrophic failure. Colonial Pipeline in 2021 showed that an attack on IT systems alone could force the shutdown of physical infrastructure, even without OT systems being touched directly. Each incident narrowed the gap between what security teams worried about in theory and what operators were dealing with in practice.
Why the old playbook does not transfer
Many organisations responded to this shift by extending their IT security programme into the OT environment. On paper this looks efficient: one policy set, one risk register, one team. In practice it tends to create more risk than it removes.
IT security is built around a set of priorities that do not map cleanly onto industrial environments. Confidentiality usually outranks availability in an office network; in a plant, availability and safety outrank almost everything else. Patch cycles that IT teams treat as routine can be disruptive or dangerous on a control system that has not been validated against a new patch and cannot tolerate an unplanned reboot. Endpoint agents that are unremarkable on a laptop can interfere with the real-time behaviour of a programmable logic controller. Vulnerability scanning tools that are safe against IT infrastructure have been known to crash OT devices outright.
None of this means OT security should ignore what IT security has learned. It means the two disciplines need to be treated as related but distinct, with governance structures, risk models, and technical controls designed for the environment they actually protect.
What a structured approach looks like
Organisations that get this right tend to share a few characteristics. They treat OT security as a management system with defined roles, documented processes, and measurable outcomes, not a collection of point solutions bolted onto existing infrastructure. They adopt recognised frameworks, most commonly IEC 62443, rather than inventing their own taxonomy of risk. They build governance down to the level of individual assets and zones, rather than managing risk only at the level of the facility or the organisation as a whole. They move away from annual, spreadsheet-based assessments towards continuous visibility into their environment. And they extend the same standard of scrutiny to the OEMs and third-party service providers who touch their systems, since a well-governed internal environment can still be compromised through a poorly governed supply chain.
Regulatory pressure is catching up
Regulators in the regions OT Associates serves have moved in the same direction. Australia’s Security of Critical Infrastructure Act has broadened both the sectors it covers and the obligations placed on responsible entities, including requirements around risk management programmes and incident reporting for OT-reliant assets. In the Gulf, national frameworks such as the UAE’s information assurance standards and Saudi Arabia’s Essential Cybersecurity Controls increasingly reference OT and industrial control systems explicitly rather than treating them as an afterthought to general IT requirements. Organisations that have already built a structured, standards-aligned OT security programme are finding compliance to be a natural output of good practice. Those that have not are finding it a considerably harder retrofit.
Where this series is heading
This is the first in a series of posts that will look at what a mature OT security programme actually involves in practice. We will cover how to build a Cybersecurity Management System that survives contact with a real production environment, why continuous compliance is replacing the annual audit, how IEC 62443’s zones, conduits, and security levels translate into practical design decisions, and why the differences between protecting a plant and protecting an office network run deeper than most organisations assume. We will also look at governance at the level of individual assets, the limits of spreadsheet-based assessment, and how to hold OEMs and service providers to a consistent security standard.
None of these are abstract concerns. They are the questions that determine whether an OT security programme actually reduces risk or simply produces documentation. The organisations that answer them well are the ones that will be able to operate with confidence as their environments become more connected, not less.
