How Safe Is Safe Enough? The ALARP Principle for Engineering Risk Trade-offs

The article opens with a design review where a team states its safety target as "zero accidents." The author argues this is not a valid goal because it is neither verifiable nor falsifiable—you can only prove it failed when an accident occurs.

Two Safety Philosophies: Reactive vs. Proactive

Engineering safety has historically followed two paths:

Reactive safety: Deploy the system, wait for accidents, then investigate root causes and update standards. Early aviation regulation evolved this way—almost every airworthiness clause traces back to a fatal crash. The cost of learning is borne by victims, and the approach assumes similar accidents will repeat so lessons can be reused.

Proactive safety (System Safety): Identify failure modes and hazards during design, eliminate what can be eliminated, and add controls for the rest. The core tool is Hazard Analysis—simulating failures before the system is built. Mature high-risk industries shift to proactive safety because the reactive cost becomes unaffordable.

Risk Can Never Be Eliminated

Safety always conflicts with performance, cost, reliability, and usability. The article gives two concrete trade-off examples:

Industrial robot emergency stop: Faster braking protects people but shocks the gearbox and drivetrain, accelerating wear and reducing reliability—which itself creates new risks. Slower braking preserves equipment but leaves more kinetic energy during a collision, increasing injury risk. There is no absolutely "safer" option; the choice is where to place the risk.

Parameter entry verification: Requiring double entry and automatic comparison catches input errors, but each extra step lengthens the task. Operators grow fatigued and start skipping checks, confirming dialogs blindly, or accepting defaults. The protection against one error class may induce a new class of human error.

The author summarizes a counter-intuitive conclusion: safety measures themselves introduce new risks. A table in the source compares three measures (faster emergency stop, multi-step verification, hardware redundancy) with their benefits and attendant costs (wear, procedure fatigue, cost/weight/complexity).

If the goal were to cover every extreme, low-probability scenario, the system would become infinitely expensive, heavy, and complex—ultimately losing its purpose. A system designed only for vanishingly rare catastrophes is a failed design.

The Measuring Stick: ALARP — As Low As Reasonably Practicable

The UK Health and Safety Executive (HSE) defines ALARP, dividing risk into three bands:

Unacceptable region: Risk must be reduced regardless of benefit.

ALARP region (broadly acceptable with effort): Most engineering systems fall here. Risk must be lowered until further reduction would be grossly disproportionate to the risk reduction achieved.

Broadly acceptable region: Risk is low enough that no further investment is needed.

The middle band is where engineers debate. The criterion is not a simple cost-benefit test (cost < benefit → do it; cost > benefit → stop). Instead, further investment is required unless the cost is grossly disproportionate to the risk reduction. This distinction is critical: a marginal cost excess does not justify stopping; only a gross disparity does. Moreover, the acceptable disproportion varies with severity—near the unacceptable region, near-any-cost reduction is expected; near the broadly acceptable region, extra spending is waste.

Three Stances on New-Technology Risk

Society and engineers typically adopt one of three attitudes:

Anti-technology: High-risk innovations should not be deployed. Morally simple but cannot address already-deployed systems or explain why technology has doubled life expectancy over the past century.

Techno-optimism: Build whatever is technically feasible; accidents are human error, so automate humans away. This oversimplifies: new technology eliminates old failure modes but creates novel ones. Humans possess situational awareness ("something feels off today") that automated systems struggle to replicate.

Risk-benefit analysis (mainstream): Quantify benefits and risk losses; proceed if net benefit is positive. Many design reviews essentially perform this calculation. However, it has two flaws:

It ignores distributional equity—beneficiaries and risk-bearers are often different groups (e.g., passengers gain convenience, residents bear noise and crash risk; business units gain efficiency, maintainers inherit complexity).

It fails ethically when irreversible, life-threatening outcomes are involved: a large aggregate benefit cannot justify accepting a catastrophic loss for a few.

The Real Question: Which Systems Should We Build?

The article concludes that safety is not about reaching a fixed threshold but about making a conscious, traceable trade-off :

Stop reducing risk when further cost is grossly disproportionate to the gain.

Document that judgment completely so future reviewers can understand why certain protections were omitted and which residual risks were accepted.

This yields no single number; each project must derive its own threshold from regulations, cost, failure consequences, and use context. More important than "how to keep risk below the threshold" is the prior question: which systems do we choose to build? Once an irreversible high-risk system is deployed, its risk becomes a mandatory, long-term burden on all stakeholders. Every architectural decision, requirement definition, and review comment ("implement it this way for now," "follow the standard," "handle it later") implicitly answers "how safe is safe enough." Engineers often don't realize they are making that choice.

Safety is not a destination state we arrive at; safety is the reasoned justification that must be fully explained after every trade-off.

References

ALARP principle and three-region model: UK HSE risk management guidance; core criterion: cost grossly disproportionate to risk reduction.

Functional safety tolerable risk and residual risk concepts: ISO 26262; GAMAB (at least equally good) for European railway risk management.

Robot emergency-stop and parameter-verification cases: engineering practice illustrations, not tied to a specific project.

Inspired by the book Introduction to System Safety Engineering .