PSSR Explained: 4 Startup Tests Before New Work Goes Live

A pre-startup safety review, usually called a PSSR, asks whether a new or changed operation is ready to run without relying on unfinished controls. It matters before commissioning, restart, expansion, or a significant process change, when the cost of discovering a missing safeguard is already high.

The useful question is not whether every document has a signature. It is whether the worksite can show that the design, people, procedures, and emergency response are ready for the conditions that will exist on the first operating shift.

A pre-startup safety review is a structured readiness check performed before new, modified, or restarted work enters operation. It confirms that safety requirements have been addressed, controls are available, affected people are prepared, and unresolved conditions have an explicit decision owner before exposure begins.

What is a PSSR?

A PSSR is the final readiness review before an asset, process, or changed work arrangement moves from preparation into operation. It does not replace design review, risk assessment, commissioning checks, or management of change. It connects their outputs and tests whether the promised controls exist in a form that operators can use.

ISO 45001:2018 supports this logic through operational planning, change management, competence, and emergency preparedness. The standard does not make a signed checklist sufficient. Readiness still depends on evidence that the controls are installed, understood, and available where the work will happen.

Across more than 250 cultural transformation projects, Andreza Araujo has seen readiness weaken when teams treat a review as an administrative finish. Her book Safety Culture: From Theory to Practice makes the broader point that culture becomes credible when decisions match the controls the organization says it values.

4 startup tests a credible PSSR should pass

A useful PSSR tests four different claims. They should be recorded separately because a project can be technically complete while the people who operate it are not ready, or trained people can arrive at a worksite where the promised barrier is still absent.

Design test

The equipment, layout, guarding, isolation points, ventilation, alarms, and other engineered controls match the approved risk decisions.

Control test

The procedures, permits, inspections, maintenance arrangements, and emergency controls are available in the form the operating team will actually use.

People test

Operators, supervisors, maintainers, and contractors have the competence, authorization, and role clarity required for the changed work.

Response test

Abnormal conditions, escalation routes, rescue arrangements, and stop-work triggers have been rehearsed or otherwise verified before exposure begins.

These tests are stronger than a single completion percentage because each one points to a different failure path. A green project dashboard cannot compensate for an unverified isolation point, an unavailable procedure, or a supervisor who does not know when the new process must stop.

How to tell a PSSR from a management of change review

Management of change asks what is changing, which hazards the change introduces, and which decisions must be controlled before approval. A PSSR asks whether those decisions have been converted into operating readiness. The first governs the change; the second tests the condition of the work before it starts.

That boundary matters because a closed change record can create false confidence if the field still lacks a physical barrier, an updated procedure, or trained people. The PSSR should therefore reference the change record while remaining willing to stop startup when the evidence is incomplete.

How to differentiate a PSSR from a permit-to-work

A permit controls a defined task, while a PSSR controls readiness for an operating condition. They can overlap during commissioning, but neither should be used as a substitute for the other.

When should a team use a PSSR?

Use a PSSR before a new process starts, after a major modification, before a restart following extended shutdown, or when a change alters hazards, safeguards, staffing, or emergency response. The trigger should be defined before the project reaches its final week, because late discovery creates pressure to accept open items.

Do not wait for a dramatic redesign. A smaller change can still affect isolation, chemical exposure, traffic flow, contractor interfaces, or the assumptions built into a procedure. The right threshold is the change in operating risk, not the size of the capital budget.

What should leaders do with open items?

Every open item needs a named owner, a due date, evidence of interim control, and a decision about whether startup can proceed. If the item affects a critical barrier or emergency response, the default should be to hold the decision until the responsible leader can demonstrate an acceptable control.

The review becomes useful when it creates a visible decision trail rather than a longer list. If the team cannot explain why an exception is safe, who accepted it, and what will prove closure, the PSSR has identified a readiness problem that still needs leadership attention.

For a broader comparison of change controls, read MOC vs PTW vs PSSR: Which Control Fits Operational Change.