A HAZOP tells you that a scenario is hazardous. It does not tell you how hazardous, and it does not tell you whether the safeguards already on the P&ID are enough or whether you need another layer. That gap is exactly what Layer of Protection Analysis exists to close. LOPA takes a scenario flagged in hazard and risk assessment and runs the numbers: how often does the initiating event occur, how many independent protection layers stand between that event and the consequence, and does the resulting mitigated frequency land inside the facility's tolerable risk criteria. For U.S. oil and gas and chemical facilities working under OSHA Process Safety Management, LOPA is the bridge between a qualitative PHA finding and a defensible SIL target for any Safety Instrumented Function the scenario requires. Done well, it tells you exactly how much risk reduction you need and where to get it. Done poorly — with IPLs that aren't actually independent, or initiating event frequencies pulled from the wrong source — it produces a SIL rating that looks rigorous and isn't.
Why LOPA Sits Between HAZOP and SIL Determination
A HAZOP or What-If study is built to find hazardous scenarios, not to rank them numerically. It produces a qualitative judgment — "this deviation could cause a loss of containment" — and a list of existing safeguards, but it has no built-in mechanism for deciding whether those safeguards are enough or whether the residual risk is acceptable. LOPA picks up exactly where the PHA leaves off. It takes one scenario at a time, assigns a numerical initiating event frequency, credits only the safeguards that genuinely qualify as independent protection layers, and multiplies the two together to get a mitigated event frequency that can be compared directly against the facility's tolerable risk criteria. When the mitigated frequency doesn't clear that bar, LOPA tells you the size of the gap — which is the number that becomes the target PFDavg for a new or upgraded Safety Instrumented Function.
The discipline that makes LOPA useful is also where most facilities lose rigor under schedule pressure: crediting a safeguard as an IPL when it shares a sensor, a power supply, or a human action with another layer in the same scenario. Teams reviewing their existing LOPA studies for the first time in several years often book a demo to see how many of their credited IPLs would still pass an independence check today.
The Four Criteria That Decide Whether a Safeguard Actually Counts as an IPL
Not every safeguard listed in a HAZOP worksheet earns a place in a LOPA calculation. A device, system, or human action only qualifies as an Independent Protection Layer if it satisfies four criteria simultaneously, and failing any one of them means the safeguard either doesn't get credited at all or gets credited with a much weaker PFD than the team initially assumed.
Specificity
The IPL must be designed to detect and respond to one specific hazardous scenario. A general-purpose alarm that operators are trained to interpret a dozen different ways doesn't carry the same credit as a function built and tested for this exact deviation.
Independence
The IPL's performance cannot depend on the initiating event or on any other IPL credited in the same scenario. A pressure transmitter shared between the BPCS control loop and the SIS trip function fails this test — a single sensor failure takes out both layers at once.
Dependability
The protection provided must reduce the identified risk by a known, specified amount — a PFD that's been quantified, not assumed. This is where IPL credit gets tied directly to maintenance history, proof test records, and failure rate data rather than good intentions.
Auditability
The IPL has to be designed so its protective function can be periodically validated — proof tested, inspected, or otherwise confirmed still capable of performing on demand. An IPL nobody can verify is functioning is an IPL that shouldn't be in the calculation. Book a demo to see how iFactory ties IPL auditability directly to proof test scheduling.
Common Independent Protection Layers and Their Typical PFD Credit
LOPA practitioners draw on industry-standard PFD ranges for common safeguard types rather than re-deriving every value from scratch. These figures are order-of-magnitude estimates — appropriate for a semi-quantitative method — and the specific value credited for any given IPL should reflect the facility's own maintenance and proof test history wherever that data exists.
| IPL Type | Example | Typical PFD Range | Key Independence Risk |
|---|---|---|---|
| BPCS Control Loop | Operator response to alarm with adequate time to act | 10⁻¹ | Cannot be credited if it shares logic or a sensor with the SIS |
| Safety Instrumented Function | SIL-rated SIS trip on high pressure or high level | 10⁻¹ to 10⁻⁴ | PFD must come from verified SIL calculation, not an assumed default |
| Relief Device | Pressure relief valve sized for the specific overpressure scenario | 10⁻² to 10⁻³ | Credit voided if undersized for this scenario or shared with another service |
| Passive Protection | Dike, blast wall, or inherently safer design feature | 10⁻² to 10⁻³ | Generally the most defensible IPL since there is no active failure mode |
| Human Response | Trained operator action following a specific, validated procedure | 10⁻¹ to 10⁻² | Requires adequate time to detect, diagnose, and respond — credit drops sharply under time pressure |
From Scenario to SIL Target: How LOPA Output Feeds Functional Safety
The entire point of running LOPA on a scenario is to answer one question with a number: does the existing combination of initiating event frequency and credited IPLs already bring the consequence below the tolerable event frequency, or is there a risk gap that needs to be closed. When a gap exists, LOPA doesn't just flag the problem — it quantifies exactly how much additional risk reduction is required, and that number becomes the target PFDavg the next SIF has to achieve. Request a LOPA-to-SIL mapping review to see how your facility's scenario library translates into current SIL targets.
Define the Scenario
Pull one cause-consequence pair from the PHA worksheet — one initiating event, one specific hazardous outcome — and define the scenario boundary clearly enough that IPL credit decisions aren't ambiguous.
Assign Initiating Event Frequency
Estimate how often the initiating event occurs per year, drawing on industry data sources such as the CCPS Initiating Events and IPL database rather than guessing at a round number.
Credit Qualifying IPLs Only
Walk every existing safeguard against the four IPL criteria, multiply the surviving PFDs against the initiating event frequency, and apply any conditional modifiers relevant to the scenario.
Compare to Tolerable Frequency and Set SIL
Compare the mitigated event frequency to the facility's tolerable event frequency criteria. Any remaining gap defines the target PFDavg, and therefore the SIL, for the next protection layer.
"We had LOPA studies on file for every major scenario in the unit, but when we actually pulled the IPL credit assumptions apart during a five-year PHA revalidation, we found two scenarios where the BPCS alarm and the SIS trip shared the same level transmitter. On paper we had two layers. In reality we had one. Re-running those LOPA worksheets with the correct independence assumption changed our SIL target on both SIFs." — Process Safety Lead, U.S. Gulf Coast Refining Facility
Where LOPA Studies Lose Rigor Over Time
A LOPA worksheet signed off at the time of a PHA is a snapshot of plant conditions and credited safeguards as they existed that day. The studies that hold up under audit five years later are the ones where someone has been actively checking whether the underlying assumptions still match reality, not the ones sitting untouched in a document control system.
Expert Review: Why LOPA Quality Depends on Discipline, Not Software
Across more than fifteen years facilitating LOPA sessions for U.S. refining and chemical clients, the studies that fall apart under audit almost never fail because the math was done wrong. The arithmetic in LOPA is simple — multiply a frequency by a series of probabilities. What fails is the discipline behind the inputs: a facilitator who lets a team credit an operator response without checking whether there's actually enough time to detect, diagnose, and act before the consequence occurs, or a team that credits a relief valve as an independent layer when it's shared across two services and sized for neither scenario perfectly. The standard itself is honest about being semi-quantitative — it was never meant to produce precision numbers, only defensible order-of-magnitude judgments. The discipline problem is that those judgments get treated as permanent once the worksheet is signed, when in reality every IPL credit is only as good as the assumption behind it on the day someone last checked it. Facilities that keep their LOPA studies defensible are the ones where IPL independence, proof test currency, and management of change are tracked against the original worksheet continuously, not the ones with the most polished templates.
Conclusion: LOPA Is Only as Strong as Its Weakest Credited IPL
LOPA gives a process safety team something a HAZOP cannot: a number. It quantifies how much risk reduction a scenario actually needs and tells you precisely where that reduction has to come from, whether that means a new Safety Instrumented Function, a stronger relief system, or simply correcting an IPL credit that was never independent in the first place. The value of that number depends entirely on the rigor behind it — on initiating event frequencies that reflect real data, on IPLs that genuinely satisfy specificity, independence, dependability, and auditability, and on a system that catches it when a shared sensor, a missed proof test, or an unreviewed management of change quietly invalidates an assumption the original study depended on. A LOPA worksheet filed away and never revisited is a snapshot of a moment in time. A LOPA program connected to live proof test and change records is an ongoing safety case.
Frequently Asked Questions: LOPA and Process Safety
How is LOPA different from HAZOP?
HAZOP identifies hazardous scenarios qualitatively; LOPA takes a specific scenario from that HAZOP and quantifies the initiating event frequency and IPL credits to determine if existing risk reduction is adequate.
What are the four criteria a safeguard must meet to count as an IPL?
An IPL must satisfy specificity, independence from the initiating event and other IPLs, dependability with a known PFD, and auditability through periodic validation.
How does LOPA output determine a SIL target?
When the mitigated event frequency exceeds the tolerable risk criteria, the size of that gap defines the additional risk reduction required, which sets the target PFDavg and corresponding SIL for the next protection layer.
Why can't a BPCS control loop and an SIS trip share the same sensor in LOPA?
Independence requires that an IPL's performance not depend on the initiating event or any other credited IPL, so a shared sensor means a single failure can defeat both layers simultaneously.
How does iFactory help maintain LOPA study integrity over time?
iFactory ties IPL credit assumptions to live proof test records and management of change events, flagging any scenario where field conditions no longer match the original LOPA worksheet.
