Process Safety Management Software: The Auditor Asks Whether the Credited Trip Still Works, and Nobody Knows

Why the audit question is never about the study, it is about the safeguard

An auditor opens the hazard study for the amine unit, dated 2019, and turns to node 12. The deviation is high level in the flash drum. The consequence recorded is carryover to the downstream compressor with potential for mechanical damage and loss of containment. Three safeguards are credited: a relief valve, a high high level trip that shuts the inlet, and an operator response to a high level alarm.

Then comes the only question that matters. Show me that the high high trip is still installed, still set at the value credited in the study, and still proof tested at the interval its integrity level requires. Show me the last test record.

What follows is forty minutes of screen sharing across three systems. The instrument index gives a tag. The maintenance system has a preventive job against that tag whose last completion is fourteen months old on a twelve month interval. Somebody remembers that the trip was bypassed during a compressor outage last spring, and nobody is certain it came out of bypass on the same day the paperwork says it did.

The study was competent. The facilitation was good. The team was experienced. The failure is that the study is a document describing a plant at a moment, while the safeguards it credits are physical things that change. The regulation is explicit that hazard analyses are revalidated at least every five years and that recommendations are resolved and documented, and process safety management also requires mechanical integrity testing of critical equipment. Nothing in a report format connects those obligations to each other.

Problem 1: your credited safeguards have never been listed in one place

Ask a process safety manager how many independent protection layers the site currently credits across all its studies. Almost nobody can answer, because the answer is distributed across twenty study reports in a document management system, each with its own worksheet, each written by a different facilitator over fifteen years.

What a custom build does first, before any workflow, is extract every credited safeguard from every study into a register, and force each one to resolve to something real: an instrument tag, a relief device, a specific written procedure, an interlock in the control system, or a physical item like a bund or a flame arrestor. Anything that cannot resolve to a real object is flagged, and the flagged list is where sites find their genuine surprises, including safeguards credited against equipment that was removed in a revamp.

This extraction is tedious and it is where machine assistance earns its place: reading legacy study worksheets, proposing the tag references implied by phrases such as high high level trip on the flash drum, and putting each proposal in front of a process safety engineer to confirm. The engineer adjudicates every one. The machine removes the reason the exercise never gets started.

Problem 2: recommendations become a spreadsheet with an average age

A study produces recommendations. Those recommendations go into a tracking spreadsheet. The spreadsheet grows. Some items are closed with a note saying accepted risk, signed by someone who has since retired. Some are closed by a change that partially addressed them. Some sit at ninety percent complete for three years because the final piece needs a turnaround.

What a custom build must include is risk based treatment. Each recommendation inherits the scenario risk it addresses, which sets the due date, the approval level required to defer it, and the escalation path. Deferring a high consequence recommendation should require a named senior signature and a documented interim measure, and the interim measure becomes a safeguard in the register with its own expiry. Closure requires evidence of the right kind: a marked up drawing, a revised procedure with a revision number, a completed work order, a training record. Closed with a comment saying done is not closure, and a system that accepts it is a filing cabinet with a login.

Problem 3: management of change and the hazard study live in separate universes

A change is raised to add a bypass line around a control valve to improve turndown. It goes through a review, gets approved, gets installed. Nobody connects it to node 12 of the 2019 study, where the flow path assumption underlying two credited safeguards has now changed.

This is the most consequential integration in the entire category, and it is almost never in place. The management of change process asks whether a hazard review is required, and a human answers based on judgement. What a system can do is answer part of that question mechanically: this change touches tags that appear in four hazard study nodes and two credited safeguards, so those studies are affected and here they are.

Problem 4: bypasses are where credited protection quietly stops existing

A safety instrumented function credited in a layer of protection analysis is only as good as its availability. Under the functional safety standard for the process sector, an integrity level implies a proof test regime, and the calculation assumes the function is in service. Every hour it spends in bypass is an hour the risk assessment does not describe.

A build should treat a bypass on a credited safeguard as an event that changes the site's risk position, not a log entry. Duration limits by integrity level, compensating measures recorded and verified by a named person, automatic escalation as the limit approaches, and a shift by shift review of every live bypass at handover so the incoming crew accepts a specific list. Where your control system can expose bypass status directly, read it, because a register that depends on people remembering to write things down will be wrong exactly when it matters.

Problem 5: revalidation restarts from a PDF every five years

Studies belong in a database. Nodes, deviations, causes, consequences, safeguards, risk rankings and recommendations are structured objects with relationships. Once they are, revalidation starts from the previous study with everything that has changed since already highlighted: the modifications made, the incidents and near misses that occurred on that node, the recommendations closed and deferred, the safeguards whose test records show poor performance. The team then spends its time on judgement rather than transcription, which is the only way five yearly revalidation stops being a budget line everyone dreads.

Where PHA-Pro, Enablon, Intelex and VelocityEHS actually stop

Sphera PHA-Pro is the established tool for running the study itself and it is good at that job. It is a facilitation environment: it captures a hazard and operability study or layer of protection analysis efficiently in a room with a team and a facilitator, and it produces the report. What it is not is a live register of what your plant currently relies on, connected to your maintenance system, aware of your changes and your bypasses. The study output leaves the tool and becomes a document, and the document is where the trail goes cold.

Enablon, Intelex and VelocityEHS approach it from the other direction as enterprise environmental, health and safety platforms with process safety modules. They handle action tracking properly, which is genuinely more than a spreadsheet, and they bring incident and audit management alongside. The gap we consistently find is depth at the safeguard level: safeguards remain descriptive text inside a study record rather than objects resolved to equipment tags with test intervals and current status. Connecting them to your computerised maintenance system, your instrument index and your control system bypass status is custom integration work in every case, and that integration is the entire point of the exercise.

There is also a structural mismatch worth naming. These platforms are configured for a corporate template, and process hazard analysis is site specific: node structures, risk matrices, safeguard taxonomies and integrity level assignment conventions differ between plants that a corporation acquired at different times. Forcing one template across them usually degrades the studies at every site to make the corporate report tidy.

Our position: keep PHA-Pro for facilitation if your teams like it, and build the register and the links around it. Replacing a facilitation tool is rarely the win. Owning the safeguard register always is.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this is the honest shape. A first release covering study import from existing reports, a safeguard register resolved to equipment tags with an unresolved exception list, and recommendation tracking with risk based due dates, evidence based closure and escalation runs $70,000 to $150,000 and ships in 12 to 16 weeks. A full platform adding maintenance and inspection integration so safeguard test status is live, bypass and impairment control, management of change linkage at tag level, incident linkage to study nodes, and structured revalidation support runs $180,000 to $420,000 phased over 6 to 12 months.

What drives cost up specifically here: the number of legacy studies to import and their condition, because a 2004 study in a scanned worksheet is a different problem from a recent one exported cleanly. Maintenance system integration, which depends on whether your preventive jobs carry the equipment tags your studies reference or a separate numbering scheme somebody invented. Control system bypass status, which crosses a network boundary and requires the controls engineer and a security review. Multiple sites with different risk matrices and node conventions. And any requirement to hold safety instrumented function reliability data, which brings its own calculation and audit expectations.

Build versus buy, and when buying is the right call

Buy, or stay on a spreadsheet, if you have one covered process, one current study, and a recommendation list you can read in a single sitting. Buy an enterprise platform module if your corporation has already standardised on one for incidents and audits, your sites genuinely share a risk matrix, and your ambition is action tracking rather than live safeguard status.

Build when two or more of these are true. You cannot currently produce a list of every safeguard your site credits. Your studies reference equipment that has been modified since and nobody has traced the impact. You have safety instrumented functions with proof test intervals that need to be visibly linked to what they were credited for. Your bypass register and reality have disagreed at least once. Or you have multiple sites with different node structures and risk matrices, and any single corporate template would degrade all of them.

The tipping point is whether you are managing documents or managing risk. A site that needs to demonstrate it completed studies is doing document management, and a platform will do. A site that needs to answer, at any moment, whether the protection it claims in its risk assessment is currently in place and currently tested, is running a live register, and a live register has to know your tags.

How to choose a developer for process safety software

Ask them to explain how a safeguard becomes a tag. A developer who has done this work will describe an extraction and adjudication process, an exception list for safeguards that cannot be resolved, and a plan for the ones that turn out to reference removed equipment. A developer who proposes importing studies as attachments has understood the filing problem and missed the safety problem entirely.

Ask how a change record finds the studies it affects. If the answer is that an engineer selects them from a list, the system has automated nothing that mattered. The link should be mechanical at tag level, with the engineer's judgement applied to the result rather than to the search.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts, and the right to hire anyone else. At Digital Heroes the code is yours from the first commit. A safeguard register is evidence in a regulatory inspection and after an incident, and evidence should never depend on somebody else's licence terms.