The Process Safety Lifecycle — From HAZID to ALARP

Introduction

Ask an engineer to list the process safety studies on a project and you will get a familiar pile: HAZID, HAZOP, LOPA, SIL determination, the cause-and-effect matrix, a bow-tie or two, and somewhere at the end an ALARP statement. Treated as a checklist of deliverables to be ticked off, they generate a lot of paper and surprisingly little safety.

Treated correctly, they are a single chain. Each study takes the output of the one before, sharpens it, and hands it to the next. Hazards identified early are examined in detail, the detail is turned into quantified risk, the risk drives the integrity of the protective functions, those functions are realised in hardware and logic, and the whole thing is finally tested against the question that actually matters to a regulator and to the people on the facility: is the residual risk as low as reasonably practicable?

This post sequences that chain end to end and links to the detailed treatment of each step. It is the spine of our safety work; the individual posts are the vertebrae.

The Lifecycle at a Glance

The chain runs broadly like this, early-concept to operations:

1. HAZID — identify, broadly, what can go wrong while the design is still fluid.
2. HAZOP — examine the developed design line by line to find how deviations arise.
3. LOPA — for the scenarios that matter, quantify the risk and the protection gap.
4. SIL determination — turn that gap into an integrity target for each safety instrumented function.
5. Functional safety management (IEC 61511) — design, verify, and maintain those functions across the lifecycle.
6. Cause-and-effect matrices — capture the resulting trip logic in an auditable, implementable form.
7. Bow-tie analysis — communicate the barriers and check none are missing or shared.
8. ALARP demonstration — prove the residual risk is as low as reasonably practicable.

The order is not arbitrary: each step needs the maturity of design information that the previous steps have helped produce. Run them out of sequence — a SIL workshop before a HAZOP, say — and you are quantifying hazards you have not yet properly identified.

Step 1 — HAZID: Casting the Net Wide

A hazard identification (HAZID) study comes first because it is the only study cheap and fast enough to run while the concept is still moving. It casts a wide net — external hazards, layout, escape, dropped objects, environment — and is deliberately qualitative. Its purpose is to make sure no major hazard category is missed before the design hardens around it.

The distinction between this broad early screen and the later, structured, design-specific examination is worth getting straight; HAZOP vs HAZID lays out exactly what each is for and why you need both. HAZID feeds the design basis and the early FEED safety concept; its findings are the raw material the HAZOP later examines in detail.

Step 2 — HAZOP: Examining the Design in Detail

Once the P&IDs are developed, the HAZOP takes over. Working node by node with guidewords (no flow, more, less, reverse, as well as, other than), a multidisciplinary team systematically asks how each parameter can deviate, what causes it, what the consequence is, and what safeguards exist. It is the single most important hazard study on most facilities — which is why the importance of HAZOP and the practicalities of running an effective HAZOP each get their own treatment.

The HAZOP does two jobs for the chain that follows. It confirms or closes out the HAZID hazards in the context of the real design, and it produces the scenarios with inadequate safeguards — the ones where the team is not satisfied that existing protection is enough. Those scenarios are precisely the input to LOPA.

Step 3 — LOPA: Quantifying the Gap

A layer of protection analysis (LOPA) takes a HAZOP scenario that looks under-protected and puts numbers on it. It estimates the initiating-event frequency, credits each independent protection layer (IPL) for its probability of failure on demand, and compares the resulting mitigated frequency against a tolerable risk target. If a gap remains, LOPA quantifies how much additional risk reduction is needed.

That required risk reduction is what sets the integrity of any new safety instrumented function. LOPA is the hinge of the whole chain — the point where qualitative hazard work becomes a quantified requirement — and it is covered together with the integrity step in SIL determination using LOPA.

Step 4 — SIL Determination: From Risk Gap to Integrity Target

The risk-reduction factor that LOPA produces translates directly into a Safety Integrity Level (SIL 1 to SIL 4) for each safety instrumented function. SIL 1 buys roughly a factor of 10–100 of risk reduction, SIL 2 a factor of 100–1,000, and so on. The higher the SIL, the more demanding the requirements on the sensor–logic–final-element loop: redundancy, diagnostic coverage, proof-test intervals, and architectural constraints all tighten.

Determining the SIL is the output of LOPA; delivering and sustaining it is the next step.

Step 5 — Functional Safety Management: Delivering and Keeping the SIL

A SIL target is a promise about performance over the whole operating life — and a promise is worthless without the management system to keep it. Functional safety management under IEC 61511 is the lifecycle discipline that turns the SIL number into reality: the safety requirements specification, the verification calculations, the validation testing, the competence and management-of-change controls, and the proof-test regime that keeps the function meeting its target year after year.

This is where many facilities quietly fail. A function designed to SIL 2 but proof-tested late, modified without assessment, or staffed by people who do not understand its basis is no longer SIL 2 — it has degraded silently. Functional safety management exists to stop that drift.

Step 6 — Cause-and-Effect Matrices: Making the Logic Auditable

The trips and interlocks that emerge from HAZOP, LOPA, and SIL work have to be captured in a form the control-system engineers can implement and everyone can audit. The cause-and-effect matrix is that form: a grid mapping every initiating cause (a row) to every protective effect (a column), with a mark at each intersection that should fire.

The matrix is the bridge between the safety analysis and the executed logic in the SIS and DCS. It is also the document a HAZOP or SIL finding ultimately lands in — which is why a thermal-relief or trip recommendation always ends "…and reflect it in the cause-and-effect matrix."

Step 7 — Bow-Tie Analysis: Seeing the Barriers Whole

Where the cause-and-effect matrix is about logic, the bow-tie is about communication and barrier integrity. It places a single top event at the centre, threats and their preventive barriers on the left, consequences and their mitigating barriers on the right. It makes visible, to operators and management as well as engineers, exactly what stands between a threat and a major accident.

The bow-tie is also an integrity check on everything upstream: it exposes barriers that are weak, missing, or — most dangerously — shared between several threats so that one common-cause failure removes protection from multiple scenarios at once.

Step 8 — ALARP: Proving the Residual Risk Is Tolerable

Finally, the chain has to answer the regulator's question. Identifying hazards, quantifying risk, and installing barriers is not enough; you must demonstrate that the residual risk has been driven as low as reasonably practicable — that every further risk-reduction measure has been considered and adopted unless its cost is grossly disproportionate to the benefit. ALARP demonstration in practice covers how that argument is actually built and evidenced, including the gross-disproportion test and the role of good practice.

ALARP is not a separate study bolted on at the end. It is the conclusion the whole lifecycle exists to support — each earlier step is part of the evidence that the risk is tolerable and that reasonable measures have been taken.

Worked Example — Tracing One Scenario Through the Chain

Scenario (illustrative): a high-pressure separator that can be over-pressured if its gas outlet control valve fails closed while inflow continues.

1. HAZID flags "vessel overpressure" as a major hazard category for the separation package — broad, early, no detail yet.
2. HAZOP, on the gas-outlet node, applies the guideword no flow: cause = control valve fails closed; consequence = separator pressure rises toward and past design; safeguard = relief valve. The team judges relief alone insufficient given the consequence and records the scenario for LOPA.
3. LOPA estimates the control-valve-failure frequency, credits the operator response and the PSV as IPLs, and finds the mitigated frequency still an order of magnitude above the tolerable target — a required risk reduction of ~100.
4. SIL determination converts that factor of 100 into a SIL 2 high-pressure trip on the separator (the same logic that, taken further, justifies a HIPPS and can reduce the relief and flare load).
5. Functional safety management writes the safety requirements specification for that SIL 2 function, sizes the proof-test interval to hold the PFD, and puts it under management of change.
6. The cause-and-effect matrix records: row "separator PT high-high" → columns "close inlet ESDV", "open blowdown", "alarm" — the implementable logic.
7. The bow-tie shows the SIL 2 trip and the PSV as two independent preventive barriers against the "loss of containment from overpressure" top event, and confirms they do not share a common cause.
8. The ALARP demonstration records that the trip, the relief valve, and the procedural controls together drive the risk into the tolerable region, and that no further reasonably practicable measure was identified.

One scenario, eight studies, each handing a sharper version of the same problem to the next. That continuity — not the existence of the individual documents — is what process safety actually is.

Common Pitfalls

• Running the studies out of order. A SIL workshop before a competent HAZOP, or an ALARP statement before the LOPA, quantifies and concludes on hazards that have not been properly identified.
• Treating each study as a standalone deliverable. The value is in the chain. If the HAZOP actions never reach the LOPA, or the SIL never reaches the cause-and-effect matrix, the paperwork exists but the protection does not.
• Claiming IPLs that are not independent. LOPA credit and bow-tie barriers both collapse if two "independent" layers share a sensor, a logic solver, or a power supply. Independence is the assumption that breaks most often.
• Setting a SIL and forgetting it. A SIL is a lifecycle promise. Without the functional safety management — proof testing, MoC, competence — the integrity degrades silently after handover.
• Writing ALARP as a formality. ALARP is an argument that must show measures were genuinely considered and adopted unless grossly disproportionate — not a closing paragraph asserting the risk is acceptable.
• Stale cause-and-effect matrices. When trip logic is changed in the field but the matrix is not updated, the auditable record diverges from the executed logic — a classic management-of-change failure.

Conclusion

The process safety lifecycle is one argument built in stages: here are the hazards (HAZID), here is how they arise in this design (HAZOP), here is how big the risk is and what protection it needs (LOPA/SIL), here is how we deliver and keep that protection (IEC 61511, C&E), here are the barriers laid out (bow-tie), and therefore here is why the residual risk is tolerable (ALARP). Each step is only as good as the one feeding it, and the conclusion is only as good as the weakest link in the chain.

Follow the linked posts for the detail on each step. If you need a HAZOP chaired, a LOPA and SIL study delivered, or an ALARP case built and defended, get in touch — independent, experienced process safety facilitation is one of the things we do.