Frameworks, standards and cyber security controls all play an important role in protecting operational technology (OT) environments. They provide structure, establish common expectations and help organisations improve their security maturity over time.
Yet across the water, energy, resources, transport and manufacturing sectors, we continue to see a common challenge. Organisations can invest significant effort into implementing controls and still struggle to answer a deceptively simple question:
What must continue operating when something goes wrong?
It is a question that sits at the intersection of cyber security, engineering, operations and risk management. More importantly, it is often the question that determines whether a security program delivers meaningful resilience or simply achieves compliance.
The distinction matters because operational environments are different. Unlike traditional enterprise technology, OT systems are directly connected to the processes that keep facilities running, products moving, services flowing and communities supplied. The consequences of disruption are often measured not just in downtime, but in safety impacts, operational losses, environmental and public confidence.
In our experience, the most resilient organisations are not necessarily the ones implementing the greatest number of controls. They are the organisations that have developed a clear understanding of their operational priorities, their critical dependencies and the outcomes they need to protect.
Much of the advice available to organisations today is framed around actions that should be considered.
Improve network segmentation
Strengthen remote access controls
Review supplier risk
Increase monitoring and visibility
These are all worthwhile initiatives, and in many environments they are necessary. However, the effectiveness of any control ultimately depends on the outcome it is intended to achieve.
Engineering teams are exceptionally good at solving complex problems when objectives are clearly defined. The challenge is often not implementing the solution. The challenge is understanding what success looks like.
For an OT environment, success is rarely measured by compliance alone. It is measured by the ability to maintain safe and reliable operations despite changing conditions, operational pressures and an increasingly complex threat landscape. That shifts the conversation.
Rather than asking which controls should be deployed, organisations begin asking:
Which systems are most critical?
Which functions must remain available during an incident?
How long disruption can be tolerated?
And what evidence exists to demonstrate that assumptions are correct?
Those answers differ significantly between industries, facilities and even assets within the same organisation. That is why resilience cannot be outsourced to a framework. It has to be engineered into the environment itself.
One of the most powerful shifts organisations can make is moving from thinking about threat categories to thinking about threat objectives.
Consider two scenarios.
A ransomware group disrupts an operational network. Separately, a sophisticated state-sponsored actor causes a similar operational disruption.
At first glance, the outcomes may appear identical. Systems become unavailable, operations are affected and recovery activities commence.
However, the intent behind those events can be fundamentally different.
For a criminal group, the disruption may be the primary objective. The outage creates leverage to support a financial outcome. Recovery capability becomes the most important consideration.
For a sophisticated adversary, the disruption may be only one part of a broader objective. It could be a distraction, a capability test or a means of diverting attention from activity occurring elsewhere in the environment.
The distinction is important because it influences the way systems are designed, monitored and operated. An organisation focused solely on restoring services may overlook the need to maintain visibility during a major incident. Equally, an organisation focused only on prevention may not invest sufficiently in recovery and continuity capabilities.
Understanding what an adversary is trying to achieve helps organisations prioritise the safeguards most likely to deliver meaningful protection.
Many cyber security practices originated within enterprise IT environments. Those environments evolved around relatively short technology lifecycles, regular software updates and a degree of operational flexibility that allows systems to be changed, patched or replaced relatively quickly.
Operational technology evolved under a different set of assumptions.
Industrial systems are designed to run for decades. Availability, reliability and safety are often prioritised above feature velocity. New technologies are layered onto existing infrastructure, integrations accumulate over time and operational requirements frequently limit how quickly change can be introduced.
The result is an environment where resilience cannot rely solely on the ability to patch or replace technology.
Instead, resilience is often built through architecture, segmentation, monitoring, operational discipline, governance and an intimate understanding of how systems interact.
This is one of the reasons why security conversations in OT frequently extend beyond traditional cyber security teams. Decisions about security are often inseparable from decisions about engineering, operations, maintenance, safety and risk.
The most successful organisations recognise this early and approach cyber security as a systems engineering challenge rather than purely a technology challenge.
While every environment is different, common themes emerge when working across critical infrastructure and industrial sectors.
Perhaps the most consistent observation is that significant risks often stem from dependencies that are either poorly understood, undocumented or assumed to operate differently than they actually do.
In one water utility environment, resilience planning assumed operators could continue operating treatment and pumping systems manually during a communications outage.
On paper, the strategy appeared sound. Manual operation was possible and the organisation had established clear procedures to support continuity.
When the environment was assessed more closely, however, an important dependency emerged. Operators could continue running the plant, but visibility of reservoir levels relied on a telemetry pathway that had been assumed to remain available.
The challenge was not whether the plant could operate. It was whether operators would retain access to the information required to make informed decisions while operating under degraded conditions.
The lesson extended beyond technology. It highlighted the importance of understanding not only critical assets, but also the information flows that support operational decision-making.
Energy environments often present a different kind of complexity.
Many industrial devices communicate only when operating conditions change. Long periods of little or no activity are completely normal and may indicate that systems are performing exactly as intended.
The challenge is determining whether an absence of activity reflects a healthy system or a failed communications pathway.
In one distributed energy environment, monitoring strategies had to be redesigned around expected reporting behaviours rather than event volume. Only then could operators confidently distinguish between normal operations and potential failures.
The discussion reinforced an important point. Effective monitoring is not simply about collecting more data. It is about understanding which signals genuinely indicate risk within a specific operating context.
Transport infrastructure projects often demonstrate the value of integrating security considerations throughout the engineering lifecycle.
In one project, factory acceptance testing identified a management network that was designed to remain isolated but had been configured with a pathway back into the corporate environment to support time synchronisation services.
The issue itself was relatively straightforward to address. More importantly, it was identified before commissioning.
Had the same dependency been discovered after deployment, remediation would have been considerably more disruptive and expensive.
The experience highlighted the benefits of treating cyber security as a design and assurance activity rather than a final-stage compliance exercise.
Mining and resources environments frequently operate with decades of accumulated modifications, upgrades and integrations. These environments often contain extraordinary operational knowledge, but they can also inherit assumptions that are no longer reflected in documentation.
During a network segmentation program, testing identified a historian system that had been classified as read-only. Further investigation revealed that an associated reporting application maintained a write path that had not been documented.
The dependency was discovered during testing rather than during production operations. That distinction matters.
Known vulnerabilities can generally be planned for and managed. Undocumented dependencies often reveal themselves at the worst possible time, particularly when environments are being modified or responding to incidents.
Across many industrial environments, understanding these hidden relationships delivers some of the greatest gains in resilience.
When cyber security investments are discussed, attention naturally gravitates toward technology solutions. Firewalls, monitoring platforms, identity systems, detection tools and network controls all have an important role to play.
Yet technology represents only one layer of resilience.
Across industrial environments, long-term security outcomes are equally influenced by:
Operational processes
Maintenance practices
Workforce capability
Governance structures
And risk management disciplines
Technology is visible. The supporting foundations are often less obvious.
We have seen organisations invest heavily in advanced capabilities yet struggle to realise their value because ownership, operational procedures or sustainment models were never fully established. We have also seen organisations achieve significant improvements through relatively modest technology investments supported by strong operational discipline and clear accountability.
The lesson is not that technology is less important. Rather, technology is most effective when it forms part of a broader system designed to support operational outcomes.
Standards, frameworks and industry guidance remain essential components of any security program. They provide valuable foundations and help organisations benchmark progress against recognised practices.
However, resilience requires a deeper understanding of the environment being protected.
It requires organisations to understand which outcomes matter most, what dependencies exist, which assumptions are being made and how those assumptions can be tested before they are challenged by real-world events.
Across water, energy, transport, resources and manufacturing sectors, the strongest security programs are increasingly those that bring cyber security, engineering and operational thinking together.
Because operational resilience is not ultimately measured by the number of controls deployed. It is measured by an organisation's ability to continue delivering safe, reliable and critical services when conditions are at their most demanding.
And that begins with understanding not only how systems are protected, but what those systems must continue to do when it matters most.