An auditor doesn't usually ask whether you have a permit-to-work system. They ask whether you can reconstruct, months later, exactly what was authorised, by whom, under what conditions, and what changed along the way. That's a different question, and a surprising number of control of work software platforms fail it quietly, not because the record doesn't exist, but because it can't be produced in a form that proves anything.
This matters more as control of work moves from paper and spreadsheets to computer based permit to work systems, because digitisation on its own doesn't guarantee auditability. A system can be fully digital and still leave gaps that a paper-based process, for all its faults, sometimes closed by accident, through a signature, a timestamp written in the margin, a physical copy filed by hand.
What 'audit-ready' is actually being tested against
HSG250 sets out HSE's guidance on permit-to-work systems. It isn't prescriptive about software, and it doesn't mandate a particular audit trail format. What it does describe, consistently, is the need for a system that demonstrates control: clear authorisation, competent acceptance, defined scope, and a record of how the work was closed out. Guidance is not the same as legal requirement, and it's worth being precise about that distinction when evaluating a vendor's claims. What HSG250 gives you is a reasonable basis for what good practice looks like, which is usually the standard an internal or external audit will measure against even where it isn't cited directly.
The practical test of an auditable control of work system isn't whether it stores a record. It's whether that record can show its own history. Ask a vendor to pull up a permit that was amended twice during a shift, suspended overnight, and reinstated the next morning. If the system can only show you the final state, it hasn't given you an audit trail. It's given you a result.
Isolation sign-off is usually where this breaks down first
We've written before about why isolation is the weak point in permit to work, and it's worth repeating here in an audit context specifically. Isolation certificates often sit in a separate register from the permits that depend on them, which means proving that an isolation remained in place for the full duration of dependent work can require cross-referencing two systems that weren't designed to talk to each other.
A genuinely auditable system should let you select an isolation certificate and see, without manual reconciliation, every permit that depended on it, when each was raised and closed, and whether any attempt was made to remove the isolation while a dependent permit was still live. If that attempt happened and was blocked, the system should show that too. An audit trail that only records successful actions and silently drops the ones that were prevented isn't giving you the full picture, it's giving you a curated one.
Evidence capture and reporting aren't the same test
Many control of work platforms are strong on reporting: dashboards, KPI exports, permit volumes by area. That's a useful operational tool, but it isn't evidence capture, and conflating the two is a common mistake when evaluating software against audit readiness. Reporting tells you what the system currently shows. Evidence capture tells you whether what it shows can be trusted not to have been altered after the fact.
A reasonable thing to ask a vendor to demonstrate: retrieve a permit that's over a year old, show every amendment made to it, and show who made each one and when. If the answer involves exporting a report that was generated at the time rather than querying the live record, that's worth noting. Reports summarise. Audit trails preserve.
Contractor records need to survive the same scrutiny
On assets running a high proportion of contracted work, the contractor management system is often where audit gaps surface, particularly around competency. A permit accepted by someone whose authorisation had lapsed, or whose training record wasn't current at the time of acceptance, is a genuine finding risk, not a theoretical one. We've covered this in more detail in contractor permit management and the competency gap.
The test here is similar to the isolation test: can the system show, retrospectively, what a contractor's competency status actually was at the moment they accepted a specific permit, rather than what it is today. Competency records that only reflect current status can't answer that question, and that's exactly the question an audit tends to ask.
Data centres are starting to ask for the same thing
An automated permit to work system for data centres faces a slightly different regulatory backdrop (PUWER, LOLER, and the Electricity at Work Regulations are more directly relevant than the offshore safety case framework) but the audit logic is identical. HV and LV switching operations, generator maintenance, and UPS isolation work all need the same kind of evidence trail: who authorised the work, what was isolated, and whether the isolation held for the duration. We've written separately about data centre electrical compliance for HV/LV authorised persons, and the overlap with offshore control of work is closer than the different terminology suggests.
Testing this before you commit
Before choosing a platform, it's worth running a small set of retrieval tests rather than relying on a features list. Ask to see a permit spanning a shift handover, a suspended permit reinstated days later, an isolation shared across several live permits, and a contractor's competency status at a specific past date rather than today. If a vendor can answer all four without exporting to a spreadsheet first, you've learned more than any feature comparison would tell you.
If you're reviewing how your current system would hold up against that kind of test, we can work through a sample of real permits and isolations with your team and flag where the existing record would or wouldn't answer those questions.
Source: [internal analysis, Elisian]