DCB0129 and DCB0160 are two standards for NHS clinical risk management in health IT. They ask organisations to appoint a Clinical Safety Officer, look at how their software could harm patients, put controls in place, and keep a written record of the risks and what was done about them. DCB 0129 applies to manufacturers. DCB 0160 applies to the organisations that deploy and use the software.
Not every NHS organisation can produce that documentation for every tool it uses. More than 10,000 digital tools used in patient care have no documented clinical safety assurance. A 2025 study covering 14,747 deployments across 178 NHS organisations found that 17.3% of deployments with reported assurance data were fully assured against both standards. In a separate subset of 8,536 deployments, 70.1% had no documented clinical safety assurance.
The standards were introduced in 2009 and last updated in 2018. The current versions are DCB0129 v4.2 and DCB0160 v3.2. NHS England opened a public consultation on 29 June 2026 and closed it on 11 September 2026. The review is looking at whether the standards still fit a world of AI, complex interconnected systems, and modern development practices. The response report is still pending, so the rules you follow today may be revised. If you are a manufacturer, a revised standard could change what you submit for procurement. If you are writing a deployment safety case in a trust, it could change what that case needs to cover. Either way, the version you work to now may not be the version you work to next year.
By the end of this blog, you will know the difference between DCB0129 and DCB0160 in practice. You will also see who each standard applies to, what it asks of you, and how the two fit together.
How Do DCB0129 and DCB0160 Compare?
The table below compares DCB0129 vs. DCB0160 across the main requirements.
| Requirement | DCB 0129 | DCB 0160 |
| Applies to | Manufacturers of health IT systems | Health and care organisations deploying and using health IT systems |
| Main responsibility | Clinical risk management during product development and maintenance | Clinical risk management during deployment, use, maintenance, and decommissioning |
| Clinical Safety Officer | Required | Required |
| Risk assessment | Product-level clinical risk assessment | Assessment of risks in the local care setting |
| Key documentation | Clinical Risk Management Plan, Hazard Log, and Clinical Safety Case Report | Clinical Risk Management Plan, Hazard Log, Clinical Safety Case Report, and Safety Incident Management Log |
Manufacturers build the product and show it is safe. Deploying organisations put it to work in the care setting where it will be used and check that it stays safe there. Both want safe systems, but each has a different job to do.
Meeting DCB 0129 does not satisfy DCB 0160, and meeting DCB 0160 does not cover the manufacturer’s duties. Each standard requires its own Clinical Safety Officer and its own signed safety case. The two standards work together, but one does not replace the other.
What Is DCB 0129?
DCB 0129 sets the clinical risk management rules for anyone who makes health IT systems. If your organisation develops a product used in patient care, this standard applies to you. This could be a software vendor, an in-house development team inside a trust, or a supplier building tools for NHS use.
DCB 0129 also applies to health IT systems that are subject to medical-device regulations. These requirements can apply alongside the relevant medical-device regulatory requirements.
NHS England summarises DCB0129 compliance as three duties:
- Implement proportionate clinical risk management processes.
- Maintain clinical safety documentation.
- Appoint a Clinical Safety Officer throughout the development lifecycle.
A product should be designed with patient safety in mind from day one, not fixed up later. The manufacturer has to show they have thought about what could go wrong and put steps in place to stop harm before the software ever reaches a patient.
Who Needs to Follow DCB 0129?
You are in scope if your organisation develops or manufactures health IT products used in patient care. This includes:
- Software vendors building clinical tools
- In-house development teams inside NHS trusts
- Suppliers producing health IT systems for NHS use
The duty stays with the organisation that builds the product. It does not matter if you are a small team or a large vendor. If your software is a health IT system that can affect patient safety, you carry the safety responsibility for it. Not every piece of software used in the NHS falls within scope, so check the applicability guidance before assuming the standard applies.
When a supplier hosts and operates the system on behalf of a customer, responsibility depends on who developed the product, not who runs the servers. If the supplier built the software, they hold the manufacturer role and produce the DCB 0129 documentation. If the deploying organisation built it, the manufacturer role sits with them. The standard follows the role, not the server. The deploying organisation’s local risk assessment under DCB 0160 always stays with the deploying organisation.
Key Clinical Safety Requirements
DCB 0129 sets five clinical safety requirements for manufacturers.
1. Appoint a Clinical Safety Officer.
You need a named person who owns clinical safety. This is a senior clinician with current professional registration and the authority to make safety decisions. They approve the Clinical Safety Case Report that supports the release decision.
2. Find hazards and assess risk.
Your team has to look at how the software could cause harm. Wrong data shown, a missed alert, a calculation error. Each hazard gets assessed for how likely it is and how bad the outcome could be, using the risk criteria defined in the clinical risk management process.
3. Put controls in place.
Once you know the risks, you build things to stop them. Checks, warnings, limits, whatever fits the hazard. You write down what you did and why, and record the residual risk that remains.
4. Keep a hazard log and clinical safety case report.
The hazard log tracks every risk and what is being done about it, and it stays current as the product changes. The safety case report brings together the evidence that the product is safe for its intended use. Regulators, customers, and your own team work from both documents.
5. Review safety across the product lifecycle.
Safety work runs for as long as the product is in use. Every update, new feature, or fix needs a fresh look at the risks. The CSO reviews designs, test plans, and release decisions along the way.
What Is DCB 0160?
DCB 0160 sets clinical risk management requirements for health and care organisations that deploy and use health IT systems. This includes NHS trusts, GP practices, care providers, and other bodies that put clinical software into service.
A safe product can still become unsafe once it is set up in a particular place, with particular workflows and particular staff. DCB 0160 makes the deploying organisation responsible for that local picture. The standard recognises that risks arise not only from the design of a system but from how and where it is deployed.
These organisations must also consider their data protection and security responsibilities under the NHS Data Security and Protection Toolkit, which helps assess how they protect sensitive information.
Who Needs to Follow DCB 0160?
Any health or care organisation that deploys and uses health IT systems falls within scope. That covers:
- NHS trusts and foundation trusts
- Integrated care boards
- GP practices and primary care networks
- Community and mental health providers
- Social care providers
The legal position has shifted. Since 7 July 2025, section 250(6A) of the Health and Social Care Act 2012 provides that a person to whom an information standard applies must comply with it, unless the requirement is waived. The regulations that brought this into force include a saving provision, so the current DCB0129 and DCB0160 still operate under the older “have regard to” duty for now. If revised standards are published under the new provisions, that saving would not apply to them. A further amendment came into force on 5 February 2026. Section 121 of the Data (Use and Access) Act 2025 expanded the law so that IT providers can also be subject to compliance duties under information standards.
Key Clinical Safety Requirements
DCB 0160 sets five clinical safety requirements for organisations that deploy and use health IT systems.
1. Appoint a Clinical Safety Officer.
You need a named officer with a clinical background who owns safety for the systems you deploy. The officer must be able to make safety decisions on their own judgement. They need enough authority to raise safety concerns, and project deadlines or delivery pressure should not override those decisions.
2. Review the manufacturer’s safety documentation.
Before you go live, read the manufacturer’s Clinical Safety Case Report and Hazard Log. They tell you what risks the manufacturer has handled and what has been left for you to manage locally. If those documents are missing or thin, that is a procurement problem. You cannot assess local risk against a safety case that does not exist.
3. Assess local risks.
How will the system work in your setting? What could go wrong when your staff uses it in your workflows? A product that is safe in one hospital might create risks in another because of how it is configured or how care is delivered there.
4. Look at workflows, training, and intended use.
The system has to fit the way your team works. Staff needs training. The intended use has to match what actually happens on the ground. Each of those factors changes which risks exist locally and how serious they are.
5. Manage risk assessments, incidents, and changes.
Keep your local risk assessments current. Track safety incidents. Review safety again whenever the system changes or your care processes change.
One more responsibility sits with top management. Under DCB 0160, top management must authorise deployment and accept any residual clinical risk on behalf of the organisation. The CSO oversees the clinical risk management process and approves the required safety documentation. These are separate responsibilities. The CSO does not make the final deployment decision on behalf of the organisation.
A manufacturer’s safety case does not cover you. It shows the product is safe in principle. It cannot tell you whether it is safe in your building, with your staff, and your patients. The manufacturer’s DCB0129 work tells you what hazards exist in the product. Your DCB0160 work tells you whether those hazards matter where you are, and what new hazards your local setup introduces.
How Do DCB 0129 and DCB 0160 Work Together?
The difference between DCB0129 and DCB0160 comes down to who carries responsibility at each stage. DCB 0129 covers the manufacturer, and DCB 0160 covers the organisation deploying the system. The manufacturer shows the product itself is safe. The deploying organisation shows it can be used safely in its own setting, with its own workflows and staff. NHS DTAC (Digital Technology Assessment Criteria) also supports this process by assessing digital health technologies against key areas, including clinical safety, data protection, technical security, interoperability, and usability. Each produces its own safety case, and one does not replace the other.
Manufacturer Responsibilities Under DCB 0129
The manufacturer finds and manages product-related hazards. They build controls into the software, keep a hazard log, and produce a clinical safety case report. That report is shared with deploying organisations so they can carry out their own assessment. It sets out the risks found and what has been done about them.
Deploying Organisation Responsibilities Under DCB 0160
The deploying organisation takes that documentation and asks a different question. Can we use this system safely here? They look at local configuration, workflows, staff training, and the patients they serve. Then they document their own risk assessment and keep it current. The deployment hazard log is separate from the manufacturer’s hazard log. It records risks that come from connecting the system to existing systems, staff who are not fully trained on it, network downtime, and the needs of the local patient population.
Practical Example
In November 2025, NHS England issued a safety alert about a mistake that was happening in electronic prescribing systems. Staff were recording a patient’s penicillin allergy as a penicillamine allergy. The two words look and sound similar, which is why the mistake was easy to make. Penicillamine is a different drug used for rheumatoid arthritis and Wilson’s disease, not an antibiotic. A patient with a penicillin allergy recorded as penicillamine could be given penicillin, and the reaction could be fatal. One death had already been linked to the error.
The alert also explained why the software made this mistake easier. In some systems, typing “penicill” into the allergy search box returns penicillamine as the only option, because penicillin is stored as a drug group rather than a drug name. In others, an alphabetical list puts penicillamine above penicillin. Neither of those is a flaw in one specific product. The risk can come from how the system was built, how it was set up locally, and how staff used it.
Take a prescribing system. The manufacturer builds dose-range checks and allergy alerts into the product. They test it, log the hazards, and write a safety case. This is the DCB 0129 work.
A hospital deploys it and makes a series of local choices:
- Configure the dose ranges for their patient groups
- Link the system to their lab systems
- Set their own alert thresholds
Each of those choices can create new risks. Maybe a threshold is set too high for one ward. Maybe the lab link drops data in a way the manufacturer never saw.
The hospital assesses those local risks and puts controls in place. This is the DCB 0160 work. The manufacturer’s work made the product safe. The hospital’s work makes it safe for their patients.
How Qualysec Supports Health IT Security Testing
Qualysec tests health IT systems for security weaknesses that could put patients at risk. The work covers:
- Applications and APIs. Checks your software and the interfaces it relies on.
- Cloud infrastructure and networks. Covers the systems your software runs on, within an agreed scope.
- Remediation and retesting. Helps you understand what was found, fix it, and confirm the fixes work.
The systems Qualysec tests are under more pressure than they were last year. UK healthcare recorded 264,000 intrusion prevention events between January and May 2026, ten times the whole of 2025. These were events recorded by SonicWall’s intrusion prevention system sensors, not confirmed breaches. Two-fifths (41%) of those events targeted Log4Shell, a Java flaw patched five years ago. Some clinical systems built on older Java applications are difficult to patch or replace on a normal schedule because downtime can disrupt patient care. This can leave known vulnerabilities exposed for longer.
A system that goes down, displays incorrect patient data, or allows unauthorised access can create risks to patient safety. Security testing supports your DCB 0129 or DCB 0160 work by assessing vulnerabilities that could contribute to these problems. It does not replace the safety case, the hazard log, or the local risk assessment. It adds evidence about the system’s security alongside its clinical safety assessment.
If you want to talk through scoping a test, get in touch with Qualysec.
Conclusion
The difference between DCB0129 and DCB0160 comes down to who carries the responsibility. Manufacturers own product safety. Deploying organisations own local safety. A product-level safety case is strong evidence, but it does not replace local clinical risk assessment. NHS compliance also involves considering the NHS DTAC, which assesses digital health technologies across clinical safety, data protection, technical security, interoperability, and usability.
If you are building a safety case now, build it against the current versions. The focus groups in the review wanted clinical risk management to stay mandatory. They also flagged AI governance and monitoring after go-live as areas that need work. The wording of the standards may change. The current versions build on the split between product safety and local safety, and your safety case has to reflect that split today.
Have questions about your DCB 0129/0160 security scope or health IT compliance testing? Get in touch with our team to discuss your requirements.
FAQs
1. Who Needs to Comply With DCB 0129?
Any organisation that manufactures or develops health IT systems used in patient care. That covers software vendors, in-house development teams inside trusts, and suppliers building clinical tools for the NHS.
2. Who Needs to Comply With DCB 0160?
Health and care organisations that deploy and use health IT systems. NHS trusts, GP practices, care providers, and similar bodies all carry duties under the standard.
3. Do Both Standards Require a Clinical Safety Officer?
Yes. The manufacturer’s officer owns product safety through development and maintenance. The deploying organisation’s officer owns safety in the local care setting. Neither role can be filled by IT alone. The officer must be a registered health professional with the authority to make clinical safety decisions.
4. Can an Organisation Need to Follow Both DCB 0129 and DCB 0160?
Yes. An NHS trust that builds its own clinical software and also deploys other systems acts in two roles. As developer, it follows DCB 0129 and produces the product safety documentation. As deployer, it follows DCB 0160 and assesses risks in its own setting. Each role is checked separately, and both sets of duties apply.
