Risk Log vs Hazard Log: What's the Difference?

Why the Terminology Matters

Many health technology companies already maintain a risk log or risk register to manage project and business risks. Then they begin preparing for NHS deployment under DCB0129 and discover they also need a Hazard Log. At this point, projects often stall because the two documents are mistakenly treated as the same thing. Although both deal with "risk", they serve fundamentally different purposes.

A project risk log helps teams manage uncertainties that could affect delivery, budget or operational success. A Hazard Log, on the other hand, documents hazards that could lead to patient harm arising from a health IT system and forms a key part of the clinical safety evidence supporting NHS deployment. Understanding this distinction is important for Clinical Safety Officers, regulatory affairs teams, quality managers and product owners developing health IT systems or Software as a Medical Device (SaMD) for the NHS.

In this guide we'll explain:

• what a Risk Log is;

• what a DCB0129 Hazard Log is;

• how both differ from the ISO 14971 Risk Management File;

• when each document should be used; and

• the common mistakes organisations make when preparing clinical safety documentation.

What is a Risk Log?

A Risk Log (sometimes called a Risk Register) is a general project or organisational management tool used to identify, assess and monitor risks that could affect objectives. Risk logs are common across project management methodologies such as PRINCE2 and wider corporate governance frameworks. Their purpose is to help organisations proactively manage uncertainty rather than patient safety specifically.

Although formats vary, a typical risk log includes columns such as:

• Risk ID

• Risk description

• Risk owner

• Likelihood

• Impact

• Overall risk rating

• Planned mitigation

• Residual risk

• Current status

• Target review date

Many organisations also use related documents including:

• Risk Registers

• RAID Logs (Risks, Assumptions, Issues and Dependencies)

• Risk and Issue Logs

These documents belong to the same family and are often used interchangeably depending on organisational preference. Importantly, a risk log is process agnostic. It does not inherently relate to healthcare, clinical safety or regulatory compliance. For example, a health technology company may use a project risk log to monitor:

• delays from third-party suppliers;

• software integration risks;

• recruitment challenges;

• commercial dependencies;

• budget overruns;

• procurement delays.

These are genuine project risks, but none represent hazards capable of causing direct patient harm. Consequently, they do not belong in a Clinical Safety Hazard Log.

What is a Hazard Log?

A Hazard Log is the principal clinical safety record used throughout the development of a health IT system. It documents hazards associated with the product that could contribute to patient harm, together with the evidence demonstrating those risks have been appropriately assessed and controlled. For organisations developing systems within scope of DCB0129, the Hazard Log forms a core part of the clinical safety documentation supporting NHS deployment. Unlike a project risk register, the Hazard Log focuses exclusively on clinical safety. It records hazards attributable to the software, their causes, the situations in which they may arise, their potential clinical consequences and the controls implemented to reduce risk.

A typical Hazard Log contains information such as:

• Hazard identifier

• Hazard description

• Hazard causes

• Potential clinical harm

• Severity

• Likelihood

• Initial risk rating

• Existing and additional risk control measures

• Justification and evidence

• Residual risk

• Current status

• Owner

The Hazard Log evolves throughout the product lifecycle. New hazards are added, existing risks are reassessed, mitigation measures are updated and verification evidence is maintained as the product changes. The Hazard Log also supports the Clinical Safety Case Report (CSCR) by providing traceable evidence that identified clinical risks have been considered and appropriately managed. Before release, the documentation should be reviewed and approved by the organisation's appointed Clinical Safety Officer (CSO) as part of the wider clinical risk management process.

For NHS deployments, the manufacturer's Hazard Log also supports organisations complying with DCB0160. Deploying organisations use the manufacturer's clinical safety evidence alongside their own local risk assessments when assessing the safe implementation of digital health systems.

Key Differences Between Risk Logs and Hazard Logs

Although both documents refer to "risk", they exist for very different reasons.

Feature	Risk Log / Risk Register	Hazard Log
Primary purpose	Manage project or organisational risks	Manage clinical safety hazards that could lead to patient harm
Regulatory basis	Internal management tool	Clinical safety evidence supporting DCB0129 compliance
Scope	Commercial, operational, technical and delivery risks	Hazards associated with the health IT product
Typical owner	Project Manager, Programme Manager or Risk Lead	Manufacturer through the clinical risk management process
Clinical Safety Officer approval	Not normally required	Forms part of documentation reviewed within the Clinical Safety Case
Lifecycle	Reviewed throughout project delivery	Updated throughout product development, release and post-market maintenance
Evidence value	Internal governance	Supports NHS clinical safety assurance

The important point is that the same word, ‘risk’, describes two entirely different artefacts. A software supplier may legitimately maintain both documents throughout the same project:

• the project risk register helps deliver the project successfully;

• the Hazard Log helps demonstrate that the product is clinically safe.

Neither replaces the other, and both may be required by different stakeholders within the organisation.

How ISO 14971 Fits

For medical device manufacturers, there is a third document that often creates confusion: the ISO 14971 Risk Management File. ISO 14971:2019 is the internationally recognised standard for applying risk management to medical devices, while ISO/TR 24971:2020 provides detailed implementation guidance. Unlike DCB0129, ISO 14971 does not prescribe a document called a Hazard Log. Instead, manufacturers maintain a Risk Management File containing the evidence generated throughout the risk management process.

This typically includes:

• Risk Management Plan

• Hazard analyses

• Risk evaluations

• Risk control measures

• Verification activities

• Residual risk assessments

• Benefit-risk evaluations

• Production and post-production reviews

Much of the information recorded within hazard analysis tables will look very similar to a DCB0129 Hazard Log, but the overall scope is significantly broader. ISO 14971 considers all medical device risks, including:

• biological hazards;

• electrical hazards;

• mechanical hazards;

• software failures;

• usability-related hazards;

• manufacturing defects;

• environmental factors.

By comparison, DCB0129 focuses specifically on clinical risks associated with health IT systems used within NHS care settings. For organisations developing Software as a Medical Device for NHS deployment, both frameworks are often relevant. The good news is that the analyses do not need to be duplicated. A well-structured ISO 14971 Risk Management File frequently provides much of the evidence required to populate the DCB0129 Hazard Log, with additional emphasis placed on clinical workflows, healthcare context and NHS deployment considerations.

Common Mistakes Teams Make

One of the most common mistakes is assuming that an existing project Risk Register can simply be renamed as a Hazard Log. Although this may appear efficient, the two documents answer entirely different questions and are reviewed by different audiences. Another frequent issue is developing clinical safety documentation without appointing an appropriately qualified Clinical Safety Officer. Organisations sometimes attempt to obtain clinical approval shortly before NHS deployment, only to discover that key assumptions, hazards and risk assessments require significant rework. Teams also commonly record isolated hazards without documenting the complete chain between:

• hazard;

• cause;

• clinical harm; and

• implemented controls.

Clinical Safety Officers and reviewers rarely assess hazards in isolation; they examine the reasoning linking each stage together and whether the evidence adequately supports the residual risk. Traceability is another area where organisations struggle. Hazard Log entries should link clearly to design controls, verification activities, clinical safety arguments and the claims presented within the Clinical Safety Case Report.

Finally, some organisations treat the Hazard Log as a one-off deliverable created for procurement purposes. In reality, it is a living document that should evolve alongside the software, reflecting new releases, design changes, clinical incidents, corrective actions and post-market learning. Reusing an unchanged template across multiple product releases rarely provides sufficient assurance.

Frequently Asked Questions

Is a Risk Log the same as a Hazard Log?

No. A Risk Log manages general project or organisational risks, while a Hazard Log records hazards that could contribute to patient harm arising from a health IT system. Although both assess risk, they support different decisions and different audiences.

Does ISO 14971 require a Hazard Log?

Not specifically. ISO 14971 requires manufacturers to maintain a Risk Management File containing hazard analyses and supporting evidence, but it does not prescribe a document called a Hazard Log (although a document similar to the DCB0129 hazard log is frequently created). Many organisations map information between their Risk Management File and DCB0129 clinical safety documentation.

Who approves the Hazard Log under DCB0129?

The Hazard Log forms part of the wider clinical safety documentation overseen by the organisation's appointed Clinical Safety Officer. The CSO provides clinical oversight of the risk management process and contributes to the approval of the Clinical Safety Case Report.

Can one document be both a Risk Log and a Hazard Log?

In most cases, no. While there may be limited overlap, the documents serve different purposes, contain different information and are used by different stakeholders. Attempting to combine them often results in a document that satisfies neither project governance nor clinical safety requirements.

What should a DCB0129 Hazard Log contain?

A typical Hazard Log includes the hazard, its cause, , potential clinical harm, severity, likelihood, risk controls, verification evidence, residual risk and owner. The precise structure varies between organisations but should support a clear, traceable clinical safety argument.

How often should a Hazard Log be updated?

The Hazard Log should be maintained throughout the product lifecycle. It should be reviewed whenever significant design changes occur, before each product release, following safety incidents, during post-market surveillance activities and whenever new clinical risks are identified.

Get Your Clinical Safety Documentation Right

Although they share similar terminology, a Risk Log, Hazard Log and ISO 14971 Risk Management File each serve distinct purposes. Understanding how these documents relate and where they differ is essential for organisations developing health IT systems and Software as a Medical Device for NHS deployment.

At AbedGraham, we help manufacturers build practical clinical safety documentation that aligns DCB0129, DCB0160 and, where applicable, ISO 14971 requirements. Whether you need Clinical Safety Officer support, assistance preparing a Hazard Log or advice on integrating medical device risk management with NHS clinical safety processes, our specialists can help.

Book a discovery call to discuss your clinical safety documentation and NHS compliance requirements.

BOOK A DISCOVERY CALL