LOPA: What Layer of Protection Analysis Is, Independent Protection Layers, and Risk Reduction

Understand LOPA, initiating events, IPLs, PFD, independence, enabling conditions, risk calculation, and its relationship with SIL and IEC 61511.

Check it out!

Layer of Protection Analysis (LOPA) is a semiquantitative risk-analysis methodology used to evaluate specific accident scenarios, estimate the mitigated frequency of a consequence, and verify whether the existing independent protection layers are sufficient to meet the adopted risk criterion. LOPA occupies an intermediate position between qualitative analyses such as HAZID and HAZOP and more complex quantitative studies. Its value does not lie in producing numbers with many decimal places, but in disciplining the assumptions: one scenario at a time, a coherent initiating-event frequency, credit only for truly independent layers, and traceability regarding the need for additional risk reduction.

What Is LOPA

LOPA stands for Layer of Protection Analysis. The Center for Chemical Process Safety (CCPS) describes the technique as a semiquantitative methodology that works with a single cause-consequence pair per scenario and uses specific criteria to evaluate which safeguards may receive credit as Independent Protection Layers (IPLs).

The basic logic is straightforward: start from a previously identified scenario, estimate the frequency of the initiating event, and determine how much each independent layer reduces the probability that the scenario will progress to the consequence of interest. The result is compared with the organization’s risk criterion. If the existing reduction is insufficient, additional measures must be evaluated.

This apparent simplicity requires discipline. A technically weak LOPA may look quantitative while hiding dependencies, unsupported frequencies, double counting, and barriers whose reliability has not been demonstrated.

Where LOPA Fits Between HAZID, HAZOP, and QRA

HAZID identifies hazards broadly. HAZOP investigates process deviations in a structured manner. LOPA selects relevant scenarios and quantifies the effect of independent layers in orders of magnitude. A Quantitative Risk Assessment (QRA) can model frequencies, consequences, and risk in even greater detail, including spatial distribution, vulnerability, and multiple scenarios.

Method	Main focus	Nature
HAZID	Broad hazard identification	Qualitative/structured
HAZOP	Deviations, causes, consequences, and safeguards	Qualitative/structured
LOPA	Scenario frequency and IPL credit	Semiquantitative
QRA	Quantitative risk modeling	Quantitative

The choice depends on the decision. LOPA should not be used merely because a spreadsheet is available; it should be used when its level of detail is compatible with the uncertainty of the data and the significance of the decision.

Anatomy of a LOPA Scenario

A LOPA analyzes a defined chain. Conceptually, it includes:

• the consequence of interest;
• the scenario or accident sequence;
• the initiating event;
• enabling conditions, when applicable;
• independent protection layers;
• conditional modifiers, when applicable;
• the estimated mitigated frequency;
• the risk criterion or tolerable frequency;
• the need for additional risk reduction.

Not every scenario will have an enabling condition, a conditional modifier, or three IPLs. The diagram represents the logic, not a mandatory number of barriers.

The Scenario Must Be Specific

LOPA does not work well with vague descriptions such as “unit explosion risk.” The analysis must define a clear cause-consequence relationship.

A useful scenario should answer:

• what event initiates the sequence?
• under what operating condition?
• what loss of control occurs?
• what consequence is being evaluated?
• which protections act between the initiating event and the consequence?

When multiple causes have different frequencies or dependencies, it may be necessary to separate them into distinct scenarios rather than combine them arbitrarily.

Initiating Event

The initiating event is the failure, error, or condition that starts the propagation of the scenario. The frequency used must represent occurrence of the event in the analyzed context, rather than a number selected merely to simplify the calculation.

Initiating events may involve:

• failure of basic process control;
• equipment failure;
• human error;
• loss of a utility;
• improper opening or closing;
• valve failure;
• overpressure caused by a process condition;
• loss of cooling;
• loss of power;
• improper maintenance intervention.

The source of the frequency must be documented: corporate database, historical data, recognized literature, specific analysis, or a validated engineering criterion.

Initiating-Event Frequency Is Not Consequence Probability

A cause may occur without producing the final consequence because intermediate conditions and protection layers exist. Confusing initiating-event frequency with consequence frequency overestimates or underestimates risk.

The mathematical structure of LOPA represents precisely this sequence. In simplified form:

Mitigated frequency ≈ initiating-event frequency × applicable factors × PFD of credited IPLs.

This expression should not be used mechanically. Before multiplying factors, verify that they belong to the scenario, that there is no double counting, and that the layers are truly independent.

What Is an IPL?

An Independent Protection Layer (IPL) is a protection capable of preventing the scenario from progressing to the consequence of interest independently of the initiating event and of the other credited layers.

CCPS highlights attributes such as independence, functionality, integrity, reliability, auditability, access control, and management of change. This means that having a device or alarm shown on the P&ID is not enough to make it an IPL.

An IPL must have a defined function and sustained performance throughout its lifecycle.

Safeguard vs. IPL

Every IPL is a safeguard, but not every safeguard deserves credit as an IPL.

Situation	Can it be a safeguard?	Automatically an IPL?
Process alarm	Yes	No
Interlock in the same BPCS that causes the event	Yes	Generally not without an independence analysis
Properly designed relief valve	Yes	May be, depending on the scenario and criteria
Operating procedure	Yes	Not automatically
Independent SIF	Yes	May be, with demonstrated performance and independence
Containment wall	Yes	Depends on the consequence analyzed and the criteria

This distinction is central. Crediting every safeguard creates an artificial sense of safety.

Independence Between Layers

Two protections are not independent merely because they have different names. Dependencies may exist in sensors, logic, power supply, utilities, communications, final elements, maintenance, testing, configuration, or human action.

Example: an alarm and a trip that use the same transmitter may simultaneously lose their protective capability if that transmitter fails dangerously. Likewise, two systems supplied by the same circuit or dependent on the same network may share a common failure mode.

The analysis must ask what can defeat both layers at the same time?

Common Cause and Common Mode

Common-cause failures are particularly dangerous because they invalidate the assumption of simple multiplication between independent probabilities.

Sources of dependency may include:

• the same electrical power supply;
• the same instrument air;
• the same transmitter;
• the same control logic;
• the same final element;
• the same physical cable route;
• the same environmental condition;
• the same maintenance team or procedure;
• a replicated configuration error;
• a common bypass;
• a shared cybersecurity vulnerability.

LOPA governance must record these dependencies before granting credit.

Probability of Failure on Demand — PFD

PFD represents the probability that a layer will fail when its function is demanded, within the assumptions of the method used. In LOPA, PFD values are used to estimate the frequency reduction associated with IPLs.

Generic values should not be copied without verifying the conditions required to support them. Test frequency, diagnostic coverage, repair, maintenance, bypasses, architecture, competence, and management of change can affect actual performance.

For a Safety Instrumented Function (SIF), SIL verification is an engineering problem in its own right and should not be replaced by a fixed cell in a LOPA spreadsheet.

Enabling Conditions

An enabling condition is a condition that must be present for the initiating event to progress through the analyzed scenario, but it is not itself the initiating cause.

Examples may involve a specific operating step, the presence of material, a campaign mode, or equipment being in a particular state.

Improper use of enabling conditions can artificially reduce scenario frequency. They should be applied only when there is clear justification and no overlap with the initiating-event frequency itself.

Conditional Modifiers

Conditional modifiers represent probabilities associated with subsequent or complementary conditions in the scenario, such as personnel presence, ignition probability, or other factors when technically applicable.

Like enabling conditions, conditional modifiers require discipline to avoid double counting. CCPS has published specific guidance for these elements precisely because inconsistent use can significantly change the result.

How to Perform a LOPA

The process must be reproducible and auditable.

Select the Consequence

The consequence must be technically defined. The same cause may lead to different consequences and require separate scenarios.

Define the Initiating Event

The initiating cause must be consistent with the mechanism being analyzed. Duplicated frequencies or arbitrary aggregations compromise the analysis.

Identify Safeguards

First record the existing protections. Then evaluate which ones meet the criteria for an IPL. This order reduces the tendency to “force” a safeguard into the calculation simply because it was already mentioned in the HAZOP.

Compare with the Risk Criterion

The organization must have a documented criterion. The LOPA spreadsheet alone does not define what constitutes tolerable risk.

Conceptual Calculation Example

Consider, solely as a teaching example, an initiating event with a hypothetical frequency of 10⁻¹ per year. Assume there are two independent IPLs, each with a hypothetical PFD of 10⁻¹. Ignoring other factors in this example, the mitigated frequency would be on the order of:

10⁻¹ × 10⁻¹ × 10⁻¹ = 10⁻³ per year.

This example illustrates the logic of orders of magnitude; it does not provide standardized values for use in design. In a real study, every frequency, PFD, dependency, and condition must be technically justified.

Tolerability Criterion and Risk Gap

The LOPA result is useful only when compared with a defined risk criterion. If the estimated mitigated frequency remains above the criterion for the consequence, a risk-reduction gap exists.

This gap can be addressed through different strategies:

• eliminate or reduce the hazard through inherently safer design;
• reduce the initiating-event frequency;
• add or improve a protection layer;
• modify the process or inventory;
• improve segregation or containment;
• implement a SIF with the required SIL when appropriate;
• review operation or maintenance.

The decision should not automatically jump to “install a SIS.” The hierarchy of risk reduction and the feasibility of inherent or passive solutions should be considered first.

Relationship Between LOPA and SIL

One important application of LOPA is to help determine the risk reduction that must be provided by a safety instrumented function. CCPS recognizes the use of LOPA for this purpose, and IEC 61511 includes guidance for determining required safety integrity levels.

When a SIF is required, the resulting requirement must move into the Functional Safety lifecycle: definition of the function, safe state, trip conditions, response time, required SIL, independence, architecture, testing, operation, and management of change.

LOPA helps determine the requirement; it does not replace verification that the designed SIF actually meets that requirement.

Required SIL vs. Verified SIL

The required SIL results from the risk-reduction need assigned to a SIF. SIL verification evaluates whether the designed architecture and components can achieve the required performance, considering random and systematic failures according to the applicable method.

Mixing these two stages is a serious error: determining “SIL 2” in a LOPA does not prove that the implemented system is SIL 2.

BPCS and Independence

The Basic Process Control System (BPCS) performs normal process control. Depending on the scenario, a control function or alarm in the BPCS may be a useful safeguard. However, granting IPL credit requires evaluating independence from the initiating event and the other layers.

If a BPCS failure is the initiating event itself, using another function dependent on the same infrastructure to reduce the scenario may create improper credit.

Alarms and Operator Action

An alarm followed by human response does not automatically receive credit. It is necessary to evaluate whether:

• the condition is detected reliably;
• the alarm is distinguishable;
• there is enough time for diagnosis and action;
• the operator has a procedure and training;
• the action is physically executable;
• there is no alarm overload;
• the function is independent of the other credited layers;
• performance and testing are maintained.

In fast-moving scenarios, human response may simply be incompatible with the available time.

Relief Devices and Mechanical Protection

PSVs, rupture disks, containment systems, and other barriers can be extremely important, but credit depends on the consequence analyzed, capacity, independence, design, inspection, maintenance, and actual operating conditions.

A relief valve may prevent equipment overpressure and still fail to prevent another consequence, such as a hazardous discharge at an unsuitable location. The IPL must be evaluated against the specific scenario.

Safety Instrumented Systems

A SIF may act as an IPL when it has appropriate independence and performance for the scenario. The complete function normally includes a sensor, logic solver, and final element. Relying solely on individual component certification does not demonstrate the performance of the complete function.

In addition to the PFD calculation, the following must be governed:

• functional requirements;
• architecture;
• proof-test intervals;
• bypasses;
• detected and undetected failures;
• competence;
• configuration;
• validation;
• maintenance;
• Management of Change.

LOPA and Human Factors

Human error may appear as an initiator, condition, or protection element depending on the scenario. This requires care to avoid assigning artificial independence to actions performed by the same person, under the same operational pressure, and based on the same information.

The study should represent the actual work, not an idealized procedure.

LOPA in Brownfield Facilities

In existing plants, a common difficulty is crediting “design” IPLs that no longer exist in the documented form. Logic changes, bypasses, instrument changes, stuck valves, overdue tests, and documentation failures affect the validity of the assumptions.

Before crediting a layer, it may be necessary to physically verify:

• installed architecture;
• sensor and final element;
• power supply and utilities;
• logic and setpoints;
• physical and functional independence;
• test history;
• bypass condition;
• As-Built documentation.

This connects LOPA to Site Survey, Diagnostic Engineering, and recommissioning.

Management of Change

A LOPA contains assumptions that can lose validity after modifications. Increased capacity, a product change, a new operating mode, a setpoint change, valve replacement, software update, or a test-interval modification can change the frequency, consequence, or IPL performance.

The Management of Change process should identify which risk studies need to be revisited.

Documentation and Traceability

The LOPA record should allow the reasoning to be reconstructed. For each scenario, it is advisable to record:

• scenario origin;
• consequence analyzed;
• initiating event and frequency source;
• enabling conditions;
• conditional modifiers;
• identified safeguards;
• justification for credited IPLs;
• PFD and adopted source;
• dependencies evaluated;
• calculation result;
• risk criterion;
• reduction gap;
• recommendations;
• responsible parties and status.

Without this traceability, future reviews become exercises in reconstructing assumptions.

Data Quality

LOPA works with orders of magnitude, but that does not mean accepting arbitrary data. Uncertainty must be recognized and treated conservatively when necessary.

Mature governance defines authorized sources, criteria for proprietary data, update rules, treatment of missing information, and responsibility for approving assumptions.

Facilitation and Competence

The workshop should bring together process, operations, instrumentation, automation, maintenance, and safety knowledge appropriate to the scenarios. The facilitator must control the method and challenge improper credit.

For decisions that lead to SIL or SIS specification, the required competence increases. The organization should clearly define who determines the requirement, who verifies the calculation, who approves it, and who validates implementation.

Owner’s Engineering and Independent Review

Owner’s Engineering can act as a governance layer between the risk study, design, and supplier. This includes reviewing assumptions, ensuring consistency between HAZOP and LOPA, verifying that requirements migrated into specifications, supporting TBE and FAT/SAT, and controlling changes.

This role is different from supplying the Safety PLC or developing all application logic. The focus is on preserving the owner’s risk requirements throughout procurement and implementation.

LOPA in Procurement

When a recommendation results in a new system or modification, the procurement process must preserve the technical requirements. A generic RFP requesting a “SIL 2 system” without defining SIFs, interfaces, process conditions, proof tests, and responsibilities transfers ambiguity to the supplier.

Requirements originating from LOPA must be converted into engineering documentation and acceptance criteria.

FAT, SAT, and Validation

The existence of hardware compatible with a certain SIL does not close the lifecycle. Testing must demonstrate that implemented functions correspond to the requirements.

FAT and SAT can verify logic, sequences, diagnostics, failures, interfaces, and documentation. Functional Safety validation has its own requirements and should be planned according to the applicable scope, independence, and responsibilities.

Auditing IPLs During Operation

An IPL retains its credit only if its performance is sustained. Operational governance should control:

• proof tests and inspections;
• failures on demand;
• bypasses;
• pending repairs;
• configuration changes;
• alarm performance;
• spurious failures;
• process changes;
• maintenance competence;
• test evidence.

This monitoring closes the gap between “design LOPA” and the actual risk of the facility.

Recurring Errors in LOPA

The main problems are methodological, not arithmetic:

• overly broad scenarios;
• initiating frequency without a source;
• double counting of conditions;
• crediting safeguards that are not independent;
• ignoring common-cause failure;
• using generic PFD values without assumptions;
• crediting human action without adequate time and reliability;
• treating required SIL as verified SIL;
• failing to update the study after a change;
• closing recommendations without proof of implementation.

A spreadsheet can multiply numbers correctly and still produce the wrong conclusion if these assumptions are inadequate.

How Engineering Consulting Can Support LOPA

Consulting support can focus on method, facilitation, governance, and independent review. This includes preparing scenarios, organizing information, moderating workshops, checking IPL criteria, recording assumptions, integrating specialists, following up recommendations, and ensuring that resulting requirements reach design and procurement.

For A3A, this approach connects directly to Engineering Risk Management, Technical Consulting, Industrial Automation Design, Owner’s Engineering, and Commissioning, without confusing consulting with SIL certification or SIS supply.

LOPA Consulting Deliverables

A package may include:

• study plan and criteria;
• list of selected scenarios;
• controlled LOPA worksheets;
• frequency and PFD sources;
• IPL justifications;
• dependency records;
• mitigated-risk calculation;
• reduction gaps;
• recommendations;
• requirements for subsequent studies;
• action matrix;
• executive report and approval record.

Final Considerations

LOPA is a powerful tool because it forces engineering teams to make explicit why a protection deserves credit and how much risk remains after it acts. Its rigor lies less in mathematical sophistication than in the quality of the assumptions, the independence of the layers, and lifecycle governance.

When integrated with HAZID, HAZOP, SIL, automation design, Procurement, and commissioning, LOPA turns risk scenarios into traceable requirements. This linkage is essential so that the risk reduction defined in the study continues to exist after the design moves through suppliers, construction, testing, operation, and change.

Technical References

[1] CENTER FOR CHEMICAL PROCESS SAFETY (CCPS). LOPA Data — What is LOPA. New York: AIChE. Available at: https://ccps.aiche.org/resources/tools/lopa

[2] CENTER FOR CHEMICAL PROCESS SAFETY (CCPS). Layer of Protection Analysis: Simplified Process Risk Assessment. New York: AIChE, 2001. Available at: https://ccps.aiche.org/publications/books/layer-protection-analysis-simplified-process-risk-assessment

[3] CENTER FOR CHEMICAL PROCESS SAFETY (CCPS). Guidelines for Enabling Conditions and Conditional Modifiers in Layers of Protection Analysis. New York: AIChE, 2013. Available at: https://ccps.aiche.org/publications/books/guidelines-enabling-conditions-and-conditional-modifiers-layers-protection-analysis

[4] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 61511-1:2016+AMD1:2017 CSV — Functional safety — Safety instrumented systems for the process industry sector — Part 1. Geneva: IEC. Available at: https://webstore.iec.ch/en/publication/61289

[5] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC TR 61511-0:2018 — Functional safety for the process industry and IEC 61511. Geneva: IEC. Available at: https://webstore.iec.ch/en/publication/60766

[6] INTERNATIONAL SOCIETY OF AUTOMATION. ISA-84 Series of Standards. Research Triangle Park: ISA. Available at: https://www.isa.org/standards-and-publications/isa-standards/isa-84-standards

Frequently Asked Questions

What is LOPA?

LOPA is Layer of Protection Analysis, a semiquantitative methodology that evaluates a specific scenario, its initiating frequency, and the independent protection layers to estimate the mitigated frequency of the consequence.

What is the difference between a safeguard and an IPL?

A safeguard is any measure that contributes to risk reduction. An IPL is a safeguard that meets additional criteria for independence, functionality, integrity, reliability, and auditability and may receive quantitative credit in LOPA.

Is LOPA a quantitative analysis?

It is generally classified as semiquantitative. It works with frequencies and probabilities in orders of magnitude using simplified rules, placing it between qualitative analyses and a detailed QRA.

Can LOPA be used to determine SIL?

It can be used to determine the additional risk reduction required and, when that reduction will be provided by a SIF, support determination of the required SIL. This does not replace subsequent SIL verification of the designed function.

Can an alarm be an IPL?

It may be part of a creditable layer under specific conditions, but not automatically. Independence, detection, response time, operator action, training, auditability, and other applicable criteria must be evaluated.

When should LOPA be reviewed?

It should be reevaluated when changes in process, capacity, setpoints, instruments, logic, testing, equipment, or operating conditions may alter scenario assumptions or layer performance.

Additional Technical Materials

Related Solutions

• Digital Supervision and Control Systems (SDSC): automation and integrated operations

Related Services

• Technical Engineering Consulting: diagnosis, strategy, and decision support
• Engineering Risk Management: identification, analysis, mitigation, and contingency
• Industrial Automation Design: control, supervision, OT networks, and integration
• Engineering Commissioning: planning, testing, readiness, and handover

Key Content on the Topic

• HAZID in Engineering: Hazard Identification, Methodology, and Application in Industrial Projects
• HAZOP in Engineering: Methodology, Guide Words, and Process Deviation Analysis

Related Technical Content

• Bow Tie in Engineering: Causes, Top Event, Consequences, and Control Barriers
• Risk Analysis in Engineering Projects: Methods, Criteria, and Prioritization