Skip to content

Reviewed guide

What does DCB0129 require from a health IT supplier?

Understand the DCB0129 clinical risk management process, CSO role and evidence a health IT manufacturer should maintain.

Assurance AI · Published 30 October 2026

Reviewed by Khalid Anwar on 30 October 2026

DCB0129 is the clinical risk management standard for manufacturers of health IT systems. It requires a managed process for identifying, assessing, controlling and monitoring risks to patients as a product is developed and changed. Compliance is mandatory under the Health and Social Care Act 2012. NHS England publishes the current standard and implementation guidance. It has also started a review of DCB0129 and DCB0160, so check that page for the current release before relying on any summary.

The output is more than a set of documents. A buyer needs to see that the documents describe the system it is actually considering and that clinical risk management influenced product decisions.

Start with intended use

Define the users, patient population, clinical setting, task supported and limits of the product. Include the version and relevant configuration. A vague intended use makes it difficult to judge whether the hazard analysis covers the right risks. Record the applicability decision for the actual product, rather than assuming that all software in a healthcare organisation has the same role.

Build a repeatable process

Set out who can identify hazards, how risk is assessed, which criteria determine acceptability, who approves controls and what triggers a reassessment. The process should cover changes, incidents and monitoring after release. Name a suitably competent Clinical Safety Officer (CSO) with a defined role and authority. NHS England's developer guidance tells software builders to nominate or hire a CSO.

Maintain traceable evidence

The evidence normally includes a clinical risk management plan, hazard log and clinical safety case report. For each significant hazard, a reviewer should be able to trace the clinical scenario to a control, its owner, verification and remaining risk. The safety case should explain how that evidence supports a conclusion for a specified release; our worked report anatomy shows the logic.

The deploying organisation has separate local responsibilities under DCB0160. Supplier assumptions, residual risks and deployment instructions should therefore be clear enough to hand over; our DCB0129 vs DCB0160 guide sets out the split.

Five questions before an NHS buyer asks

  1. Does the safety case name the version and intended use being sold?
  2. Are hazards specific to the actual workflow and patient harm that could follow?
  3. Can every material control be shown to exist and work?
  4. Has the CSO reviewed the evidence within their agreed remit?
  5. Is there a mechanism to reassess risk when the product changes?

If the answer to any is unclear, record the gap and fix the underlying process. A template completed shortly before procurement will be difficult to defend if the evidence behind it is missing.

See our DCB0129 service guide for how Assurance AI supports suppliers, and indicative fees for the scope of that work.

Next step

Need to know what this means for your product?

Tell us what you are building or deploying and we will tell you what, if anything, you need to change in your clinical safety evidence.