LOPA revalidation is the review that re-opens a completed layer of protection analysis and checks it against current conditions, meaning current process design, current protection layers, and the current P&ID revision. It happens when the basis the study was built on changes, or on the periodic cycle the operating company's procedure sets, commonly tied to the site's PHA revalidation programme. A management of change to the process or a protection layer, a new or modified SIF, an incident that reveals a scenario the original study did not consider, a change to a credited independent protection layer, and the scheduled cycle itself are the trigger classes that put a completed LOPA back on the table.
A LOPA is a snapshot. It describes one hazard scenario, the protection layers credited against it, and the P&ID revision the study was built on, all at a single point in time. Change any of those and the study quietly stops describing the plant it was written for.
Key takeaways
- A LOPA is tied to one scenario, one set of credited IPLs, and one P&ID revision. Any of the three can go stale on its own.
- Revalidation is triggered by an MOC, a new or modified SIF, an incident or near-miss, a change to a credited IPL, or the operating company's periodic PHA revalidation cycle.
- Not every MOC triggers a full revalidation. The MOC procedure's own screening step decides.
- No universal interval applies across every site. The operating company's procedure and the applicable regulation set the cycle.
- A revalidation is only as good as the drawing it is checked against. A superseded P&ID revision, or an IPL removed on a later revision and never traced back, invalidates the exercise even when the calculation itself is untouched.
Trigger classes that put a LOPA back on the table
| Trigger | What changed | Why the LOPA no longer holds |
|---|---|---|
| MOC to process or protection layer | Equipment, setpoint, or protective device modified | The scenario or a credited IPL may no longer match the installed plant |
| New or modified SIF | A safety instrumented function added, removed, or reallocated to cover the scenario | The risk gap the LOPA calculated may now be covered differently, or not covered at all |
| Incident or near-miss | An event exposes a cause or consequence path the original team did not consider | The scenario list itself was incomplete, so the LOPA answered a narrower question than the plant needed |
| Change to an assumed IPL | An interlock defeated, a relief device re-rated, an alarm reclassified or removed | Credit was taken for a layer that no longer provides the risk reduction the study assumed |
| Consequence or receptor change | Occupancy, inventory, or nearby equipment shifts the severity of the outcome | The consequence category the scenario was scored against has moved |
| Periodic cycle | The interval set by the operating company's procedure, commonly tied to the PHA revalidation programme, elapses | Even with no known trigger, the plant has drifted enough over the interval to need re-confirming |
Not every trigger on that list reaches a full revalidation. The screening step built into the MOC procedure is what decides, and a change that never touches the scenario, the initiating cause, or a credited layer usually closes without one. A change to a device or setpoint the LOPA specifically relied on almost always does.
A SIF added to cover a scenario is the clean case, where the chain from a HAZOP recommendation through LOPA to a SIF on the I/O list runs forward and the new function shows up where it should. The harder case is a SIF or IPL that was quietly removed, re-rated, or reallocated after the LOPA was filed, with nothing forcing anyone to go back and check whether the study still holds.
What a revalidation is checked against
The math in a LOPA calculation is the part that gets the attention. The part that decides whether the revalidation means anything is the document set it is checked against, and that part is skipped as often as it is done properly.
A revalidation that confirms the credited layers are correct, using a P&ID revision the site superseded several revisions ago, has confirmed nothing. If an IPL credited in the original study was removed on a later revision and the LOPA was never reopened, the study has been silently invalid since the day that revision was issued, not since the day someone noticed. If the SIF register and the I/O list disagree about which points belong to which safety function, the revalidation team is working from two different pictures of the same plant and has no way to know which one is current. Reconciling the document set is not a formality that happens after the revalidation. It is the precondition for the revalidation meaning anything at all.
Reconcile before revalidating
| Item | Where it lives | The drift that bites |
|---|---|---|
| P&ID revision cited in the LOPA | The LOPA worksheet's reference field | The current issued revision has moved on, so the scenario or an IPL the study describes may already be superseded |
| SIF or SIS register | The safety function register maintained alongside the safety requirement specification | A SIF added or retired since the last LOPA doesn't appear in either document, so the credited layer count is wrong |
| I/O list signal class and rack assignment | The I/O list, cross-referenced to the SIL-rated I/O list | A trip point migrated to a shared or reassigned card, undermining the independence the IPL credit assumed |
| Alarm rationalization status | The alarm database and rationalization record | An alarm credited as an IPL in the LOPA was later reclassified or removed, and the LOPA that credited it was never reopened |
| As-built instrumentation | Field walkdown records against the P&ID | A device the LOPA relies on for a protection layer was replaced or relocated without the drawing catching up |
The alarm-as-IPL case
This is the trigger that gets missed most often because nothing about it looks like a safety event. An alarm with a defined operator response and adequate time to act can be credited in a LOPA as an independent protection layer. Years later, an alarm rationalization pass goes through the alarm database, and that same alarm gets reclassified as informational, or removed outright, because on its own it looked redundant or nuisance-prone. The rationalization work is correct on its own terms. What it misses is that the alarm was carrying weight in a risk calculation nobody consulted before making the change, and the LOPA that credited it is never reopened. The scenario the study addressed is now less protected than the study on file says it is, and the gap is invisible until someone pulls the original worksheet during an audit or an incident review.
Keeping the record current between revalidations
None of this is solved by revalidating more often. It is solved by keeping the P&ID, the SIF register, the I/O list, and the alarm database in agreement as each one changes, so that whenever a revalidation is triggered, whether by an MOC, an incident, or the scheduled cycle, the team is checking the study against a document set that actually describes the plant. A P&ID revision that carries its own change history, cross-referenced against an I/O list that still names the SIF each safety point belongs to, turns that check into a short reconciliation instead of a document hunt through years of superseded drawings. The LOPA reference covers the calculation itself, and the SIL reference covers the integrity level a revalidated SIF is held to.