How to Build a Rail Threat Intelligence Programme: A Practical Roadmap

Key takeaways:

• The NIS Regulations and NCSC's Cyber Assessment Framework are the primary regulatory reference points for UK rail operators, with the Cyber Security and Resilience Bill set to extend that framework further into the supply chain.

• Intelligence requirements should be defined before any source or service is selected: which systems matter most, who the relevant threat actors are given an organisation’s position in a fragmented ownership structure, and what decisions the programme needs to support.

• Most rail operators cannot build comprehensive dark web, technical, and geopolitical intelligence coverage in-house, particularly coverage scoped to rail-specific OT vendors and suppliers rather than generic IT threats. This is why managed intelligence services remain amore practical option for most of the sector.

• Intelligence only creates value when it reaches the people who need to act on it. It should be translated into terms both cybersecurity and engineering teams can use, and prioritised by exploitability rather than severity score alone.

• Governance and measurement, not just collection, are what separate mature intelligence programmes from ones that stall.

Part one of this series set out why rail cybersecurity investment is accelerating. Part two looked at why generic threat intelligence falls short in a rail environment, given safety constrained response options, legacy protocols like GSM-R that sit outside standard monitoring, a supply chain that spans Network Rail, operators, and suppliers, and a shortage of people who understand both cybersecurity and rail operations. This final instalment answers the question security leaders ask most: where do we actually start building the intelligence capability part two argued this sector needs?

Start With Regulation, Not Tooling

UK rail operators already sit inside a defined regulatory structure. Rail transport is classed as a critical service under the NIS Regulations, with the Department for Transport acting as competent authority and the NCSC's Cyber Assessment Framework used to evaluate whether an operator is doing enough. The Cyber Security and Resilience Bill will put that framework on a statutory footing and extend scope further into the supply chain. Operators with cross-border exposure should also be aware of the EU's NIS2 Directive, which classes rail among the "highly critical sectors" and introduces its own 24-hour early warning, 72-hour incident report, and one-month final report obligations for essential entities. UK-based operators should treat the CAF as their primary reference point rather than NIS2. Alongside these, TS 50701 is a CENELEC technical specification setting out a lifecycle-based approach to cybersecurity in railway applications. It is increasingly being used by vendors and operators as the engineering-level route to meeting CAF's OT-related outcomes.

None of these frameworks tell organisations exactly what to buy. What they do is force a structured answer to the question of what needs protecting, to what standard, and how quickly an incident needs to be reported once discovered.

Step 1: Define What You Need Intelligence to Answer

Before evaluating any tool or service, rail security leaders need clear answers to a few questions. If compromised, which systems would cause the greatest operational or safety harm? Which threat actors are most relevant to your geography and ownership structure? The UK rail's split across Network Rail, train and freight operating companies, and rolling stock leasing companies means the answer is rarely the same for two organisations. What third parties have access to systems, and how well is that access actually understood? These are theintelligence requirements which determine what a programme needs to be watching for before a single source is switched on.

Step 2: Build Intelligence Coverage Across the Right Sources

This is the core of a rail-specific intelligence programme, and it is where most generic approaches fail. As part two set out, standard intelligence coverage is built around enterprise IT and misses much of what actually matters in rail. A rail-specific programme needs to cover five types of sources:

• Open web and specialist rail media, for incident and vulnerability reporting relevant to the sector rather than IT generally.

• The dark web and criminal forums, scoped to the specific OT vendors, signalling systems, and legacy protocols an operator actually runs, rather than a generic sweep for its name.

• Technical and vulnerability feeds, tracking the specific signalling and OT vendors in an operator's environment, not just common enterprise software.

• Supplier and contractor monitoring, extended to named third parties, given that UK rail's biggest recent incident originated at a supplier rather than the operator itself.

• Geopolitical monitoring, since state-aligned threat actors have repeatedly shown interest in transport infrastructure for pre-positioning and intelligence-gathering purposes.

Covering all five properly, and knowing which of them actually matters for a given operator's specific systems and suppliers, is a specialist, continuous undertaking. It is precisely why most rail operators use a managed intelligence service rather than attempting to build this coverage from scratch.

Step 3: Get Intelligence Into the Hands That Need It

A quarterly PDF report has limited value if it sits unread. Effective programmes push indicators of compromise into whatever detection and response tools an operator already runs. They also use threat actor profiles to tell engineering and security teams which groups are actually likely to target their organisation and prioritise vulnerability patching by active exploitation rather than relying on CVSS scores alone. That last point matters more in rail than most sectors. As part two covered, a safety critical system often cannot be patched the moment a vulnerability is disclosed. This means that intelligence needs to help judge whether a flaw is being actively exploited elsewhere and worth an out-of-cycle intervention, rather than simply ranking severity. Intelligence should also feed directly into incident response playbooks, which should be built around the scenarios most relevant to an organisation's specific threat landscape.

Step 4: Govern the Intelligence Function

Threat intelligence touches security operations, OT engineering, procurement, legal, and the board, and it needs governance built around that reach. The practical mechanisms that keep intelligence moving to the people who need to act on it, rather than sitting in an inbox, are:

• A monthly intelligence review with security and operational stakeholders.

• A defined escalation path for urgent findings.

• Regular board-level reporting on threat exposure.

• A formal process for feeding intelligence into vendor and supplier risk assessments.

This is also where the expertise gap from part two has to be actively managed. Specifically, governance should ensure that intelligence reaching engineering and operational teams has already been translated into rail-specific terms.

Step 5: Measure and Mature the Intelligence Function

Track the mean time to detect and respond, and whether intelligence inputs measurably reduced those figures. Track how many vulnerabilities were identified ahead of public disclosure through intelligence rather than after the fact. Ask security operations, engineering, and leadership directly whether the intelligence they receive is timely and useful. Programmes that skip measurement tend to stagnate at whatever maturity level they started.

Where CYJAX Fits

Across this series, the picture has been consistent. Part one showed that investment and threat activity are both rising and that UK rail is not exempt from either. Part two showed why generic threat intelligence routinely misses what actually matters in this sector, from safety -constrained response to a supply chain that extends beyond the operator's own network. This roadmap is the answer to both: a structured way to close that gap.

CYJAX works with rail and transport operators to deliver exactly this kind of programme: continuous monitoring of dark web forums and criminal marketplaces for mentions of your organisation and named suppliers. CYJAX also provides finished intelligence tailored to OT and ICS environments, which has been interpreted by analysts who understand rail's operational constraints. Our threat actor profiles are updated as tactics evolve, and direct analyst access is available for urgent questions. Whether your organisation is defining its first set of intelligence requirements or looking to mature an existing capability, the goal across all three parts of this series has been the same: turning threat data into decisions, made faster, by the people who need to make them.

Get in touch to speak with a CYJAX analyst about your rail security requirements, or revisit part one and part two of this series.