Digital Permit to Work: Why the System Has to Refuse Its Own Signature

# Digital Permit to Work: Why the System Has to Refuse Its Own Signature

TL;DR: If the same user can request a permit to work and also issue it, the system is producing a record of an approval that no one independently verified — and that defeats the legal and operational purpose of the permit, even if the form itself is technically complete.

The right form, signed by the wrong person

A permit to work (PTW) exists for one specific reason: to force a second person, with authority and information the requester doesn't have, to confirm that a hazardous task — hot work, confined space entry, excavation, work at height, intervention on an energized line — can proceed safely right now, at that location, under those conditions. The permit isn't the document. It's the act of a distinct person having looked at the request and said "yes, but."

That's easy to state on paper. It's surprisingly easy to destroy in software.

When a team digitizes the HSE process, the natural instinct is to replicate the paper form: fields for the work description, identified hazards, required PPE, isolations, requester signature, issuer signature. The problem shows up in the layer no one designs on purpose — access control. If the same user has permission to fill in both the "requester" field and the "issuer" field in the same session, the system isn't enforcing a second, independent check. It's producing a PDF with two signatures where only one decision ever took place.

This isn't a theoretical failure. It's the single most common failure in permit-to-work systems built under time pressure, because the path of least resistance in any web form is to let the authenticated user fill in whatever fields are on screen. No one deliberately decides to allow self-issuance — it survives because no one explicitly decides to block it.

Segregation of duties isn't bureaucracy — it's what makes the signature evidence

In financial audit, segregation of duties (whoever authorizes a spend cannot be the one who processes it; whoever receives goods cannot be the one who ordered them) exists so that a signature actually means something. We've described this exact principle in the context of capital approvals, where the spreadsheet fails precisely because it cannot stop the same user from approving their own request — see AFE e Controlo de Capital: Porque é que a Folha de Cálculo Falha Sempre no Momento Errado. The principle in HSE is identical, but the consequences of violating it are worse: in finance, a bad self-approval produces an incorrect invoice; in a permit to work, it produces a worker striking an arc or lighting a torch next to a line no one independently confirmed was depressurized.

OSHA's hazardous energy control regulation (LOTO — lockout/tagout, 29 CFR 1910.147) contains a direct, verifiable example of this principle applied to energy isolation: the periodic inspection of each energy control procedure must be performed by an authorized employee other than the one(s) utilizing that procedure, and the employer must certify who performed the inspection, when, and on what equipment — at least once a year (OSHA, 29 CFR 1910.147; OSHA, Periodic Inspections). This isn't a "best practice" suggestion — it's an explicit regulatory requirement that verification of a safety control cannot be carried out by the same person who applied it.

Industry guidance on permit-to-work systems follows the same logic from the other direction. EIGA's (European Industrial Gases Association) guidance on work permit systems states that for a robust system at least two individuals should be involved together at the work site — the permit issuer and the permit receiver — and that lone workers should not be allowed to write a work permit for themselves (EIGA, Doc 040 — Work Permit Systems, section 2.1). The second person is what brings an independent view of hazards the task-focused requester may not see. The UK Health and Safety Executive publishes guidance specifically for the petroleum, chemical and allied industries on permit-to-work systems, covering training, competence, work planning and system audit (HSE, HSG250) — the fact that an entire publication exists on this one topic, rather than a generic clause buried in a broader standard, says something about how often segregation of duties fails in practice.

What changes when you design this properly

The gap between a digital form and an actual control comes down to three concrete design decisions.

1. Two real users, not two fields. The system has to identify requester and issuer as two distinct, separately authenticated accounts, with a different userId recorded against each signature field. That sounds obvious, but it requires the data model to explicitly separate requestedByUserId from issuedByUserId — and for the business logic to reject the write whenever the two IDs match, regardless of what the client-side form shows or hides. Validation only in the interface (hiding the "issue" button from whoever submitted the request) isn't a control — it's decoration, trivially bypassed by anyone calling the API directly.

2. Distinct roles, not just distinct users. Two people isn't enough on its own — the second person needs formal authority to issue that specific permit type. A hot work permit, for example, typically requires an issuer with recorded competence and authorization for that specific hazard, not just anyone with an active account. This ties directly into the system's RBAC (role-based access control) model, where the role "Permit Issuer — Hot Work" is a deliberately granted authorization, not a side effect of having a logged-in session — see Permissões que Não Mentem: RBAC e Trilho de Auditoria Imutável num ERP Industrial.

3. An immutable audit trail, recorded at the transaction level. Every state change in the permit — requested, reviewed, issued, suspended, closed — has to be recorded with the user, the timestamp and, where relevant, the justification, in a log that cannot be rewritten after the fact. If an incident investigation needs to reconstruct "who knew what, and when," the answer has to be in the database, not in the memory of whoever was on shift.

The table below summarizes what separates a form from a control:

Linking the permit to the energy isolation cycle

The piece most often missing from rushed implementations is the bidirectional link between the permit and the physical energy isolation (LOTO). A hot work or mechanical maintenance permit shouldn't be issuable while the associated isolation list — which valves were closed, which breakers were opened and locked, which lines were depressurized and tested — isn't recorded as confirmed by whoever physically applied the isolation. The reverse has to hold too: the isolation shouldn't be removable while the dependent permit is still open.

That requires a third role, distinct from both requester and issuer: whoever applies and confirms the isolation in the field. In many operations that's the same "authorized employee" OSHA refers to in 1910.147 — the person applying the lock and tag — but the design point is the same one: the system has to technically refuse to let the permit proceed without that separate confirmation, exactly as it refuses self-issuance. We've described how this same discipline around inspection and incident logging extends across the rest of the HSE program in HSE Digital em Angola: Inspecções, EPI e Incidentes Que Deixam Rasto Auditável.

The legal framework in Angola

In Angola, the General Labour Law (Lei n.º 12/23, of 27 December 2023) sets the general workplace safety and health framework, and Decree No. 31/94, of 5 August, remains the regulatory basis establishing the principles for promoting Safety, Hygiene and Health at Work (LEX.AO — Decreto n.º 31/94). More recently, Presidential Decree No. 179/24, of 1 August, approved the Regulation on Licensing for Safety, Hygiene and Health at Work (SHST) services: it sets the rules for SHST services and their registration and authorisation with the General Labour Inspectorate, applies to companies that already had such services running, and requires an annual SHST services report (Miranda Advogados, 2024; LEX.AO — Decreto Presidencial n.º 179/24).

None of these instruments prescribes the design of a piece of software — but all of them share the same logic that underpins OSHA's requirement on periodic LOTO inspections: the formal competence and independence of whoever verifies a safety control are part of the control itself, not an administrative footnote. A system that lets the same person request and issue a permit is, in practice, documenting an issuer competence that was never actually exercised — which is an exposure both operationally and in front of a labour inspection or an incident investigation.

The recurring production failure: "super-user mode"

Even well-designed systems fail here in a predictable way: someone — usually a well-intentioned administrator during a period of operational pressure — gains access to a role meant to be reserved for issuing and requesting permits at the same time, "just this once, because there's no one else on shift." Every one of these exceptions, unless it's technically impossible at the data-model and API level, eventually becomes the silent norm, because the pressure to bypass the process is constant and the pressure to respect it only shows up after an incident.

That's why segregation of duties can't live in a written policy or a procedures manual. It has to live in the table structure, the database constraints and the server-side validation logic — exactly the kind of work that requires software built around the operation's actual process, not a generic form adapted after the fact. That's why this kind of control, like other sensitive approval workflows in industrial environments, is usually only achievable reliably with custom software designed around the real safety process, rather than bolted onto a generic task-management product.

FAQ

Can one person hold both the requester and issuer role during reduced-crew situations, like an understaffed night shift?

From a system design standpoint, it shouldn't be technically possible for the same user to hold both roles on the same permit, regardless of crew size. If the operation has to run with reduced staff, the correct answer is a contingency plan with a remote second issuer (by phone or video, with that remote authorization logged), not an exception carved into the system. OSHA applies exactly this logic to periodic LOTO inspections, always requiring an employee other than the one using the procedure.

Does this only apply to hot work, or to every permit type?

The principle applies to any permit authorizing a high-hazard activity — hot work, confined space entry, excavation, work at height, electrical intervention. The competence level required of the issuer varies by hazard (a hot work issuer may not be authorized to issue a confined space entry), but the rule that requester and issuer must be distinct users with distinct roles doesn't change.

What difference does this make in an incident investigation or a regulatory inspection?

An audit trail showing a requestedByUserId different from the issuedByUserId, with timestamps and each user's RBAC role at that moment, proves the second check happened. Without that record, a permit signed twice by the same person is, in practice, indistinguishable from a permit that was never reviewed — and that's precisely the question a labour inspector or accident investigator will ask first.

Is it worth adapting a generic task-management product for this, or does it need to be built from scratch?

It depends on how much the generic product lets you enforce server-side (not just interface-level) validation rules and generate an immutable, queryable audit trail. Many digital checklist products replicate the paper form without enforcing the underlying business rule — in that case, "digitizing" preserves the appearance of the control without preserving the control itself.

Sources

• OSHA — 29 CFR 1910.147, The control of hazardous energy (lockout/tagout)
• OSHA — Lockout-Tagout eTool, Periodic Inspections
• UK Health and Safety Executive — HSG250, Guidance on permit-to-work systems (petroleum, chemical and allied industries)
• EIGA — Doc 040, Work Permit Systems
• Lei n.º 12/23, of 27 December 2023 — General Labour Law
• Decreto n.º 31/94, of 5 August — Principles of Safety, Hygiene and Health at Work
• Decreto Presidencial n.º 179/24, of 1 August — Licensing of SHST Services