What is DCB0129?
DCB0129 ("Clinical Risk Management: its Application in the Manufacture of Health IT Systems") is an information standard issued by NHS England (formerly NHS Digital), applying to manufacturers of health IT systems. Its subject is exclusively patient clinical safety: the risk that the operation or failure of an IT system leads to harm to health, for example through wrong patient identity, a lost test result, a stale allergy record or a medication dose error. It is not a general information security or cybersecurity standard.
Its legal basis is section 250 of the Health and Social Care Act 2012: the Department of Health and Social Care approved DCB0129 for publication as an information standard under that section. Section 250(6A) says that a person to whom an information standard applies must comply with it, except where the requirement to comply is waived. Since 5 February 2026 an information standard can also apply to relevant IT providers, meaning suppliers of information technology or IT services used in connection with health care or adult social care in, or in relation to, England (section 250(2B)(e) and (7)). Version 4.2 of DCB0129 was published in 2018, before that change. In practice a supplier has to demonstrate compliance because the buyer must check it. The twin standard DCB0160 requires a health organisation that buys a health IT system to make sure that the manufacturer and the system comply with DCB0129 (DCB0160, requirement 2.5.1). Buyers ask for it routinely, including in the DTAC (Digital Technology Assessment Criteria) assessment. DCB0160 also places mirror obligations on the health organisations that deploy and use health IT systems.
Who is it for?
DCB0129 applies to manufacturers of health IT systems intended for use in health care in England, regardless of where the company is based. It covers a broad spectrum of software: electronic health records, order communications and e-prescribing, clinical decision support, patient-facing applications, integrations and middleware carrying clinical data, as well as configured platform deployments. If the product creates, processes or presents information that influences patient care, it is in scope.
For companies based outside the United Kingdom, DCB0129 compliance is a condition of entry to the NHS market in England: it appears in procurement requirements, in the DTAC and in due diligence questionnaires. DCB0129 applies to all health IT systems, including those that are also controlled by medical device regulations, so a product can be a medical device and a health IT system under DCB0129 at the same time. The standard states that its requirements are broadly consistent with those of ISO 14971, so one risk management process can serve both. The DCB0129 requirements that ISO 14971 does not have still have to be met: the Clinical Safety Officer, the Hazard Log approved by the Clinical Safety Officer and the Clinical Safety Case Reports.
The Clinical Safety Officer: the key role
The most distinctive DCB0129 requirement is the Clinical Safety Officer (CSO), whom Top Management nominates: the person in the manufacturer's organisation responsible for the clinical safety of the health IT system. The CSO must be a suitably qualified and experienced clinician, hold a current registration with an appropriate professional body relevant to their training and experience, and be knowledgeable in risk management and its application to clinical domains. An engineer or quality manager without clinical qualifications and registration cannot hold this role. Approving the Clinical Risk Management Plan, each hazard log version and each Clinical Safety Case Report is the CSO's responsibility.
The CSO must also make sure that the processes defined by the clinical risk management process are followed (2.3.4). Some companies engage an external clinician as CSO. In every case the CSO takes part in the work, for example in hazard analysis, which the standard says should be carried out by a multi-disciplinary group that includes a CSO (4.1.2).
Key artefacts & requirements
DCB0129 requires a documented clinical risk management process (2.1.1) and the safety documentation set out in section 3 of the standard, maintained throughout the life of the system:
- The Clinical Risk Management File (CRMF): opened at the start of the project and maintained for the life of the system; all formal documents, evidence of compliance and decisions that influence clinical risk management are recorded in it (3.1).
- The Clinical Risk Management Plan (CRMP): produced at the start of the project and approved by the CSO, it includes the manufacturer's OWN risk acceptability criteria (3.2). The standard imposes no matrix; an example exists only in the implementation guidance.
- The Hazard Log: the record of the ongoing identification and resolution of hazards; the CSO approves each version, and an issued version accompanies each Clinical Safety Case Report (3.3).
- The Clinical Safety Case: the organised product and business process documentation and supporting evidence, built up through the lifecycle of the system (3.4).
- The Clinical Safety Case Report (CSCR): the report presenting the arguments and evidence that the system is safe for a given use; produced at each lifecycle phase defined in the CRMP and for each modification that changes clinical risk, approved by the CSO and made available to the receiving organisation (3.5, 7.3.3).
- The Safety Incident Management Log: the record of the reporting, management and resolution of safety incidents (3.6).
- The post-deployment process: collecting and reviewing reported safety concerns and safety incidents, resolving incidents in a timely manner, and applying the clinical risk management process to every modification (7.2, 7.3).
What does compliance look like in practice?
DCB0129 has no certification scheme with an accredited body. Compliance is demonstrated through documents and process, and verified by buyers. In NHS procurement the supplier is asked to name the CSO, present the CSCR and hazard log, and describe the clinical risk management process; the same questions appear in the clinical safety section of the DTAC. The deploying organisation builds its own local safety case on top of the manufacturer's CSCR under DCB0160, and DCB0129 requires the manufacturer to make each CSCR available to the receiving organisation (3.5.3).
The biggest challenge for agile teams is keeping the cadence: the clinical risk management process applies to every modification, in proportion to the scale of the change and any new clinical risks (7.3.1, 7.3.2), and a modification that changes clinical risk needs a new CSCR approved by the CSO (7.3.3, 3.5.2). Companies that build these steps into the release process (definition of done, release review) meet the standard as part of their normal work; companies that backfill documents before a tender are easy to spot from the approval dates. The initial effort is typically a few weeks of work: appointing the CSO, the plan, the first hazard workshops involving clinicians, and the first CSCR.
Relationship to ISO 14971 & other frameworks
DCB0129 is conceptually related to ISO 14971, and the standard itself states that its requirements are broadly consistent with the requirements of ISO 14971. Both standards describe the loop: hazard identification, risk estimation and evaluation, control, residual risk, post-release monitoring. A company running a mature ISO 14971 process will do most of the DCB0129 analytical work "along the way". The differences matter, though. DCB0129 narrows the subject to patient clinical harm arising from a health IT system. It requires roles and documents that ISO 14971 does not have: a registered clinician as CSO, a CSCR at each lifecycle phase defined in the CRMP, an issued hazard log with each CSCR, and each CSCR made available to the receiving organisation. It also rests on section 250 of the Health and Social Care Act 2012 (England) rather than on the EU conformity assessment system.
In a health IT vendor compliance portfolio DCB0129 most often coexists with: DCB0160 (on the customer side), ISO 14971 and the UK MDR/MDR (when the product is a medical device), IEC 62304 (the software life cycle), and ISO 27001 and the DSPT (information security in the NHS). Cross-mapping avoids duplicating work where the processes genuinely overlap.
How does Guardiso help?
Guardiso gives you the DCB0129 requirements as controls, document templates (the policy, the Clinical Risk Management Plan, the Hazard Log and the Clinical Safety Case Report) and a place for the evidence. Clinical decisions stay where they belong: with your Clinical Safety Officer. Guardiso does not replace the CSO or clinical judgement.
- DCB0129 requirements created as controls when you enable the standard, numbered as in the NHS specification (version 4.2), with statuses, owners and the evidence each requirement needs.
- A free readiness self-assessment with hints on what an NHS buyer or compliance auditor will ask for.
- A risk register with a matrix configured for each organisation, so that the register can use the criteria from your Clinical Risk Management Plan (3.2.1).
- Document approval with a record of who approved which version and when. Approval rights follow the roles in your organisation, and DCB0129 requires the CSO to approve the plan, each hazard log version and each CSCR.
- Review dates on documents and an incident register in which you can record safety incidents and their resolution.
- Cross-mapping: ten DCB0129 requirements are linked to the matching ISO 14971 clauses, and two of them also to ISO 27001 controls.