LOPA: 7 Questions Leaders Should Ask

In a LOPA, one credited independent protection layer is often treated as a 10-fold risk reduction, according to the CCPS book Layer of Protection Analysis: Simplified Process Risk Assessment. This article gives senior EHS and operations leaders seven questions that separate a real layer of protection from a line item that only looks convincing in the risk file.

Why LOPA belongs in leadership conversations

Layer of Protection Analysis, usually shortened to LOPA, is a semi-quantitative risk assessment method that tests whether barriers between a hazardous event and a serious consequence are strong enough. IEC 31010:2019 lists LOPA among recognized risk assessment techniques, while IEC 61511 connects it to safety instrumented functions in process industries.

The mistake is treating LOPA as an engineering exercise that can stay inside the process safety office. The real leadership question is whether the organization has enough independence, maintenance discipline, competence, and decision rights to trust the layers it has credited.

On the Headline Podcast, hosted by Andreza Araujo and Dr. Megan Tranter, conversations about visible felt leadership often return to one uncomfortable point. A leader cannot claim strategic control of fatal risk while accepting barrier language that no one has tested in the field.

1. Define the hazardous scenario before you count layers

A LOPA only works when the hazardous scenario is specific enough to name the initiating event, consequence, existing safeguards, and target risk. A vague scenario such as chemical release cannot support a credible protection layer decision because the team does not know which failure path it is analyzing.

The market often sells LOPA as a calculation, although the first leadership failure usually appears before the arithmetic starts. If the scenario does not say what fails, where it fails, how quickly it escalates, and who has to act, then every later number inherits that weakness.

Senior leaders should ask for scenario language that an operator, maintenance planner, and control engineer would all recognize. For example, high level in tank T-204 during night transfer causing overflow to diked area is usable because it creates a concrete path for testing alarms, interlocks, response time, and physical containment.

2. Test independence before accepting a protection layer

An independent protection layer must reduce risk without depending on the same failure path that created the scenario. CCPS guidance treats independence as a defining condition, not a decorative feature, because two barriers with a common cause behave like one weak barrier under stress.

This is where leaders should be skeptical of attractive diagrams. If the same control system detects the deviation, sends the alarm, triggers the interlock, and depends on the same power source, the organization may be counting several names for one fragile mechanism.

The same logic applies outside the control room. When contractor oversight, permit approval, and field verification all depend on one busy supervisor, the apparent barrier stack may collapse into a single human bottleneck. That is why contractor interface risk belongs beside technical barrier discussions rather than after them.

3. Ask whether the credited layer can actually deliver 10x reduction

LOPA commonly assigns order-of-magnitude risk reduction credits, and a single strong independent protection layer may be treated as reducing risk by a factor of 10. 10x is not a slogan in LOPA, it is a claim about reliability, independence, and proof, according to the CCPS LOPA method.

What most leadership reviews miss is the evidentiary burden behind that number. A safety shower, gas detector, alarm, operator response, pressure relief valve, or interlock should not receive credit because it appears on a drawing. It earns credit because inspection records, proof tests, response times, design assumptions, and failure modes support the claim.

As co-host Andreza Araujo explores in Antifragile Leadership, pressure reveals whether a system has learned or merely memorized procedures. A layer that only works when staffing is ideal, maintenance is current, alarms are quiet, and the supervisor is nearby is not a leadership asset. It is a conditional hope.

4. Separate preventive layers from mitigative layers

Preventive layers reduce the likelihood that the hazardous event will occur, while mitigative layers reduce the consequence after the event has started. LOPA becomes misleading when a team mixes those two functions and then believes the scenario is controlled.

A high-level alarm may prevent overflow only if the operator has enough time, authority, and clarity to stop transfer. A dike may mitigate consequence after overflow, although it does not prevent release. A relief valve may prevent vessel rupture, while emergency response mitigates harm after exposure begins.

The distinction matters because executive reviews often reward visible mitigations and neglect upstream prevention. Leaders who already track SIF leading indicators should add one question to each review: are we reducing the initiating event, or are we only preparing to survive it?

5. Challenge human response credits under real operating conditions

Human response can be part of a protection strategy, but it should be credited cautiously because alarms, procedures, time pressure, fatigue, and authority gradients change performance. James Reason's work on latent conditions explains why people often inherit weak systems rather than create risk alone.

The leadership trap is treating operator will respond as a neutral sentence. It hides alarm rationalization, screen design, shift workload, training recency, competing tasks, and whether the operator has permission to stop production when the alarm points toward danger.

A practical test is simple enough for a monthly operations review. Ask the team to show the alarm priority, the expected response time, the latest drill, the staffing assumption, and the actual field path from recognition to action. If any of those pieces are missing, the credited layer needs downgrading or redesign.

6. Connect LOPA to Bow-Tie and risk matrix decisions

LOPA becomes more useful when it is connected to Bow-Tie analysis and the risk matrix rather than treated as a separate specialist file. Bow-Tie shows the barrier architecture, the risk matrix helps prioritize scenarios, and LOPA tests whether the credited layers provide enough reduction.

The three methods answer different questions. A risk matrix can distort leadership attention when severity and likelihood categories are too broad, while Bow-Tie analysis exposes barrier questions that a matrix cannot show. LOPA adds numerical discipline only after the scenario and barriers are defined well enough.

3 methods should not produce three disconnected risk files. The executive value appears when the same scenario travels from matrix prioritization, to Bow-Tie barrier review, to LOPA credit testing, and then into budget decisions for engineering, maintenance, training, and staffing.

7. Audit proof testing, ownership, and change control

A protection layer remains credible only while proof testing, ownership, and management of change keep its assumptions alive. IEC 61511 treats functional safety as a life-cycle issue, which means a layer credited during design can lose integrity during operation.

This is the quiet weakness in many mature organizations. The LOPA file says the interlock exists, but bypass records are not reviewed. The alarm exists, but nuisance alarms trained operators to ignore it. The relief device exists, but the process chemistry changed and the sizing basis was never revisited.

Leaders should require each credited layer to have an owner, test interval, failure record, bypass rule, and escalation path. That review should sit with the same seriousness as financial controls because a credited layer that is not maintained is a control that has already started to fail.

Each quarter without a barrier ownership review increases the chance that an outdated LOPA will keep approving work while the real operating system has moved on.

Comparison: listed safeguards versus credible LOPA layers

The clearest way to audit LOPA quality is to compare a listed safeguard with a layer that deserves credit. The difference is not vocabulary. It is evidence.

Conclusion: LOPA is a leadership test, not only a calculation

LOPA protects people when leaders use it to challenge independence, evidence, ownership, and drift rather than to decorate an existing risk assessment with technical language.

The next Headline Podcast conversation you bring into your leadership team can start with one question: which protection layers are we trusting, and which ones have we only listed? Visit Headline Podcast for real safety conversations where leadership and safety come together to shape better workplaces and better lives.