What ALARP Means
ALARP stands for As Low As Reasonably Practicable. It is a long-established principle of UK health and safety law that requires organisations to reduce risks until any further reduction would require measures whose cost, time or effort would be grossly disproportionate to the additional safety benefit achieved.
The legal foundations of ALARP can be traced to the landmark case Edwards v National Coal Board (1949), which established that deciding whether a control is reasonably practicable involves balancing the magnitude of the risk against the sacrifice required to eliminate or reduce it. This principle is reflected throughout the Health and Safety at Work etc. Act 1974, which underpins modern UK health and safety legislation. The UK Health and Safety Executive (HSE) describes risk using a three-region framework:
- Unacceptable risk - the level of risk is intolerable and activity should not proceed.
- Tolerable if ALARP - risk may be accepted only where it has been reduced as low as reasonably practicable.
- Broadly acceptable risk - the remaining risk is sufficiently low that further reduction is generally unnecessary.
For digital health organisations, ALARP provides the bridge between these wider legal principles and the practical management of clinical risks within health IT systems. Whether developing Software as a Medical Device (SaMD) or non-medical device software, manufacturers need to demonstrate not only that risks have been identified but also that reasonable opportunities to reduce them have been properly considered.
ALARP in DCB0129 and DCB0160
Within the NHS, the principle of ALARP is embedded within the clinical risk management standards DCB0129 and DCB0160. DCB0129 applies to manufacturers developing health IT systems, while DCB0160 applies to organisations deploying those systems into operational healthcare settings. Together they establish how clinical risks should be managed throughout the lifecycle of digital health technologies.
The current published version of DCB0129 continues to use ALARP terminology. Throughout the clinical safety process, ALARP influences several key artefacts, including:
- Clinical Risk Management Plans
- Hazard Logs
- Clinical Safety Case Reports (CSCRs)
When reviewing these documents, the Clinical Safety Officer (CSO) must be satisfied that identified hazards have been assessed appropriately, suitable controls have been implemented and any remaining residual risks have been reduced to a level that is considered ALARP.
Importantly, DCB0129 recognises that some clinical risks cannot be completely eliminated. Where no further reasonably practicable control is available, organisations must justify why the remaining residual risk is acceptable when balanced against the expected clinical benefits delivered by the system.
This is why ALARP is not simply a scoring exercise. It is a documented engineering and clinical judgement supported by evidence demonstrating that appropriate risk reduction measures have been considered throughout development.
ALARP vs AFAP in ISO 14971
Medical device manufacturers frequently encounter another important concept alongside ALARP: AFAP, meaning As Far As Possible. ISO 14971:2019 acknowledges that different jurisdictions adopt different approaches to risk reduction. Clause 4.2 Note 1 recognises concepts including ALARP, ALARA (As Low As Reasonably Achievable) and AFAP.
However, for manufacturers placing products on the European market, the harmonised standard EN ISO 14971:2019+A11:2021 reflects the requirements of the EU Medical Device Regulation (EU MDR 2017/745). Annex I of the MDR requires manufacturers to eliminate or reduce risks "as far as possible" without adversely affecting the benefit-risk ratio. Although the distinction may appear subtle, it has practical implications.
Under the traditional UK interpretation of ALARP, the cost, effort and practicality of implementing additional controls may legitimately form part of the decision about whether further risk reduction is reasonably practicable.
Under the EU MDR's AFAP philosophy, the emphasis is different. Manufacturers are generally expected to implement all appropriate risk control measures that represent the current state of the art, irrespective of purely economic considerations, provided those controls do not adversely affect the overall benefit-risk balance of the device. In practice, organisations implementing ISO 14971 rarely rely on the standard alone. Most also use ISO/TR 24971:2020, which provides detailed guidance on applying the risk management process, selecting controls and documenting benefit-risk decisions.
For UK-based Software as a Medical Device manufacturers, this creates a dual-compliance environment. Products supplied to the NHS may require evidence supporting ALARP within DCB0129 clinical safety documentation, while technical documentation prepared for UKCA or CE marking must also satisfy the expectations of ISO 14971 and, where applicable, the EU MDR's AFAP approach. Understanding which framework applies, and documenting decisions accordingly, is an important part of effective regulatory compliance.
Applying ALARP and AFAP to Software
Whether applying ALARP or AFAP, the underlying risk management process follows a familiar sequence. The process begins by identifying hazards associated with the software before estimating the severity and likelihood of potential harms. Risks are then evaluated, appropriate controls are introduced and any remaining residual risks are assessed to determine whether they are acceptable. For software products, common hazards may include:
- algorithmic errors;
- unclear user interfaces;
- incorrect calculations;
- delayed information;
- integration failures;
- data integrity issues;
- cybersecurity vulnerabilities with patient safety implications;
- inappropriate system configuration.
Risk controls should reflect current good engineering practice and the state of the art. Examples include:
- input validation;
- confirmation steps;
- automated alerts;
- improved usability design;
- user training;
- monitoring and audit logging;
- post-market surveillance;
- ongoing software maintenance.
Once controls have been implemented, organisations must assess whether any further reasonably practicable (or technically appropriate) controls remain available. Within DCB0129, the Clinical Safety Officer plays an essential role in reviewing these judgements. The CSO provides independent clinical oversight, ensuring that hazards have been appropriately assessed, controls are proportionate and the conclusions presented within the Clinical Safety Case are supported by evidence. Ultimately, ALARP or AFAP is not demonstrated by a residual risk score alone; it is demonstrated by the quality of the reasoning that supports the decision.
The Gross Disproportion Test
One of the defining characteristics of ALARP is the gross disproportion test. The Health and Safety Executive explains that organisations should implement a safety measure unless the sacrifice involved, in terms of cost, time or effort, is grossly disproportionate to the reduction in risk achieved. The HSE deliberately does not prescribe numerical thresholds for what constitutes "gross disproportion". Instead, organisations are expected to exercise informed professional judgement, with the balance increasingly favouring additional safety measures as the potential severity of harm increases. Within digital health, this reasoning should be clearly documented.
A well-maintained Hazard Log often records:
- the identified hazard;
- current risk assessment;
- candidate control measures;
- evaluation of additional controls;
- rationale for implementing or rejecting each option;
- residual risk;
- supporting evidence.
This provides reviewers with a transparent record of how ALARP decisions were reached. Clinical Safety Officers, NHS reviewers and notified bodies increasingly expect this reasoning to be explicit. Simply stating that a risk is "ALARP" without documenting how the conclusion was reached is unlikely to provide sufficient assurance.
Common ALARP Pitfalls
Many organisations unintentionally reduce ALARP to a simple checkbox exercise. In reality, ALARP is not a pass-or-fail label, it is a structured judgement supported by evidence. Another common mistake is using ALARP terminology throughout an EU MDR technical file where the applicable regulatory framework instead expects manufacturers to demonstrate that risks have been reduced as far as possible. Teams also sometimes treat ALARP decisions as permanent. Software evolves rapidly, and new releases, clinical incidents, emerging vulnerabilities or advances in engineering practice may all require previous judgements to be revisited.
Finally, organisations occasionally document residual risks without recording the corresponding benefit-risk reasoning, particularly where elevated risks remain after all practical controls have been implemented. Both DCB0129 and wider medical device risk management expect these decisions to be clearly justified rather than assumed.
Effective clinical safety documentation balances regulatory compliance with practical software development, ensuring that robust risk management supports innovation rather than becoming a barrier to deployment.
Bringing ALARP Into Practice
For organisations developing digital health products, ALARP is more than a legal principle; it is a practical way of demonstrating that patient safety has been considered throughout the design, development and deployment of software. Whether you're preparing DCB0129 documentation for NHS deployment or aligning your technical documentation with ISO 14971 and the EU MDR, clear, evidence-based risk management is essential.
At AbedGraham, we help health technology companies integrate clinical safety, medical device risk management and regulatory compliance into a single, proportionate process. From Hazard Logs and Clinical Safety Case Reports to ISO 14971 alignment and Clinical Safety Officer support, our team can help you build documentation that stands up to scrutiny.
Book a discovery call to discuss your clinical risk management approach and how we can support your next project.