On most assets, the permit to work is issued from one system, the isolation certificate comes from another, the SIMOPS assessment lives in a spreadsheet someone updates when they remember to, and the shift handover happens verbally, backed by a logbook entry that summarises the picture rather than reproducing it. Each of these processes is usually sound on its own terms. The gaps tend to show up between them.
Digital control of work, in the way operators are increasingly asking for it, isn't really about replacing paper with a screen. It's about whether the relationships between permits, risk assessments, isolations and concurrent activity are things the system actively tracks, or things an Area Authority has to reconstruct by cross-referencing several sources under time pressure.
Where the connections actually break
A permit issuer approves a permit that references an isolation certificate by number. The isolation itself, though, sits in a separate register. If that isolation is later amended, partially deferred, or extended past its original scope, nothing necessarily tells the permit holder or the person about to accept the next shift's permit. The reference between the two documents exists on paper or in two disconnected database tables, not as a live dependency the system enforces.
The same pattern shows up with simultaneous operations. Two crews working within line of sight of each other — one doing hot work, the other opening a confined space nearby — should be visible to whoever is assessing SIMOPS risk. On assets running a high volume of concurrent permits, particularly during a shutdown or turnaround, that visibility often depends on someone manually checking the active permit list against a plan drawn up the day before, rather than the system flagging the conflict as it arises.
Risk assessment as a static document rather than a live input
A task risk assessment is usually completed at the planning stage and attached to the permit. What it doesn't always do is get revisited when circumstances change mid-shift — an isolation gets added, a nearby permit is extended, or a piece of work runs longer than planned and now overlaps with an activity it wasn't assessed against. Where the risk assessment is a document rather than something linked to current permit and isolation status, it reflects the plan rather than the live state of the asset.
Shared isolations and the point where SIMOPS assessments fail quietly
We've written before about why isolation is usually where control of work breaks down, and shared isolations are a good example of why. Where a single isolation supports several live permits, removing it requires knowing that every dependent permit has been closed or suspended first. On a system that treats isolations and permits as separate records with a manual cross-reference, that check relies on someone remembering to look, or on a register that's updated after the fact rather than in real time.
Handover is where a disconnected system shows itself first
Shift handover is usually where the cumulative effect of disconnected systems becomes visible fastest. An incoming OIM or Area Authority needs the full current picture — live permits, their status, associated isolations, any SIMOPS conflicts, anything suspended or extended overnight. If that picture is spread across a permit system, an isolation register, a SIMOPS spreadsheet and a handover log, reconstructing it accurately depends on the outgoing shift's memory and diligence rather than on the system presenting it directly.
A reasonable test of any control of work system, digital or otherwise, is whether it can show a permit spanning a shift change with its full status intact — not just that the permit exists, but what was true about it, its isolations, and any related activity at the moment of handover.
What to check when evaluating a connected system
Rather than asking a vendor to describe how their system connects permits, isolations and SIMOPS, it's more useful to ask them to demonstrate it. Some things worth asking to see directly:
- What happens when someone attempts to remove an isolation while a dependent permit is still live
- How the system flags a SIMOPS conflict between two permits raised independently, without a person manually cross-checking
- The historical state of a permit that's been amended, not just its current version
- How a suspended or extended permit is represented, and whether that status is visible to anyone relying on the associated isolation
- How a permit's full status is presented to an incoming shift, rather than summarised secondhand
Our buyer's guide to permit to work software goes into more of these evaluation questions if you're at that stage of a review.
What's required, what's recommended, and what's just how it's usually done
HSG250 sets out principles for effective permit-to-work systems, including the coordination of isolations and the assessment of simultaneous operations. It doesn't specify a software architecture, and it doesn't require permits, isolations and SIMOPS assessments to be held in a single connected system rather than separate ones cross-referenced manually. That's a design choice, not a legal specification.
What's changed is the volume most assets are trying to manage this way. Manual cross-referencing between separate registers works reasonably well at low permit volumes. It becomes harder to sustain reliably as concurrent permit numbers rise during a turnaround, or as an asset's control of work activity simply grows more complex over time.
If part of what you're reviewing at the moment is where your current control of work process relies on someone manually joining up permits, isolations and SIMOPS assessments, we can work through the existing workflow with your operations team and look at where that connection could sit in the system instead of in someone's head.