Digital Permit-to-Work — Implementation Planning Guide

Introduction

The permit-to-work process is one of the most critical functions in industrial safety management. Yet in many organisations it still relies on paper forms and personal memory — a practice that does not scale, produces no data and offers no real-time visibility into site conditions.

This guide is written as a practical tool for organisations considering a move to digital permit management — or those that have already decided to make the shift and want to ensure the planning and procurement phase is done right.

This guide is not tied to any specific system vendor. It is based on practical experience of what a successful implementation requires — and where organisations most commonly fail.

The guide answers the following questions:

• Why move away from paper-based processes — and what does that really mean?
• What needs to be planned before any system is selected?
• What should you require from the system and the vendor?
• How do you carry out a successful implementation?

The guide is suitable for HSE leadership, safety managers, procurement professionals and IT organisations — anyone involved in decision-making or implementation planning.

Prefer to read this offline? Download the full PDF — same content, formatted for printing.

1. Why Digitalise? — Pain Points and Drivers

The permit-to-work process is one of the most critical functions in industrial safety management. Yet in many organisations it still relies on paper forms, folders and personal memory — a system that cannot scale to meet the demands of growing operations, multiple concurrent jobs or an increasingly strict regulatory environment.

A paper-based permit practice does not necessarily mean the process is poor. It means the process has structural limitations that cannot be removed without digitalisation.

Most common problems with paper-based processes

• Permits physically dispersed — no real-time overview of active work
• Approvals dependent on specific individuals — bottlenecks, delays, work waiting to start
• Audit history incomplete or lost — risk in regulatory audits and incident investigations
• No automatic alerts — expired permits go unnoticed
• Contractor competencies verified manually — human error, verification omitted
• Difficulty managing consistent practices across multi-site organisations — fragmented practices, no comparability
• Reporting burdensome and slow — management visibility lacking, improvement difficult

Why now — most common drivers for digitalisation

Organisations typically begin for one or more of the following reasons:

• Safety incident or near-miss — an event exposes a process weakness; reactive pressure forces action
• Growth or a new site — paper processes do not scale to multiple sites or a growing contractor base
• Regulator or client requires it — an audit, certification or contractual partner requirement
• Strategic initiative from HSE leadership — a proactive shift as part of developing safety culture
• ERP or maintenance system renewal — a natural opportunity to build an integrated whole
• Competitor or industry standard changes — digital PTW is becoming the industry norm, not the exception

What digitalisation aims to achieve

The benefits of digitalisation are not limited to efficiency alone. There are three levels:

• Operational level — permits move faster, approvals are not held up by a single individual, and site status is visible in real time.
• Safety level — risk management is built into the process, not layered on top. The system prevents errors automatically — for example, a person with an expired competency cannot activate a permit.
• Management level — data accumulates automatically. Trends, deviations and bottlenecks are visible in reporting tools without manual compilation.

2. What Does Digitalising a PTW System Actually Mean?

Digitalising a permit-to-work system is often confused with using a digital form — the process is the same as before, but a screen is filled in instead of paper. This is the most common misconception, and it frequently leads to failed implementations.

A permit-to-work system is an operational control system. It does not merely store information — it guides the process, enforces the correct sequence, assigns responsibilities by role and prevents errors automatically. The difference is fundamental, not technical.

Paper process vs. real PTW system

Key building blocks of the system

Status model. The status model is the core of a permit-to-work system. Each permit progresses through defined states, and each state has a clear meaning, permitted actions and responsible person. The system guides — not individual interpretation.

A typical status flow: Draft → Submitted → Under review → Approved → Active → (Suspended) → Closed → Archived.

Roles and responsibilities. Roles and responsibilities are clearly separated. A role is the right or responsibility to manage a specific stage of the permit process — one or more stages. The role acts as an effective gatekeeper, ensuring that a task or decision can only be performed by a person who has been assigned the correct roles in the system.

Typical configurable roles include Permit viewer, Permit writer, Permit issuer and Permit closer. A single user may hold multiple roles.

Approval logic. Approval logic defines how many approval levels are required and in what order. The logic can be tied to risk category or permit type: low-risk permits follow a lighter process, while high-risk permits require multiple approvers.

Permit process steps in practice

A typical permit process follows these stages. The practical implementation varies by organisation and industry, but the basic structure is nearly universal:

1. Work identification and hazard assessment — the need is identified and work risks are assessed at the outset
2. Permit application / creation — the applicant completes the permit request or initiates the permit process
3. Risk assessment — work risks are assessed in more detail, mandatory or optional depending on the organisation's process
4. Conditions and controls — safety conditions are defined, checklists completed
5. Approval — the permit issuer and required approvers confirm
6. Work commencement — the permit is activated; work may begin
7. Work monitoring — active permits visible in real time
8. Suspension / modification — if conditions change, the permit can be suspended
9. Work completion — work complete, permit closed in a controlled manner

3. What Needs to Be Planned Before Implementation?

PTW system implementations rarely fail for technical reasons. The most common cause is that the process has not been defined in sufficient detail before system build begins. This section covers the key planning areas that must be resolved before any system is selected or configured.

Ground rule: define the process first — then select the system.

3.1 Current state assessment

Before planning begins, it is important to understand the starting point. This means an honest assessment of the current process — not how it should work, but how it actually works.

• Current process — how do permits flow today? Where are the bottlenecks?
• Permit types — what types of permits are in use? Are there differences between sites?
• Volume — how many permits are processed per day / week?
• Users — who participates in the process: own staff, contractors, subcontractors?
• Sites — is this one site or multiple locations?
• Integrations — what other systems does the PTW process connect to today?

3.2 Permit types and structure

One of the first decisions is what types of permits are needed in the system and how they relate to each other. Typical permit types include:

• General work permit — covers routine maintenance and service work
• Hot work permit — work generating sparks, flame or heat
• Confined space permit — working in enclosed or confined spaces
• Electrical work permit — handling electrical equipment and systems
• Excavation permit — ground excavation and associated risks
• Working at height permit — fall risk management

A structural question to address: will separate forms be used for different permit types, or a single dynamic combined permit that adapts to the nature of the work? The latter reduces duplication and improves overall visibility.

The permit hierarchy should also be defined: main permit (covers the entire job or work package), sub-permit (e.g. a hot work permit within a wider maintenance shutdown), and linked events (inspections or deviations linked to the permit).

3.3 Roles, responsibilities and approval logic

Defining roles and approval logic is the most common bottleneck in implementation projects. Sufficient time should be allocated for this.

Key decisions:

• Role definition — who has the right to write, issue and close permits?
• Multiple roles per person — can the same person hold multiple roles, and is that acceptable from a process perspective?
• Approval levels — how many approval steps are required for different permit types or risk categories?
• Sequential or parallel — do approvals happen in sequence or can they proceed simultaneously?
• Deputies — who approves when the responsible person is absent?

3.4 Risk management and controls

Risk management should be planned as part of the permit process — not as a separate step alongside it.

Planning questions:

• Mandatory risk assessment — mandatory for all permits, only for certain permit types, or optional?
• Assessment method — per job individually, ready-made risk templates, or a combination?
• Control logic — fixed checklist, or dynamic logic that adapts to the risks of the work?
• Automatic conditions — e.g. a hot work permit automatically triggers the requirement for a fire watch

3.5 Competencies and qualifications

The permit-to-work process often includes a requirement to verify that the personnel carrying out work hold valid competencies. This is an area where a digital system offers a significant advantage over paper processes:

• Competency valid — person can be added to the permit
• Competency expiring — system alerts in advance
• Competency expired or missing — system automatically prevents the person from being added to the permit

During the planning phase, a decision must be made whether competencies are managed within the PTW system itself or integrated from an external HR or competency register.

3.6 Integrations

A permit-to-work system does not operate in isolation. Before implementation, it must be established which other systems it will connect to and where the organisation's master data resides.

Key principle: establish master data ownership before locking the integration architecture. Unclear ownership leads to duplicate maintenance and errors.

3.7 Governance and standardisation

Particularly in multi-site organisations, the question of how much uniformity is desired in the process — and how much local flexibility is permitted — must be resolved.

• Global model vs. local variations — a uniform model simplifies reporting and auditing; excessive rigidity reduces usability
• Configuration boundaries — what can the local unit modify independently, and what cannot be changed?
• Language versions — is the system needed in multiple languages?

In practice, a workable model is often 80% uniform structure + 20% local flexibility — this ensures comparability and auditability without sacrificing practical usability.

4. What Should You Require from the System? — Evaluation Criteria

Selecting a permit-to-work system is a long-term decision. The system integrates deeply into operational processes, and switching later is costly and disruptive. During the evaluation phase, the system should be assessed more broadly than just its features — the vendor's maturity, implementation realism and total cost are equally important.

4.1 Functionality

When evaluating features, it is worth distinguishing between mandatory requirements and desirable capabilities:

• Permit type configuration — can permit types and form structures be configured without programming?
• Approval logic flexibility — does the system support multi-step, parallel and risk-category-based approvals?
• Status model — are statuses configurable or fixed?
• Real-time situational overview — are active permits and site status visible in real time?
• Map or area view — can permits be visually located on a floor plan or map?
• Risk assessment — does the system support the JSA/RA process — templates, dynamic logic?
• Competency management — competency tracking and automatic blocks for expired competencies
• Audit trail — is all activity recorded automatically and immutably?
• Mobile support — does the system work on mobile devices in the field without a separate app?
• Multilanguage support — does the system support multiple languages within the same instance?
• Multi-site support — can multiple sites be managed under a single system?

4.2 Integrations and technical architecture

• Directory system — does the system support SSO login (e.g. Microsoft Entra ID / Azure AD)?
• API interfaces — are open interfaces available for integrations?
• Maintenance systems — ready-made integrations with the most common CMMS systems?
• BI tools — can data be exported to reporting tools (e.g. Power BI)?
• Server location — has the organisation defined any requirements for this?

4.3 Security and compliance

• Server location — does it meet your data residency requirements?
• Role-based access control — can access rights be defined precisely at the role and site level?
• Vendor certifications — ISO 27001 or equivalent information security certification?
• Backup and recovery — how is data protected and how quickly can operations be restored after a disruption?

4.4 Implementation and usability

A system is only as good as its adoption in the field. A technically strong system will fail if users do not embrace it.

• Time to go-live — how quickly can the system be in production use?
• Ease of configuration — does configuration require programming expertise or can it be done without IT resources?
• User interface — is the system intuitive for a field user, not just an office worker?
• Training — what training does the vendor provide as part of the implementation?
• Support — how is support arranged after go-live: response times, channel, language?
• Devices in the field — what devices do users work with in the field? Does the system support mobile working without a separate app?

4.5 Pricing and total cost

Pricing models vary significantly between vendors. To ensure comparability, request a total cost calculation — not just a monthly price.

• Pricing model — what is pricing based on: number of users, permit volume, or simply the number of sites?
• Impact of user numbers — does the price increase as user numbers grow, including contractors?
• Implementation cost — is implementation included in the price or is it a separate project?
• Integration costs — what does building integrations cost?
• Ongoing development and updates — can the product be adapted to our individual needs, or will we have to adapt our daily operations to the constraints set by the system vendor?
• Contract flexibility — minimum commitment period, termination terms, data return at end of contract

4.6 Vendor assessment

In addition to the system, the vendor should also be assessed. Particularly with smaller vendors, product development, support and customer service can vary significantly.

• Industry experience — does the vendor have references from your own industry?
• Customer references — can you call reference organisations, not just read case stories?
• Product development direction — in what direction is the system being developed? Does it align with your needs?
• Vendor stability — how long has the vendor been on the market? Is the business on a stable footing?

5. Most Common Pitfalls

Implementing a permit-to-work system is an organisational change — not an IT project, but a change in working practices, operational processes and often the entire safety culture. Most failures are not caused by technology, but by how the implementation is managed and how the process is defined before system selection.

One of the most important questions before moving to digital permit management is to ask: "What do we want to achieve? What are our priorities?" Is the intention merely to digitalise the process and appear as a modern company, or is the genuine aim a cultural change that promotes productivity and occupational safety?

5.1 The process has not been defined before system selection

The most common and most serious mistake. System configuration begins before it is clear how the process should work. The result is a system built on top of the old paper process — in digital form, but equally dysfunctional.

Symptoms include: process descriptions missing or out of date; different units have different understandings of the process; decisions are made under time pressure during the project.

5.2 Roles and responsibilities remain unclear

Defining roles seems straightforward in theory — in practice it reveals the ambiguities in the organisation's structure. Who really issues the permit? Who can close it? Can the same person act as both writer and issuer?

Symptoms include: roles are copied from the paper process as-is; no deputy system has been defined; role conflicts are resolved at system level rather than organisational level.

5.3 The system is made too complex

In the early stages of digitalisation there is a temptation to build the most comprehensive and complete system all at once. The result is a heavy configuration that nobody in the field wants to use.

Symptoms: too many mandatory fields and steps in the permit process; approval logic is over-configured; every exceptional situation has been addressed at system level.

The best system is not the most comprehensive — it is the one that is used correctly in everyday operations.

5.4 Change management and communication are neglected

A system may be technically excellent, but if users do not understand its purpose or benefit, adoption will remain low. Resistance to change is particularly strong among contractors and installers working in the field.

Symptoms: implementation communicated as a mere system change; end users are not involved in the planning; training is handled as a one-time event.

5.5 No pilot is run — or it is done wrong

Jumping straight to full implementation is a high-risk approach. A pilot is the cheapest way to find process and configuration problems before they multiply across the entire organisation.

Symptoms: pilot conducted in too small or unrepresentative an environment; feedback is not collected systematically from the pilot; the pilot is not scheduled — it drags on indefinitely.

5.6 Integrations

Integration needs and wishes are best identified early in the project. Certain needs may be highly relevant and justified to define in detail from the outset, but the best outcome is often achieved once the organisation has already moved to digital permit management — the product is familiar and the so-called run-in phase is complete.

Three notes on integrations:

• Simple does not always mean inexpensive — from an end-user perspective an integration may appear easy to implement; in reality even a minor item can require significant effort and lead to unexpectedly high costs
• Define before you approve — do not give the vendor a blank cheque for integration work; always define together with the system vendor what will be done and at what level of effort
• Budget for the cost of specification work — planning integrations can require significant effort and time; the specification work itself may also incur costs that should be budgeted for in advance

6. Implementation and Change Management

A technically successful implementation does not guarantee a successful change. The system may be configured correctly, but if people do not embrace it — or do not understand why the change is being made — adoption will remain low and benefits will not be realised. Implementation should be planned as a change project, not an installation project — one in which users are involved as much as possible, particularly when significant changes to processes are being sought.

6.1 Phasing and piloting

Jumping straight to full implementation is a high-risk approach. A phased approach provides the opportunity to learn and correct before the model is replicated across the whole organisation.

1. Pilot — implementation at one site or in a limited area. Choose a pilot site with a motivated responsible person and a representative sample of permit types.
2. Evaluation and iteration — collect systematic feedback from the pilot: process, usability, configuration. Make necessary changes before expanding.
3. Rollout — replicate the corrected model to other sites in phases. Do not try to launch everything simultaneously.

A good pilot is not the minimum possible test — it is a sufficiently representative whole from which lessons learned genuinely transfer to the next phase.

6.2 Internal communication and change management

Resistance to change is a natural reaction — particularly among field users for whom a new system primarily appears as extra work. The role of communication is to reframe this: why is the change being made and what benefit does it bring to the user themselves?

Communication focus by audience:

• Management and decision-makers — strategic benefits: visibility, risk management, auditability, data to support decision-making
• HSE and safety organisation — process improvement, error reduction, real-time situational awareness
• Supervisors and permit issuers — easier approvals, mobile working, no more searching for paperwork
• Contractors and field users — permit applications simplified, no waiting, clear instructions

After a successful implementation, comments from the field typically end up like this: "I never want to go back to the old paper permit process!" — "This is so much smarter, faster and better than the old way!"

6.3 Training

One-off training is not enough. Particularly for contractors and infrequent users, training must be easily accessible and repeatable.

• Go-live training — all user groups before launch
• Role-based training — permit issuers, HSE, supervisors — deeper process understanding
• Short videos or quick reference guides — contractors and occasional users — low barrier to return to the topic
• Super-user training — internal expertise for configuration and maintenance, reduces dependency on the vendor

6.4 Metrics and measuring success

Implementation should be monitored with concrete metrics — otherwise it is impossible to know whether the change has succeeded or was merely technically executed.

• Adoption rate — what proportion of permits flows through the system? Are parallel paper processes still running?
• Lead time — how long does the permit process take from start to approval? Has it improved?
• Pending approvals — are permit requests accumulating in a queue? Where are the bottlenecks?
• Deviations and suspensions — how many permits are suspended, and for what reasons?
• User satisfaction — field feedback: is the system working in practice, or are users finding workarounds?

6.5 Continuous improvement

Go-live is not the end of the project — it is the starting point. The best organisations treat the permit-to-work system as a continuously evolving process, not a piece of software installed once.

• Regular process review — does the configuration still reflect the actual process, or has day-to-day practice changed around the system?
• Data utilisation — what does the collected data reveal about process performance? Where are the areas for improvement?
• User feedback collection — systematic feedback from the field; minor friction points should be resolved before they grow into larger problems
• Expansion — new sites, new permit types, new integrations — phased and managed

Summary and Checklists

Moving from a paper-based permit practice to digital permit management is a significant change — but when well planned, it is one of the most impactful investments an organisation can make from the perspective of occupational safety and operational efficiency.

Success does not depend on the system — it depends on how well the process is defined before implementation, how the change is managed and how committed key people are to driving the change through from the very start.

Checklist — before system selection

1. The current process has been mapped honestly — not how it should work, but how it actually works
2. Objectives have been defined: what is to be achieved and by what metrics success will be measured
3. Permit types have been listed and the permit hierarchy defined
4. Roles and responsibilities have been defined at organisational level — not just system level
5. Approval logic has been decided: levels, sequence, risk categories
6. A deputy system has been planned
7. The role of risk assessment in the process has been defined
8. Competency management has been reviewed — managed within the system or integrated from outside
9. Integration needs have been identified at a preliminary level
10. The governance model has been decided — global standard vs. local flexibility

Checklist — when evaluating systems

1. Features have been reviewed and mandatory vs. desirable requirements separated
2. The pricing model has been clarified and total cost calculated — not just the monthly price
3. The implementation model and timeline have been established
4. Security and server location have been checked against the organisation's requirements
5. SSO / directory system integration has been established
6. References have been checked — preferably from your own industry
7. Contract terms have been reviewed — termination conditions, data return, update practices

Checklist — implementation preparation

1. A pilot site has been selected and a responsible person named for the pilot
2. An internal communication plan has been drawn up for different target groups
3. A training plan has been drawn up by role
4. Success metrics have been defined before launch
5. A feedback collection model has been agreed for the pilot phase
6. A rollout plan has been prepared for the period after the pilot phase

A digital permit-to-work system is a real-time operational control system that connects risks, people, work and decisions into a single manageable whole.

Want a printable companion? Download the PDF version of this guide.