After a HAZOP or a what-if study has identified a scenario where a cause could lead to a serious consequence, the team still has one open question: is the frequency of that scenario, after crediting the safeguards actually in place, low enough to be tolerable, or does it need another independent layer of protection? Layer of protection analysis answers that question with an order-of-magnitude, semi-quantitative calculation rather than a purely qualitative judgement call. This article explains the method step by step and works through a fully illustrative example so the logic is transparent — every number in the example is a labelled assumption, not a value you should copy into a real study.
Layer of protection analysis (LOPA) is a semi-quantitative risk-assessment method that starts from a hazard scenario identified in HAZOP or another qualitative study, estimates the initiating event frequency, credits only the independent protection layers that pass defined validity tests, and calculates a mitigated event frequency that is then compared against the organisation's own risk-tolerance criteria.
What LOPA is and where it fits
LOPA sits between qualitative hazard identification and full quantitative risk assessment (QRA). A HAZOP tells a team that a scenario exists and is worth worrying about; it does not, by itself, tell the team whether existing safeguards already reduce the risk enough, or whether a new independent protection layer (IPL) — commonly a safety instrumented function — is needed. LOPA takes one scenario at a time, applies order-of-magnitude arithmetic to initiating event frequency and IPL probability of failure on demand (PFD), and produces a mitigated frequency that a competent team can compare against its own criteria. It is faster and cheaper than full QRA, but it is still a technical judgement exercise, not a formula that runs itself — every input needs a stated basis, and every IPL credited needs to survive a validity test.
Most sites reach for LOPA when a HAZOP has flagged a scenario with a severe consequence and the team is not confident, from qualitative discussion alone, whether the existing safeguards are enough. It is commonly used to screen candidate safety instrumented functions before committing to a full functional-safety design, to check whether a proposed change (assessed through preliminary process hazard analysis (PHA) or an MOC review) has adequate protection, and to prioritise which scenarios in a large hazard register deserve engineering resources first. Full QRA, by contrast, is normally reserved for site-wide risk contours, land-use planning studies or regulatory submissions where the additional cost and time of a fully quantitative model is justified. LOPA methodology as commonly practiced is documented in AIChE Center for Chemical Process Safety (CCPS) guidance, and its interface with safety instrumented systems connects to the IEC functional safety framework covered later in this article.
Inputs required from HAZOP or scenario analysis
LOPA does not generate hazard scenarios; it evaluates them. The scenario, its cause (initiating event) and its consequence should already be defined and worded consistently by the upstream hazard and operability study (HAZOP) or an equivalent structured technique before a LOPA session starts. A team that walks into a LOPA workshop without a clearly worded cause-consequence pair from the parent study will end up re-litigating the hazard identification instead of doing the risk calculation, which wastes the specialist facilitator time a LOPA session requires. Where the site already ranks scenarios using hazard indices, that ranking is a useful pre-screen for deciding which HAZOP-flagged scenarios justify a full LOPA workshop and which can be closed with qualitative judgement alone. Good practice is to pre-screen the HAZOP or PHA worksheet for scenarios that meet a defined severity threshold set by the organisation, compile them into a LOPA candidate list before the workshop, and bring the node write-up, the P&ID and any prior safeguard inventory into the session so the team spends its time on the calculation and the IPL validity discussion rather than reconstructing the scenario from memory.
Define consequence and initiating event
Each LOPA scenario is built around one initiating event leading to one defined consequence, evaluated independently even if several scenarios share the same equipment.
Initiating event frequency
The initiating event is the first failure or deviation in the causal chain — a control loop failure, a human error in a specific task, a mechanical failure of a component. Its frequency is normally expressed in events per year and should come from a documented basis: site failure history, a recognised reliability data source, or a vendor/industry figure that the team records and can defend. Do not use a generic "typical" initiating-event frequency without recording where it came from; an unreferenced number is the first thing a peer reviewer or auditor will challenge. The consequence is defined to a specific, severity-ranked endpoint (for example a defined injury severity, a quantity of loss of containment, or an environmental threshold) consistent with the site's own consequence-severity categories, because the risk-tolerance comparison later in the process depends on comparing like with like.
Identify enabling conditions and conditional modifiers
Not every initiating event leads to the consequence every time it occurs. An enabling condition is a state that must exist for the scenario to develop — for example, a particular valve line-up or a specific operating mode. A conditional modifier is a probability that reduces the frequency further — for example, the probability that ignition occurs given a flammable release, or the probability that someone is present in the affected area at the time. Each enabling condition or conditional modifier used in the calculation needs its own documented basis and should only be applied once; a common review error is stacking several modifiers that are not actually independent of one another, which understates the frequency. As a discipline, the facilitator should ask, for every modifier proposed, whether it is genuinely independent of the initiating event and of every other modifier already applied — if two modifiers both depend on the same underlying condition (for example, both assume the plant is in the same specific operating mode), only one should be credited, and the dependency should be recorded in the assumption register rather than silently dropped.
Validate independent protection layers
This is the step that separates a defensible LOPA from an inflated one. A safeguard can only be credited as an independent protection layer if it passes a set of validity tests, not merely because it exists on the P&ID.
Probability of failure on demand
Every credited IPL is assigned a probability of failure on demand (PFD) — the probability that it fails to perform its function when called upon. The PFD used in a real study has to come from the IPL's own proof-test history, manufacturer reliability data appropriate to the specific device and its test interval, or a recognised functional-safety reference applicable to that IPL type. This article does not publish IPL PFD values from IEC 61511 or CCPS reference tables; those figures are drawn from licensed standards and vary with proof-test interval, device architecture and the organisation's own maintenance evidence. Source real PFD values from your own IPL performance data or the licensed standard, with a competent functional-safety practitioner signing off the basis.
Independence, specificity, dependability and auditability
A safeguard qualifies as an IPL only if it is independent of the initiating event and of every other IPL credited for the same scenario (it does not share a sensor, a power supply, a logic solver or a human action with another credited layer), specific to detecting and responding to this scenario, dependable enough that its performance can be demonstrated, and auditable, meaning its design basis, testing and maintenance records can be produced on request. A general-purpose control loop that also happens to be the initiating event's own control system cannot be credited as an independent layer against its own failure.
Human-action credit limitations
An operator response can sometimes be credited as an IPL, but only under strict conditions: a clear, unambiguous indication that the deviation is occurring, adequate time for the operator to diagnose and act, a written procedure for the response, and training and competency evidence for the people expected to perform it. Even where these conditions are met, most LOPA practice applies a conservative (higher) PFD to human response than to an engineered, automated IPL, and many organisations cap the number of human-response credits allowed per scenario. The specific PFD value and credit limits for human response must come from your organisation's own LOPA procedure and risk criteria, set by a competent facilitator — do not assume a fixed number applies universally.
Common-cause and dependency checks
Before finalising the IPL list, the team should explicitly check for common-cause failure paths across the credited layers — shared instrument air supply, shared power, shared maintenance technician performing calibration on both layers in the same visit, or a single initiating event (such as a power failure) that could simultaneously defeat the initiating cause's control and more than one "independent" layer. A LOPA that credits three layers without checking whether a single fire, flood or power loss could disable all three at once has not actually established three independent layers.
Calculate mitigated event likelihood
Once the initiating event frequency, applicable enabling conditions and conditional modifiers, and the PFDs of the validated IPLs are established, the mitigated event frequency is calculated by multiplying the initiating event frequency by each applicable conditional modifier and by the PFD of each credited independent protection layer. The result is expressed in events per year for the defined consequence. Because this is a multiplication of several uncertain inputs, the result should always be reported as an order of magnitude, not a false-precision decimal, and the assumption basis for every input should travel with the number.
Compare with risk-tolerance criteria
The mitigated event frequency is only meaningful once compared against a target frequency the organisation considers tolerable for that consequence severity. If the mitigated frequency is at or below the target, existing safeguards may be adequate (subject to the validity checks above holding up). If it exceeds the target, the gap indicates how much additional risk reduction — commonly delivered by an additional independent protection layer such as a safety instrumented function — is required.
No universal tolerability numbers
There is no single, universally correct risk-tolerance or target-frequency number that applies to every site, every jurisdiction or every consequence category. Target frequencies must be set by the organisation's own documented risk criteria, informed by its corporate risk matrix, applicable regulatory expectations and, where relevant, societal risk guidance for its jurisdiction. Any target frequency shown in this article's worked example is illustrative only and must not be used as a substitute for your organisation's approved criteria.
SIL/functional-safety interface
Where the required risk reduction is delivered by a safety instrumented function, LOPA is the recognised method for determining the target risk reduction factor that feeds into safety integrity level (SIL) selection under the IEC 61508/61511 framework. LOPA identifies how much risk reduction the SIF must deliver; the subsequent SIL verification — confirming the designed SIF actually achieves that PFD through architecture, proof-test interval and diagnostic coverage — is a separate, more detailed functional-safety engineering exercise governed by the licensed IEC 61511 and IEC 61508 texts, which this article does not reproduce.
Workshop quality and documentation
A LOPA study is only as good as the facilitation and the paper trail behind it. A qualified, experienced facilitator who is independent of pressure to reach a particular answer, a scribe capturing the basis for every number in real time, and a fixed worksheet format all materially affect whether the study will survive a peer review years later when someone revisits the scenario after an incident or an MOC. A balanced team typically includes someone who knows the process intimately (operations or process engineering), someone who understands the instrumentation and control philosophy, and someone independent of both who can challenge optimistic assumptions — a facilitator's most valuable contribution is often simply asking "what is the evidence for that number?" before it goes into the worksheet. Studies facilitated under schedule pressure, with only the requesting engineer in the room, are a recurring finding in post-incident reviews of process-safety documentation quality.
Sensitivity and uncertainty
Because LOPA multiplies several order-of-magnitude estimates together, a competent team tests how sensitive the conclusion is to its weakest input — typically the initiating event frequency or a credited IPL's PFD. Where an input is uncertain, documenting a plausible range and checking whether the conclusion (safeguards adequate versus additional IPL required) changes across that range is better practice than presenting a single point estimate as if it were precise.
The checklist below is a practical preparation and quality-review gate for a LOPA session, useful both before a workshop starts and when a completed study is being peer-reviewed.
- The scenario's cause and consequence are worded consistently with the parent HAZOP/PHA node, with a traceable scenario ID.
- The initiating event frequency has a documented basis, not an unreferenced "typical" figure.
- Every enabling condition and conditional modifier is checked for independence from other applied modifiers.
- Each credited IPL is tested against independence, specificity, dependability and auditability before being included.
- PFD values used for each IPL are sourced from proof-test history, vendor data or a licensed reference, with the source recorded.
- Any human-action credit meets the indication, time, procedure and competency conditions, and is capped per the organisation's own procedure.
- A common-cause and dependency check has been performed across all credited IPLs.
- The mitigated frequency is compared only against the organisation's own approved risk-tolerance criteria.
- Safeguards considered but not credited are listed with the reason they were excluded.
- Follow-up actions (for example, a required SIF) are logged with an owner and due date.
Worked example and worksheet
The example below illustrates the calculation sequence only. Every value is a stated illustrative assumption chosen to demonstrate the arithmetic and documentation discipline — none of them is drawn from IEC 61511, CCPS or any other published reference table, and none should be reused in a real study.
| LOPA input | Illustrative value (assumed, not a standard) | Basis to record in a real study |
|---|---|---|
| Scenario | Loss of cooling water flow leads to overpressure of a batch reactor | Cause-consequence pair from the parent HAZOP node |
| Initiating event frequency | 0.3 per year (illustrative assumption) | Site failure history or referenced reliability data |
| Conditional modifier: operator not present to notice manually | 0.5 (illustrative assumption) | Site-specific occupancy/coverage study |
| IPL 1: independent high-temperature trip (separate sensor and logic solver) | PFD 0.04 (illustrative assumption) | Proof-test history or manufacturer data for the specific device and test interval |
| IPL 2: pressure relief device sized for this scenario | PFD 0.02 (illustrative assumption) | Maintenance and inspection history for the specific device |
Working through the sequence: mitigated event frequency = initiating event frequency × conditional modifier × PFD(IPL 1) × PFD(IPL 2) = 0.3 × 0.5 × 0.04 × 0.02 = 0.00012 events per year, or roughly 1.2 × 10-4 per year. That is the order-of-magnitude result the team would then compare against its own approved target frequency for this consequence severity — a comparison this article deliberately does not complete, because the target number has to come from your organisation's risk criteria, not from a published article.
Notice what the worked example deliberately shows and does not show. It shows the multiplication sequence, the discipline of stating each input as a labelled assumption, and the requirement to check every credited IPL against the independence, specificity, dependability and auditability tests before it is allowed into the calculation. It does not show a "correct" initiating event frequency for loss of cooling water flow, a "correct" PFD for a high-temperature trip, or a "correct" target frequency for a reactor overpressure consequence — those numbers vary by equipment condition, maintenance history, instrument architecture and the organisation's own risk appetite, and asserting fixed values here would be exactly the kind of fabricated precision this article is written to avoid. A real study would also record, in the assumption register, any existing safeguard the team chose not to credit — for example a pressure gauge with no automatic response — and why, since a reviewer will otherwise ask why an apparently relevant safeguard was left out of the calculation.
| Check | Question the reviewer asks |
|---|---|
| Independence | Does this IPL share a sensor, power source, logic solver or human action with the initiating event or another credited IPL? |
| Specificity | Is the IPL designed to detect and respond to this specific scenario, not a general-purpose control? |
| Dependability | Is there proof-test or performance evidence supporting the assumed PFD? |
| Auditability | Can the design basis, testing and maintenance records be produced on request? |
The assumption register below is the discipline that makes a LOPA defensible after the workshop ends.
| Field | Purpose |
|---|---|
| Scenario ID | Traceable link back to the parent HAZOP/PHA node and deviation |
| Consequence endpoint | Specific, severity-ranked outcome the scenario is evaluated against |
| Frequency units | Events per year, stated consistently across all inputs |
| IPL basis | Design description and why it passes the four validity tests |
| PFD source | Proof-test data, vendor reference or standard citation used, with date |
| Assumptions | Every non-measured input, labelled as an assumption with its basis |
| Safeguards not credited | Safeguards present but excluded from the calculation, and why |
| Action tracking | Follow-up items (for example, a required SIF) with owner and due date |
A LOPA study, however well facilitated, only produces a defensible number when your own initiating-event data, IPL performance evidence and risk-tolerance criteria feed it. Requesting a LOPA study is the practical next step once a HAZOP or PHA has flagged scenarios that need this level of quantification; Himaya Prevention facilitates the workshop, tests IPL validity against site evidence, and documents the assumption register so the study holds up under later audit or investigation review. Contact info@himpre.com to scope a study, or ask about tracking scenarios, credited safeguards and follow-up actions through the HSEFQ.com process-risk module.
Transparent LOPA scenario worksheet
This worksheet performs the LOPA multiplication only. It does not supply initiating-event frequencies, IPL PFDs or target frequencies — every value must come from your own data, a competent facilitator and your organisation's approved risk criteria. It is a screening aid, not a substitute for a facilitated LOPA study or a functional-safety verification.
Frequently asked questions
How is LOPA different from HAZOP?
HAZOP is a qualitative technique that systematically identifies deviations, causes and consequences across a process. LOPA takes a specific cause-consequence scenario — usually one flagged as significant during HAZOP — and applies order-of-magnitude arithmetic to estimate whether existing independent protection layers reduce its frequency to a tolerable level, or whether more risk reduction is needed.
What qualifies as an IPL?
A safeguard qualifies as an independent protection layer only if it passes four tests: independence from the initiating event and other credited layers, specificity to the scenario, dependability supported by performance evidence, and auditability of its design and maintenance records. A safeguard that exists on paper but fails any of these tests should not be credited.
Can an operator response be credited?
Sometimes, but only under strict conditions: a clear and unambiguous alarm or indication, adequate time to diagnose and respond, a written procedure, and demonstrated training and competency. Most LOPA practice applies a more conservative probability of failure to human response than to an automated IPL, and many organisations limit how many scenarios can rely on human credit.
Does LOPA determine SIL?
LOPA determines the required risk reduction that a safety instrumented function must deliver for a given scenario, which feeds into SIL selection. Confirming that a specific SIF design actually achieves that risk reduction is a separate functional-safety verification exercise under the IEC 61508/61511 framework, not part of the LOPA calculation itself.
How are assumptions documented?
Every non-measured input — initiating event frequency, conditional modifiers, IPL PFDs and any judgement calls on independence — should be recorded in an assumption register with its source, the date it was set, and who approved it, so the study can be defended and updated later without re-running the entire workshop.
0 Comments