DCB0129 and DCB0160 Explained for Digital Health Suppliers

If you sell software into the NHS, DCB0129 is one of the first acronyms a buyer will raise, usually alongside DTAC, DSPT and Cyber Essentials. It is easy to lump these together, but DCB0129 and its partner standard DCB0160 are a distinct discipline: clinical safety, not cyber security. This guide explains what each standard covers, the Clinical Safety Officer role, the hazard log and clinical safety case, how they sit inside NHS DTAC, and the line between clinical-safety governance and the technical-security evidence (penetration testing and Cyber Essentials) that we deliver.

DCB0129 and DCB0160 explained in plain English

DCB0129 and DCB0160 are two halves of the same idea: making sure health IT does not harm patients. Both are NHS information standards requiring a structured clinical risk management process rather than a one-off sign-off. The split is about who is responsible: DCB0129 governs the manufacturer building the software, DCB0160 governs the NHS organisation putting it into a live care pathway, and the two interlock so the manufacturer’s hazards feed the deploying organisation’s assessment.

DCB0129: the standard for manufacturers

DCB0129 is clinical risk management for the manufacture of health IT systems. If your organisation builds or maintains software that NHS clinicians or patients rely on, this is your standard. It asks you to operate a clinical risk management system: a defined process for spotting clinical hazards, judging how likely and serious each is, reducing the risk where you can, and recording all of it. The deliverables are a clinical risk management plan, a hazard log and a clinical safety case report. None are security documents. They are about clinical outcomes: what happens to a patient if the software shows the wrong dose, hides an alert, or displays one patient’s record under another patient’s name.

DCB0160: the standard for deploying organisations

DCB0160 is clinical risk management for the deployment of health IT systems. It applies to the NHS body that takes a finished product and embeds it into how care is delivered. Deployment introduces its own hazards the manufacturer could not foresee: how the software fits local workflows, how staff are trained, how it connects to other systems on site, and what happens during downtime. The deploying organisation runs its own risk management process, hazard log and clinical safety case for that setting. As a supplier you are not responsible for DCB0160, but you will be asked to support it, because your hazard log is a primary input to its assessment.

	DCB0129	DCB0160
Applies to	The manufacturer building the product	The NHS organisation deploying it
Typical owner	Digital health supplier or vendor	NHS Trust, ICB, GP practice, care provider
Core output	Risk management plan, hazard log, clinical safety case for the product	Local hazard log and clinical safety case for the deployment
Named role	Clinical Safety Officer (supplier)	Clinical Safety Officer (deploying)
Focus	Hazards arising from the software	Hazards arising from how it is used in care

The Clinical Safety Officer role

Both standards require a named Clinical Safety Officer (CSO): a suitably qualified, currently registered clinician who owns the clinical risk management system. Under DCB0129 the supplier’s CSO signs off the clinical safety case and is accountable for the hazard log; under DCB0160 a separate CSO does the same for the live deployment. The role is deliberately clinical, because the judgements involved, such as whether a software behaviour could plausibly harm a patient and how severe that harm might be, are clinical judgements, not engineering ones.

The hazard log and clinical safety case

The two documents at the heart of DCB0129 are the hazard log and the clinical safety case. They are produced by clinical safety specialists, not penetration testers, but it helps to know what they contain, because they sit next to your security evidence in any NHS procurement pack.

• The hazard log. A living register of every clinical hazard the product could introduce, each with an initial risk rating, the controls applied, and a residual rating. It is updated across the lifecycle, not signed once and shelved.
• The clinical risk management plan. Sets out how you run clinical risk management for the product: who is involved, the CSO, the process, and how hazards are identified and reviewed.
• The clinical safety case report. The structured argument, supported by the hazard log, that the product is acceptably safe for its intended use. The CSO owns and signs this.

A useful way to see the boundary is to take one failure and ask two questions. Take a broken access control that lets one authenticated user reach another patient’s record. The technical-security question is how the flaw exists and how to remediate it, which a penetration test answers. The clinical-safety question is what harm reaches a patient if that record is wrong or missing, which the hazard log and clinical safety case answer.

How DCB0129 and DCB0160 sit inside DTAC

The Digital Technology Assessment Criteria (DTAC) is the NHS England framework that buyers apply to a software product before they buy or deploy it. DTAC is required in practice to sell to the NHS rather than being a statutory legal mandate, but in reality it is a near-universal procurement gate. It has five sections, and DCB0129 and DCB0160 live in the first one.

• 1. Clinical safety: evidenced through DCB0129 and DCB0160, namely a clinical risk management system, a named CSO, a hazard log and a clinical safety case.
• 2. Data protection: UK GDPR, a Data Protection Impact Assessment, and links to the DSPT.
• 3. Technical security: Cyber Essentials, Cyber Essentials Plus, penetration testing, ISO 27001, vulnerability management and MFA. This is where our work sits.
• 4. Interoperability: exchanging data using recognised NHS and health standards.
• 5. Usability and accessibility: alignment to NHS service standards and accessibility.

So clinical safety (section 1) and technical security (section 3) are distinct sections of the same form. The clinical-safety section needs your hazard log, clinical safety case and CSO. The technical-security section needs your current Cyber Essentials certificate, ideally Cyber Essentials Plus for business-critical systems, and recent penetration-test evidence on the live product.

For a deeper walk-through of section 3, and whether you need Cyber Essentials, Cyber Essentials Plus or a penetration test, see our guide to DTAC technical security requirements. If you also complete the Data Security and Protection Toolkit, our explainer on the CAF-aligned DSPT for NHS suppliers covers the annual testing the framework now expects.

Where clinical safety ends and technical security begins

To be clear about our remit: we do not author DCB0129 or DCB0160 documentation, act as your Clinical Safety Officer, or write clinical safety cases; engage a clinical safety specialist for that. What we deliver is the technical-security evidence that sits alongside it, and the two halves complement each other. A penetration test we run on a digital health platform routinely surfaces issues with real clinical-safety relevance, for example broken access controls between patient records, weak session handling, or flaws in how clinical data is validated on input. We document these as security findings, mapped to the OWASP Top 10 and scored with CVSS, with clear remediation and a retest, so your clinical safety team can reference any finding with a patient-safety consequence in the hazard log.

Why EJN Labs for DTAC technical security

For the clinical-safety half of DTAC you need a Clinical Safety Officer and a clinical safety specialist, and we will point you toward that. For the technical-security half, we are built for this work. EJN Labs is a CREST member for penetration testing, the quality signal NHS buyers and DTAC assessors recognise, and a Cyber Essentials and Cyber Essentials Plus certification body through our IASME relationship, so we can certify and test you from one team. We are also ISO 27001 and ISO 9001 certified, so we run our own engagements to an audited standard.

That matters because DTAC’s section 3 asks for two things that usually come from two vendors, a valid Cyber Essentials certificate and recent penetration-test evidence on the live product, and we cover both in a single engagement. Our testing is delivered by UK-based senior and principal testers, who scope against your real architecture, map findings to the OWASP Top 10, score them with CVSS, and retest to confirm closure. We work day to day with NHS and health-tech suppliers. Pricing is scope-driven, quoted on tester days at a flat UK day rate of around £1,200, so a focused product test of roughly four to six days lands at about £4,800 to £7,200 and a broader assessment scales from there. See our healthcare penetration testing page, or, if your driver is the Data Security and Protection Toolkit, our DSPT penetration testing page.

Frequently Asked Questions

What is the difference between DCB0129 and DCB0160?

DCB0129 is the NHS clinical risk management standard for the manufacturer that builds a health IT product, covering its clinical risk management plan, hazard log and clinical safety case. DCB0160 is the equivalent for the NHS organisation that deploys and uses the product, covering hazards from how it is used in a real care setting. As a supplier you work to DCB0129; the deploying Trust or ICB works to DCB0160.

Do I need a Clinical Safety Officer for DCB0129?

Yes. DCB0129 requires a named Clinical Safety Officer, a suitably qualified, currently registered clinician who owns the clinical risk management system, hazard log and clinical safety case. Under DTAC version 2 the CSO no longer has to complete the old NHS Digital-provided training, but the role remains mandatory and must be held by a clinician, not an engineer.

How do DCB0129 and DCB0160 fit into NHS DTAC?

DCB0129 and DCB0160 underpin the first of DTAC’s five sections, clinical safety. The others are data protection, technical security, interoperability, and usability and accessibility. Clinical safety and technical security are separate sections answered by different specialists, but an NHS buyer requests both in the same procurement gate, which is why suppliers often treat them as one compliance pack.

Does EJN Labs write clinical safety cases or act as a Clinical Safety Officer?

No. Clinical safety is a separate clinical discipline, so we do not author DCB0129 or DCB0160 documentation, write clinical safety cases or act as your Clinical Safety Officer; engage a clinical safety specialist for that. We deliver the technical-security evidence DTAC also requires: CREST penetration testing and Cyber Essentials or Cyber Essentials Plus certification, which sit alongside your clinical-safety work in the same pack.

What does a DTAC penetration test cost in the UK?

We quote on tester days at a flat UK day rate of around £1,200, so a focused product test of roughly four to six days is about £4,800 to £7,200, with broader multi-component assessments scaling from there. The exact figure depends on your architecture, so we scope first and quote against a written scope. Use our quote form for an accurate, fixed price for your product.

Get a DTAC-ready penetration testing quote

Engage a clinical safety specialist for your DCB0129 and DCB0160 work, and let us handle the technical-security half. Tell us about your product and your DTAC timeline, and we will return a fixed-price quote against a written scope after a short scoping call. Every test is delivered by UK-based senior and principal CREST testers and retested to closure, so the report sits cleanly in your procurement pack.