Jarsis Platform
Compliance10 min read

Digital permit to work: HSE HSG250 buyer's guide

Most "permit to work" software is a fancy form. HSG250 expects more than that, and an HSE inspector is unlikely to accept "the system did not let us record it that way" as an answer.

HSE's HSG250 ("Guidance on permit-to-work systems") was not written for software vendors. It was written for the engineers, supervisors, and managers who actually issue permits, and for the inspectors who turn up after something has gone wrong. Reading it as a software requirements document tells you a lot about why most digital permit systems would not survive a real incident investigation.

What HSG250 actually requires

The guidance is built around a few load-bearing principles. Hazards must be identified. Controls must be put in place before work starts. Authorisation must be explicit, in writing, by someone competent. Issuing, acceptance, and handback must be separate acts by separate people where practical: separation of duties is not negotiable. Isolation of hazardous energies must be tracked, padlocked, and tagged. Communication of the permit content to the people doing the work must be evidenced. The whole thing must be auditable for years afterwards.

None of this is exotic. It is what any competent permit process does on paper. The question is what it looks like when the paper becomes a tablet in a plant room with no signal.

Where most permit software falls short

The most common shortfall is treating the permit as a document rather than a state machine. A real permit moves through a defined lifecycle: drafted, issued, accepted, active, suspended, completed, handed back, closed. Each transition has rules about who can do it and what evidence is required. Software that treats the permit as a form to be filled in once usually fails to enforce the lifecycle, and the audit trail becomes a sequence of timestamps with no semantic meaning.

The second is hand-waving on separation of duties. HSG250 is explicit: the issuer, acceptor, and authoriser should generally be different people. Software that allows one user to play all roles, or that has a configurable "skip this step" toggle, is failing the standard in a way an inspector will notice. Hard-coding separation of duties is one of the few places where opinionated software earns its keep.

The third is isolation tracking. A real permit may have multiple isolations, each with its own lockout-tagout, each with its own competent person, each with its own restoration checklist. Software that models isolations as a single text field cannot reproduce what was actually isolated when the inspector asks. Structured isolation points, mapped against an asset register, are the difference between a defensible permit and a story.

The fourth is the qualification check. The acceptor needs to be competent for the work being done. Hot work needs a hot work qualification; confined space needs a confined space qualification; high-voltage isolations need an authorised person. Software that does not check qualifications automatically is asking a supervisor to remember, which is exactly where competence-related incidents start.

The eight permit types you actually need

Most operational sites need a defined set of permit types, each with its own controls. The eight that cover the majority of UK estates and FM operations are: hot work, confined space entry, electrical isolation, working at height, excavation, line-breaking, energised electrical work, and general permit (a catch-all for work that needs authorisation but does not fit a specialist category).

Each of these has different rule-driven determinations. Hot work near combustibles needs fire-watch arrangements. Confined space entry needs atmospheric monitoring records. Electrical isolation needs structured isolation points mapped to the affected circuits. A permit platform that models these as variations on a single form is going to fail the first regulator audit.

Mobile and offline support

A permit lives where the work lives. That is usually a plant room with concrete walls, a basement with no signal, or a roof with intermittent connectivity. A permit platform that requires online connectivity to issue or accept a permit is going to be bypassed, which means paper, which means the system you spent six figures on is not the system of record. Offline-first mobile, with synchronisation when signal returns, is the bar.

Offline-first does not mean offline-forever. The synchronisation has to handle conflicts cleanly: two acceptors on the same permit, signature timestamps that disagree, evidence photos that arrive after the close-out. These are solvable, but they need to be designed for from day one, not retrofitted.

Audit trail considerations

A defensible audit trail is forensic. Every state transition recorded with the actor, the timestamp, the action, and any associated evidence. Photos hash-fingerprinted so they can be proven not to have been edited after the fact. Signatures captured with enough metadata that they can be challenged and defended. Retention long enough to cover the longest plausible investigation window, which for some industrial incidents can be years.

The audit trail should be queryable from day one. If your response to a regulator request is "we will need three weeks to extract that data," you have already lost.

Integration with PPM and compliance

A permit does not exist in isolation. It is usually issued against an asset, sometimes triggered by a planned maintenance task, often connected to a compliance certificate that has expired and triggered the work in the first place. A permit platform that lives separately from the PPM and compliance systems creates duplicate data and broken trails.

The integration that matters is bidirectional. A PPM job that requires a permit cannot start until the permit is issued and accepted. A permit that closes should automatically progress the PPM job. A compliance certificate that was the trigger should link back to the permit so the audit trail is complete.

What to ask a vendor

The questions to put in front of any permit-to-work vendor are simpler than most evaluation matrices admit. Show me separation of duties enforced by the platform, not the process. Show me an isolation with three structured isolation points and the corresponding LOTO tags. Show me a permit accepted by an operative without an up-to-date qualification, and show me what happens. Show me the audit trail of a closed permit from three years ago, on screen, in under a minute. Show me what the same permit looks like on a tablet with the WiFi turned off.

The vendors who can do all of those usually do permits seriously. The ones who deflect on any of them are shipping a digital form.

See HSG250-aligned permits in practice

The Jarsis Permit to Work module was built to HSG250 from the ground up, with hard-coded separation of duties, structured isolation points, and a forensic audit trail. Book a 30-minute walkthrough.