Put a rail safety engineer and a cyber security manager in a room and ask them to assess the same risk. They will reach different conclusions, and both will be correct within their own discipline. The disagreement is not about the facts. It is about what a risk is.
This matters because rail is now expected to do both, and the two disciplines have incompatible instincts in several places that are easy to miss until they collide.
Two different models of risk
Rail safety thinks in hazards and consequences, assessed against a duty to reduce risk so far as is reasonably practicable. The logic is that you identify what can hurt people, you assess how likely and how severe, and you keep applying controls until the cost of the next control is grossly disproportionate to the safety benefit it buys. The reasoning is documented in a safety case, it is conservative, and it is durable — a safety argument is expected to hold for years.
Cyber risk management thinks in threats, vulnerabilities, and controls, assessed against an adversary who adapts. The logic is that a capable actor is actively looking for the path you did not consider, so controls decay in value as the threat evolves. The reasoning is a current assessment, and it is expected to change.
Neither model is wrong. But note what happens at the seam: ALARP asks “have we done enough?” and expects a stable answer. Cyber asks “what has changed?” and expects an unstable one. A rail organisation that runs cyber risk through its safety governance will tend to close the question too early. One that runs safety risk through its cyber governance will tend to reopen settled arguments without cause.
Where the instincts actively conflict
Change control. Rail safety treats change as the primary source of risk. Modifications are slow, heavily reviewed, and regression-tested against the safety case, for excellent reasons. Cyber security treats unpatched systems as the primary source of risk and wants change to be fast. Both positions are defensible and they point in opposite directions. This is the single sharpest conflict in the sector, and it cannot be resolved by declaring one discipline the winner.
What availability means. In enterprise IT, confidentiality usually leads. In rail, a signalling system that fails safe by stopping trains has protected life and destroyed availability. A cyber control that trips a protective mechanism has caused the outcome it was meant to prevent. Controls have to be assessed against the operational consequence, not the information-security consequence.
Where the risk register lives. Rail organisations already have a mature hazard log with real governance. The temptation is to append cyber hazards to it and consider the job done. The mismatch is that a hazard log entry expects a stable likelihood, and cyber threat likelihood is a function of adversary intent, which does not sit still.
The competence question. A signalling engineer understands the consequence of a failure with a precision no cyber specialist can match. A cyber specialist understands the attack path with a precision no signalling engineer can match. Assessments done by either alone are systematically blind in one direction.
Where AS 7770 fits
AS 7770 exists precisely because this seam needed a bridge. It provides a framework for identifying and managing cyber security risk in rail operations, structured so that it complements safety management rather than competing with it.
The value is less in any individual requirement and more in the fact that it gives both disciplines a shared vocabulary and an agreed place for the conversation to happen. Cyber risk stops being an IT topic that safety governance regards with suspicion, and becomes a category of operational risk with a defined treatment path.
RERA-CYBER covers similar ground from the assurance direction, and organisations working seriously on this generally end up drawing on both.
What actually works
Assess jointly or not at all. The single highest-value change most rail operators can make is to stop running cyber risk assessments and safety assessments as separate exercises with separate attendees. Consequence assessment belongs to the operations and safety people. Attack path assessment belongs to the cyber people. Neither half is useful alone.
Be explicit about the change control trade-off. Do not resolve it by policy statement. Resolve it per system, with a documented rationale. A signalling system and a passenger information display are both in scope and they do not warrant the same answer.
Separate the operational technology estate in your assessments. Enterprise controls do not extend into the operational environment as cleanly as organisational charts suggest. Assess the SCADA and control estate on its own terms.
Use ALARP honestly, including for cyber. The reasonably-practicable test is a good one and it transfers. The discipline it imposes — document what you considered, what you rejected, and why — is exactly what a cyber risk decision usually lacks. What does not transfer is the assumption that the answer stays valid. Date the argument and schedule its review.
Do not let the safety case absorb cyber uncritically. Cyber risk that has been folded into a safety case tends to inherit the safety case’s review cycle, which is far too slow for a threat picture that moves quarterly.
The underlying point
Rail already has something most sectors lack: a genuine, mature, well-governed discipline for reasoning about low-probability high-consequence risk to human life. That is an enormous asset and it should not be discarded for cyber.
But it was built for a world where hazards are physical, causes are analysable, and a well-made argument stays true. An adversary breaks the third assumption. The work is to keep the rigour and drop the assumption of durability — which is harder than adopting either discipline wholesale, and considerably more useful.
Working through cyber risk in a rail environment where safety governance already exists? Get in touch — this seam is most of what we do.