Reducing risk is rarely a question of eliminating it entirely; it is a question of how far you should reasonably go. ALARP is the principle that answers that question, and it underpins how process safety decisions about adding protection are justified and, just as importantly, where they are allowed to stop. This guide explains what ALARP means, the tolerability regions it sits within, and how an ALARP argument is used to decide whether one more safety function or barrier is worth adding.
ALARP in one line: ALARP stands for as low as reasonably practicable, the principle that risk should be reduced to a level where the effort, cost, and difficulty of any further reduction would be grossly disproportionate to the safety benefit gained. It does not require risk to be driven to zero, nor does it accept risk left unaddressed simply because reduction is inconvenient. Demonstrating ALARP means showing that all reasonably practicable measures have been taken and that further ones would be disproportionate.
ALARP recognises that risk reduction has diminishing returns. Early measures often remove a great deal of risk for modest effort, but each further measure tends to remove less risk for more cost, until a point is reached where spending more buys almost nothing in safety. ALARP places the acceptable stopping point not at the first convenient measure, nor at the theoretical elimination of risk, but where the sacrifice required by a further measure - in money, time, or effort - would be grossly disproportionate to the reduction in risk it would deliver. The word grossly is deliberate and important: the balance is weighted in favour of safety, so a measure is only rejected when its cost is not merely greater than the benefit but greatly out of proportion to it.
This weighting is what distinguishes ALARP from a plain cost-benefit calculation. In an ordinary cost-benefit test, a measure is worth doing if its benefit exceeds its cost. Under ALARP the bias runs the other way: a duty-holder is expected to implement a risk-reduction measure unless its cost is grossly disproportionate to the benefit, which means many measures whose cost merely equals or slightly exceeds the benefit are still expected. The burden effectively sits with the operator to show why a further reduction was not reasonably practicable, rather than with anyone else to show why it should have been done.
Determining what is reasonably practicable draws on more than one scenario's arithmetic. It considers established good practice and relevant standards, which usually must be met as a baseline before any disproportion argument is even entertained, and only then does the case-specific weighing of extra measures come into play. In practice, meeting recognised codes and standards does a large part of the ALARP job, and the disproportion test governs the additional, discretionary measures beyond that baseline.
ALARP is usually pictured within a three-region model of risk tolerability. At the top is the intolerable region, where the risk is so high that it cannot be justified except in extraordinary circumstances; risk in this region must be reduced regardless of cost, so ALARP does not even apply until the risk has been brought down out of it. At the bottom is the broadly acceptable region, where the risk is so low that it is generally regarded as adequately controlled and no further action is normally required, though good practice should still be maintained. Between them lies the tolerable region.
The tolerable region is where ALARP does its work. A risk in this band is not so high that it must be eliminated at any cost, nor so low that it can be ignored; it is accepted only on the condition that it has been reduced as low as reasonably practicable. This is the region where the disproportion test is applied, weighing each candidate measure's cost against its benefit to decide whether it must be implemented. The tolerable region is sometimes described as the ALARP region for exactly this reason - it is the zone in which the principle determines whether a risk is acceptable, and a risk sitting there without a credible ALARP demonstration is not properly justified.
Mapping these regions onto a risk matrix or a quantitative risk criterion is how the principle becomes usable in a study. The intolerable and broadly acceptable boundaries set where mandatory action begins and where further action stops being expected, and everything between requires an ALARP argument. This is why ALARP is so tightly bound to the rest of the risk toolkit: the risk matrix or QRA places a scenario within the regions, and ALARP governs the decision about further reduction once it is placed.
A very practical use of ALARP is deciding whether to add another safety instrumented function or barrier to a scenario. After a LOPA or similar analysis, a scenario may already sit in the tolerable region with its existing protection, and the question becomes whether one more layer should be added. ALARP frames this as a proportionality question: what risk reduction would the additional SIF actually deliver, and is the cost and complexity of installing, testing, and maintaining it grossly disproportionate to that reduction. If the scenario is already low within the tolerable region and the new layer would move it only marginally at large cost, an ALARP demonstration can justify stopping - the further reduction is not reasonably practicable.
The same logic can compel adding a layer rather than avoiding one. If a scenario sits high in the tolerable region and a further SIF or barrier would remove a substantial part of the remaining risk at a cost that is not grossly disproportionate, then ALARP requires it to be added; declining would leave the risk higher than reasonably practicable. In this way ALARP is not a licence to do the minimum - it is a discipline that pushes toward every reduction that is proportionate and stops only at those that are not. A credible demonstration must show the measures considered, the risk each would remove, and the reasoning for accepting or rejecting each one.
Because an ALARP case rests on how much risk a measure removes, it depends on realistic estimates of how the plant actually behaves, and this is where operating experience supports the argument. Records of how often a protective function has been demanded, how reliably existing safeguards have performed, and how frequently the process has approached its limits inform the frequencies behind the analysis, sharpening the estimate of what an additional layer would really achieve. Merobix, as cloud SCADA for oil and gas, retains alarm, trip, and process history across many remote sites in one browser, giving the analysis team factual evidence to ground an ALARP demonstration rather than resting the decision to add or omit a SIF on assumption alone.
ALARP requires that risk be reduced as low as reasonably practicable, meaning every risk-reduction measure should be implemented unless its cost, time, or difficulty would be grossly disproportionate to the safety benefit it delivers. It does not demand zero risk, but the balance is deliberately weighted toward safety, so measures are only rejected when their cost is greatly out of proportion to the benefit, not merely greater than it.
In a plain cost-benefit analysis, a measure is worth doing when its benefit exceeds its cost. ALARP tilts the balance toward safety: a measure is expected unless its cost is grossly disproportionate to the benefit, so many measures whose cost merely equals or slightly exceeds the benefit are still required. The burden sits with the operator to show why a further reduction was not reasonably practicable.
ALARP applies in the tolerable region, between the intolerable region where risk must be reduced regardless of cost and the broadly acceptable region where no further action is normally needed. A risk in the tolerable band is accepted only if it has been reduced as low as reasonably practicable, which is why that band is sometimes called the ALARP region. A tolerable risk without a credible ALARP demonstration is not properly justified.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.