Where process safety and cyber risk start to blur
There’s a common assumption in COMAH environments that if the safety case is in good shape, the risk is understood and under control. The documentation is there, the systems are defined, the safeguards are in place.
That assumption made more sense when control was largely mechanical or procedural. It’s not how most sites operate now.
The day-to-day running of many facilities depends on digital control environments. Platforms such as SCADA and Distributed Control System sit at the centre of how processes are monitored, adjusted, and shut down. If those systems don’t behave as expected, through failure, misconfiguration, or interference, the safety case may no longer reflect reality.
COMAH focuses on outcomes, not causes
The Control of Major Accident Hazards Regulations 2015 doesn’t call out cyber explicitly, and it doesn’t need to. Its concern is with major accident hazards and the measures in place to prevent them. How something fails matters less than what that failure leads to.
If a loss of control, loss of containment, or failure of a safety function is possible, it’s in scope.
Where things drift is in how those failure paths are considered. In some organisations, cyber risk still sits slightly to one side. IT and Operational Technology (OT) are treated as different domains, managed by different teams with different priorities. Safety sits elsewhere again and none of that is unusual, but it makes it easier for certain scenarios to fall between the gaps, not because they’re unlikely, but because they don’t belong neatly to anyone.
How problems actually show up in control environments
You don’t need to stretch far to see how this plays out… Operators rely on the information in front of them. If sensor data is wrong (subtly, not obviously), the process can look stable when it isn’t. Decisions get made on that basis. From the outside, it doesn’t look like a cyber issue. It looks like normal operation, just slightly off.
Safety systems are often treated as the backstop. They’re designed to act independently, to intervene when things move outside safe limits. That independence is the whole point. In some environments, it can be reduced in practice. Integration, shared infrastructure, and remote access each add a degree of coupling that isn’t always visible or intentional, but enough to raise questions about how independent those systems really are.
Access is another consideration. Remote connectivity is part of how these environments are supported now. Vendors need it, engineers need it, operations often depend on it. But it creates a pathway into control environments that were never designed to be reached that way. If that access is loosely controlled or poorly understood, it introduces a direct route to safety-critical systems.
None of this usually appears as a single, obvious weakness, rather, accumulating.
Small decisions, cumulative impact
A change to support a new integration. A tweak to allow remote support. An adjustment to improve visibility. Each decision is reasonable in isolation. Over time, they reshape how the environment actually behaves.The difficulty is that safety thinking often captures the system at a point in time, while the system itself keeps moving. The gap between the two isn’t always apparent until something forces a closer look.
This is where COMAH expectations and the reality of modern control environments begin to meet. Regulators such as the Health and Safety Executive and the Environment Agency are looking for confidence that control measures are effective and reliable. That expectation doesn’t change because those controls are digital. If anything, it becomes harder to demonstrate.
The Network and Information Systems Regulations 2018 bring a more explicit focus on cyber resilience for certain operators. Different starting point, similar destination. The underlying question is the same: can the organisation maintain control when the systems it depends on are under stress?
Looking at cyber through a safety lens
For many organisations, the answer sits somewhere between confidence and assumption (and that’s understandable). It’s not the same as being able to evidence it, however.
This is where framing matters as treating cyber as a separate set of controls only goes so far. In a COMAH context, it needs to sit within the same safety thinking, not alongside it, but integrated into the same risk picture. That in turn, shifts the conversation.
Less about whether networks are segmented, and more about whether that segmentation genuinely protects safety functions. Less about who has access, and more about what that access can influence. Less about whether systems are monitored, and more about whether abnormal behaviour would be recognised quickly enough to act.
These aren’t new questions. They’re being asked of systems that behave differently to the ones COMAH was written around.
Control still matters. The context has changed.
The principles are already there. Identify the hazards, understand how they could materialise, put measures in place to prevent them.
What’s changed is the environment those principles are being applied to. Control systems are more connected, more frequently updated, and more dependent on external support and integration than they were when many safety cases were first written. All of that introduces new ways for things to go wrong, even when the underlying process hasn’t changed.
The question isn’t whether cyber security formally belongs inside COMAH but whether your safety case reflects how your system actually operates today. And, if it doesn’t, the gap is the risk.
Related Links:
