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.
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.