An isolation point rarely serves one job. On a live asset running several permits at once, the same valve, spade, or breaker often sits underneath work that has nothing to do with each other on paper — a vessel entry, an instrument calibration, a hot work job on adjacent pipework. Each permit references the isolation. Only one of them, usually, actually controls it.
That's where isolation management in a multi-permit environment tends to break down. Not because anyone removes a lock carelessly, but because the isolation register doesn't tell anyone else that removing it matters to a job they can't see.
What a shared isolation point actually means
A shared isolation point is a single point of isolation — a valve, spade, blind, breaker, or locked-off circuit — that more than one active permit relies on to make its work area safe. Isolation management in this context means tracking not just that the isolation is in place, but every permit currently depending on it staying that way, and controlling who can authorise a change to its status.
Most isolation standards and lockout tagout guidance are written around a single job: isolate, verify, lock, tag, do the work, de-isolate, remove the lock. HSG250 and the isolation principles that sit behind most operators' Control of Work procedures assume that structure. It holds up well until two or more permits are drawing on the same isolation certificate at the same time, and one of them finishes before the others.
Where visibility fails between permits
On assets running a high volume of concurrent permits, the isolation register is often held by whichever team requested the isolation first. A second permit gets written against the same isolation certificate — correctly, because it is the same physical point — but the person accepting that second permit may never see the first. If the isolation register isn't linked to the permit system, there's no reliable way for the Area Authority to know how many live permits currently depend on a given lock before deciding whether it's safe to break it.
We've written before about why isolation is usually where permit to work breaks down, and shared isolation across simultaneous permits is one of the sharper versions of that problem. It isn't that isolation itself is poorly understood on most assets — it's that isolation status stops being visible the moment it needs to be shared across more than one job.
The specific failure modes worth naming
A handful of situations recur wherever isolation points are shared and status isn't visible across all active permits:
- **Premature de-isolation** — a crew completes their scope, closes their permit, and reinstates the isolation because their paperwork shows no reason not to, while a second permit elsewhere still depends on the point staying isolated.
- **Conflicting isolation certificates** — two isolation certificates get raised against the same point by different teams, each unaware of the other, because the register wasn't checked or wasn't current.
- **Bypassed or removed locks** — a lock is removed to allow limited access for testing or verification, on the understanding it will be reinstated immediately, and the second job proceeds on the assumption the isolation is still intact.
- **Handover gaps** — an isolation's dependent permits are recorded correctly at the start of a shift, but the incoming shift inherits a written record rather than a live one, and a change made mid-shift doesn't reach everyone relying on it.
None of these require anyone to act outside procedure. They happen where the procedure is sound but the record it depends on is fragmented — a paper isolation register in one office, a permit board in another, and no single place that shows both together.
What isolation management needs to do differently
An isolation register that actually supports a multi-permit site needs to answer one question at any moment: which live permits currently depend on this isolation, and who authorised each of them to rely on it. That means every isolation certificate is linked, not just referenced, to each permit drawing on it — so accepting a new permit against an existing isolation automatically registers that dependency, rather than relying on the permit writer to check a separate log.
It also means a change to isolation status — removing a lock, breaking a spade, reinstating power — triggers a check against every linked permit before it happens, not after. Some operators achieve a version of this manually, through disciplined handover and a single controlled isolation log held by one authority. On assets with a lower volume of simultaneous work, that can work well. Where permit volume and isolation reuse both increase, the manual version starts to depend on someone remembering to check a register that isn't in front of them.
Ownership matters as much as visibility. Whoever accepts responsibility for breaking an isolation needs the authority to see every dependent permit, not just the one in front of them — which usually means that decision sits with an Area Authority or equivalent role with cross-permit visibility, rather than the last person to raise a permit against that point.
Testing your own process
A few practical checks tend to expose whether isolation management is genuinely centralised or just distributed across separate logs:
- Ask whether your isolation register shows every live permit linked to a given isolation certificate, or only the one that requested it.
- Try to trace, for a specific lock currently in place, exactly which permits depend on it and who accepted each one.
- Check what happens procedurally if someone attempts to close out an isolation while a dependent permit is still open — does the system stop it, or does it rely on someone noticing.
- For electrical isolations specifically, confirm the process for verifying dead before work starts is recorded against the same isolation record every dependent permit references, not a separate test certificate. We've covered the detail of when live working is genuinely permitted in electrical permit to work, which sits on the same fault line — isolation confidence that one job's paperwork can't fully verify on its own.
If you're evaluating permit to work software with this specific gap in mind, it's worth asking a vendor to demonstrate shared isolations directly rather than taking a feature list at face value — our buyer's guide to permit to work software sets out some of the other questions worth putting to a vendor during that process.
Isolation management in a multi-permit environment isn't a different discipline from single-job isolation — it's the same discipline under conditions where the register has to work for more than one job at a time. Most of the failure modes above trace back to a register that was designed, quite reasonably, before that requirement existed. If you're reviewing how isolation status is tracked across concurrent permits on your asset, we're happy to walk through the current process with your operations team and identify where the gaps in visibility actually sit.