Railway hazard log best practice

Why the hazard log matters

Under EN 50126, the hazard log is the central record of every identified hazard, its assessment, the measures taken to control it, and its current status. It is the thread that connects hazard analysis to safety requirements, safety requirements to design and test evidence, and all of that to the safety case. When an assessor wants to know whether a project is safe, the hazard log is usually where they start.

A weak hazard log is one of the most common reasons safety cases stall. The usual symptoms are hundreds of loosely worded entries, unclear ownership, and "closed" hazards with no evidence behind them.

Get the definitions right first

Many hazard log problems start with mixing up three different things:

• Cause: what could lead to the hazard, for example a failed track circuit or an incorrect data entry.
• Hazard: a condition that could lead to an accident, for example "train enters an occupied section".
• Accident (consequence): the harmful outcome, for example a collision.

Record hazards at the system boundary you are responsible for, and capture causes and consequences as linked attributes rather than as separate hazards. This keeps the log to a manageable size and makes risk assessment consistent.

Fields to record

A simple status workflow

Use a small number of statuses, each with written entry criteria, and make sure everyone applies them the same way. One workable set:

1. Open: identified and recorded, not yet fully assessed.
2. Assessed: causes, consequences and initial risk agreed; controls being defined.
3. Controlled: controls defined and traced to safety requirements; verification pending.
4. Closed: every control verified with evidence, residual risk accepted by the authorised person.
5. Transferred: responsibility formally accepted by another party, with a reference to their record.

The test for "Closed" should be strict: a proposed mitigation, a design intent or a statement in a meeting is not closure. If the evidence cannot be pointed to, the hazard is not closed.

Managing hazards at interfaces

On multi-contractor rail projects, hazards most often fall through the gaps between systems: rolling stock and signalling, platform and train, civil works and operations. Good practice includes:

• An interface hazard analysis for each significant interface, with both parties participating.
• A formal transfer process, where the receiving party acknowledges each exported hazard in writing.
• Regular cross-contractor hazard reviews chaired by the system integrator or client.
• Operational and maintenance hazards transferred to the operator and maintainer at handover, with the controls they must maintain.

Keeping the log healthy

• Review on a cadence. Hold a hazard review at each design stage and before every lifecycle gate, not just before the safety case is due.
• Control changes. Treat the hazard log as a configuration-controlled record, with a change history for each entry.
• Trace both ways. From hazard to requirement to evidence, and back again. Orphaned requirements and untraced controls are both red flags.
• Avoid duplicates. Merge hazards that describe the same condition; keep a reference from the retired ID.
• Use the right tool. Spreadsheets work for small systems, but cross-linked tools make traceability between hazards, analyses and requirements far easier to maintain on larger projects.

What an assessor will check

Expect an independent safety assessor to sample hazards and follow them end to end: is the hazard credible and well described, is the risk assessment consistent with the project method, does each control trace to a requirement, is there evidence the requirement is met, and did someone with authority accept the residual risk? A hazard log built around those questions from day one makes the safety case far easier to write.