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: DCB0129 was issued as an information standard that covered bodies must have regard to on a "must comply" basis. In practice this means a supplier of clinical software to the NHS in England must demonstrate compliance — buyers require it routinely, including within the DTAC (Digital Technology Assessment Criteria) assessment. The standard has a twin: DCB0160, which places mirror obligations on the health organisations deploying and using 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 outside the UK, including Polish SaaS vendors entering the NHS market, DCB0129 compliance is a condition of entry: it appears in procurement requirements, in the DTAC and in due diligence questionnaires. Importantly, DCB0129 applies independently of medical device regulation — a product can simultaneously fall under the UK MDR/MDR as a medical device and under DCB0129 as a health IT system; the ISO 14971 and DCB0129 risk processes then interlock heavily, but the NHS artefacts (the hazard log, CSO-approved CSCRs) must be delivered separately.
The Clinical Safety Officer — the key role
The most distinctive DCB0129 requirement is the appointment of a Clinical Safety Officer (CSO): the person accountable for the clinical safety of the manufactured systems. The CSO must be a practising, registered clinician — for example a doctor, nurse or pharmacist with current registration with a recognised UK professional body (GMC, NMC, HCPC and similar) — and be trained in clinical risk management. This requirement cannot be delegated to an engineer or quality manager: the acts of approving clinical safety documents and accepting residual risk are the CSO personal clinical judgement.
The CSO approves the Clinical Risk Management Plan, every hazard log version and every Clinical Safety Case Report before a product release. Smaller companies often engage an external, contracted CSO — an accepted practice, provided the person genuinely participates in the process rather than merely signing documents.
Key artefacts & requirements
DCB0129 requires establishing a clinical risk management system and maintaining four core artefacts throughout the product life cycle:
- The Clinical Risk Management File (CRMF) — a single repository referencing all clinical safety records and documents for the product.
- The Clinical Risk Management Plan (CRMP) — the plan of clinical safety activities across the life cycle, defining among other things YOUR OWN risk acceptability criteria (the standard imposes no matrix — an example exists only in the implementation guidance), approved by the CSO.
- The Hazard Log — a living register of clinical hazards: hazard description, potential patient harm, causes, control measures, risk assessment and status; each version approved by the CSO and coupled to its corresponding CSCR.
- The Clinical Safety Case Report (CSCR) — the report summarising the argument and evidence that the product is acceptably clinically safe; produced for each life cycle phase and each significant release, approved by the CSO before release and shared with deploying organisations.
- The post-deployment process — handling clinical safety incidents with escalation to the CSO, and assessing the clinical impact of every product change before it ships.
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 CSCR under DCB0160 — which is why refusing to share the CSCR blocks sales in practice.
The biggest challenge for agile teams is keeping the cadence: every change to clinical functionality requires a safety impact assessment, hazard log and CSCR updates, and CSO approval before release. Companies that build these steps into the release process (definition of done, release review) meet the standard naturally; 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 — 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, requires roles and artefacts unknown to ISO 14971 (a registered clinician as CSO, a per-release CSCR, coupling of hazard log versions to CSCRs, the obligation to share the CSCR with deployers) and operates within the UK legal regime rather than 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 manages the four core DCB0129 artefacts and enforces the CSO approval workflow — while clinical decisions stay where they belong: with your Clinical Safety Officer. Guardiso does not replace the CSO or clinical judgement; it organises the process and evidence around them.
- DCB0129 requirements seeded as controls when you enable the framework — CSO roles and competence, the CRMF, CRMP, hazard log, CSCR and the post-deployment process — with statuses and owners.
- A free readiness self-assessment with hints on what an NHS buyer or compliance auditor will demand.
- A risk register with a per-organisation configurable matrix — your own severity and likelihood scales and acceptability thresholds, as required by the CRMP.
- An approval workflow: the plan, hazard log versions and CSCR reports with a documented CSO approval act, date and version — ready to show in procurement.
- Recurring tasks for the post-deployment process — hazard log reviews, clinical incident handling and change impact assessment before release.
- Cross-mapping to ISO 14971, the MDR, IEC 62304 and ISO 27001 — shared risk management activities counted once, with the NHS artefacts kept distinct where the standard requires it.