PSSR (Pre-Startup Safety Review): understand the safety gate before startup, differences from pre-commissioning and ORR, requirements, MOC, training, open items, and release.
Check it out!
PSSR (Pre-Startup Safety Review) is the formal review performed before startup or return to operation of a new or significantly modified facility to verify whether the essential conditions for safety, design, procedures, training, and management of change are actually ready for introduction of the process or commencement of the intended operation.
A PSSR is not an equipment test and does not replace pre-commissioning. It functions as a startup-readiness gate, bringing together evidence produced by engineering, construction, commissioning, process safety, operations, and maintenance and converting that evidence into a formal decision: can the unit or system advance to startup, or are there still impediments that must be resolved?
Under OSHA 29 CFR 1910.119, the review is required for new facilities and modified facilities when the modification is significant enough to require a change in process safety information. Outside that specific regulatory framework, the methodology can also be adopted as a governance good practice in industrial projects and critical assets, provided its scope, responsibilities, and criteria are defined by the project and the owner.
What Is PSSR?
PSSR stands for Pre-Startup Safety Review. Its purpose is to confirm, before startup, that the physical, documentary, and operational condition required for a safe startup has been established and verified.
OSHA structures PSSR around four fundamental verifications for processes covered by its regulation: construction and equipment compliance with design specifications; existence and adequacy of safety, operating, maintenance, and emergency procedures; treatment of hazard analyses and applicable recommendations; and completion of training for personnel involved in operation.
This makes PSSR an interdisciplinary decision point. A system may have completed installation, inspections, and individual tests and still not be ready to start if, for example, an emergency procedure is not approved, a field change has not passed through management of change, a critical interlock remains pending, or the team has not yet been trained on the final configuration.
PSSR, Mechanical Completion, Pre-Commissioning, ORR, and Startup: What Is the Difference?
These milestones are related, but they are not equivalent. Separating them prevents one signature from being used to obscure technically different activities.
| Milestone | Primary question | Nature of evidence | Expected result |
| Mechanical Completion | Was installation completed according to the defined scope and criteria? | inspections, checklists, certificates, punch list | system released for subsequent verifications |
| Pre-Commissioning | Is the installation technically ready for energization, dynamic tests, or startup? | preliminary tests, calibration, cleaning, loop checks, readiness verifications | system prepared to advance to commissioning/startup |
| PSSR | Have the safety and operability conditions required for startup been formally verified? | design, PHA/MOC, procedures, training, field condition, open items, and authorizations | formal decision to release or block startup |
| ORR | Are the organization and asset ready to operate or return to operation? | people, procedures, maintenance, support, documentation, and operating condition | operational readiness confirmed |
| Startup | Can the system actually be placed into operation according to the approved procedure? | controlled execution of the startup sequence and operating records | initial entry into operating condition |
Pre-Commissioning in Engineering produces an important portion of the evidence that feeds the PSSR. Mechanical Completion establishes the installation-completion milestone. PSSR consolidates the safety and operability perspective immediately before startup.
PSSR does not correct incomplete pre-commissioning.
The safety gate is reliable only when completion, verifications, preliminary tests, configuration, and documentation have already produced sufficient evidence to support the startup decision.
Connect completion, test packs, and readiness to the pre-startup gate →
When Should a PSSR Be Performed?
Within OSHA 29 CFR 1910.119, a PSSR must be performed for new facilities and modified facilities when the change is significant enough to require modification of process safety information. The objective is to complete the verifications before introducing highly hazardous chemicals into the covered process.
As an engineering and governance practice, the concept is also useful when a change materially alters the operating condition of a facility, even when the project is not subject to the U.S. regulation. Papers presented at AIChE report the use of PSSR in mining, ports, railways, and industrial facilities in Brazil, reinforcing its value as a verification mechanism before operation.
Typical situations that may justify a structured review include a new unit, capacity expansion, significant retrofit, process change, modification of interlocks or protections, a turnaround involving significant changes, replacement of critical equipment, implementation of new automation, utility changes, or return to operation after interventions capable of changing the asset’s safety basis.
The decision to require a PSSR should be linked to the management-of-change process and project governance, not merely to the name given to the project.
PSSR Starts Before the Final Meeting
An effective PSSR should not be treated as a checklist completed on the eve of startup. CCPS recommends integrating review preparation throughout project and turnaround phases, leaving the final gate to confirm that the elements actually required have been completed.
This means identifying in advance which evidence will be required, who will be responsible for producing it, which items can block startup, and how open items will be classified. When this structure is discussed only at the end, the team tends to discover too late that documents are missing, recommendations remain open, training is incomplete, or field conditions differ from the design.
The best architecture is progressive: requirements and hazards are identified during engineering; changes are controlled during detailed design and construction; completion and pre-commissioning produce technical evidence; operations prepares procedures and training; and PSSR verifies whether the overall set has reached the condition required for startup.
Required Inputs for the Review
The input package depends on the process and the change, but it normally needs to make it possible to reconstruct the logic among requirement, design, installed condition, risk, and intended operation.
Relevant information includes engineering documents and specifications, updated P&IDs and diagrams, equipment and instrument lists, control and protection philosophy, cause-and-effect matrices, change documentation, risk analyses, PHA recommendations, completion and pre-commissioning records, instrument and interlock tests, operating procedures, emergency procedures, maintenance plans, mechanical-integrity documentation, and training records.
A long list does not guarantee quality. The decisive point is that each piece of evidence is linked to the risk or condition it is intended to demonstrate.
Compliance Between Construction, Equipment, and Design
One of the central PSSR verifications is confirming that the facility was constructed and equipped in accordance with the applicable design specifications. This requires more than comparing drawings with photographs.
Field changes need to be identified, technically justified, and incorporated into management of change when applicable. Replaced equipment should be evaluated for capacity, materials, pressure, temperature, protection, hazardous-area classification, interfaces, and other safety requirements. Redlines, open-item lists, and As-Built documents need to converge on the same configuration.
The problem appears when the unit is tested in one configuration, the documents show another, and operations receives a third informal version. PSSR should block this type of ambiguity when it affects safety or startup operability.
Safety, Operating, Maintenance, and Emergency Procedures
The physical existence of equipment does not make the facility operable. The team needs to know how to start, operate, stop, isolate, maintain, and respond to abnormal conditions in the final configuration.
Procedures should represent the actually installed condition, including changes made during construction and commissioning. Startup and shutdown sequences, operating limits, alarms, actions under abnormal conditions, authorized bypasses, emergency communication, energy isolation, and interfaces between areas need to be consistent with engineering and operator responsibilities.
A generic procedure or one copied from a previous configuration may formally exist and still be technically inadequate. The review needs to assess sufficiency, not merely documentary presence.
PHA, Recommendations, and Management of Change
For new facilities covered by OSHA PSM, PSSR must confirm that the process hazard analysis has been performed and that recommendations required before startup have been resolved or implemented. For modified facilities, the review connects to the Management of Change — MOC process.
Management of change needs to demonstrate the technical basis of the change, safety impacts, required procedure modifications, the time period for the change, and applicable authorizations. If the change affects process safety information or operating procedures, those documents need to be updated.
In the commissioning context, this interface is critical because tests frequently lead to adjustments in setpoints, logic, interlocks, parameterization, or configuration. A correction made to “pass the test” cannot remain outside change control when it alters the process safety basis.
Training and Competence Before Startup
PSSR does not verify equipment alone. OSHA also requires, within its regulatory scope, that training for employees involved in operation be completed before startup.
For a project, this means confirming that the team understands the final configuration, applicable procedures, abnormal conditions, alarms, operating limits, emergency actions, and changes introduced by the project. Purely theoretical training may be insufficient when operation depends on maneuvers, sequences, or responses to specific events.
Operations participation during commissioning and testing reduces the gap between a “technically approved system” and a “system that can actually be operated.”
PSSR Field Inspection and Walkdown
The document review must be confronted with field conditions. A structured walkdown makes it possible to verify whether physical conditions confirm what the documents state.
The team may observe equipment and line identification, valve positions, temporary blocks, blinds and spades when applicable, connections, protections, access, safety devices, escape routes, signage, instruments, bypasses, housekeeping conditions, utilities, status of auxiliary systems, and construction or maintenance open items.
The objective is not to repeat every quality checklist, but to identify conditions that may invalidate startup readiness.
Interlocks, Alarms, and Critical Functions
When startup safety depends on instrumentation and control, PSSR needs to confirm that critical functions have been adequately verified and that the results are available as evidence.
Startup permissives, trips, ESD, priority alarms, automatic actions, safety valves, control logic, and interfaces with auxiliary systems need to be in a condition consistent with the startup procedure. Temporary bypasses or inhibitions should be identified, authorized, and assessed for impact.
PSSR does not replace loop checks, functional tests, or integrated tests; it verifies whether the necessary evidence from those tests exists and supports the startup decision.
Punch List: Which Open Items Block Startup?
Not every open item has the same criticality. The gate needs to distinguish items that compromise safety or operational validity from items that can remain open under formal control.
| Open-item class | Effect on startup | Typical treatment |
| Safety critical | may compromise protection of people, containment, safety function, or emergency response | blocks startup until correction and verification |
| Operationally critical | prevents safe execution of the sequence or control of an abnormal condition | normally blocks startup |
| Major technical | reduces integrity, reliability, or capacity required for the startup scenario | requires formal assessment and generally correction before startup |
| Relevant documentary | prevents understanding of configuration, procedure, or critical evidence | conditions release until regularized |
| Minor | does not interfere with safety or startup validity | may remain on the punch list with a deadline and owner |
The classification needs to be defined by the project. The terminology is less important than the decision rule and the authority that accepts or rejects residual risk.
Critical open items need to remain visible at the startup gate.
Items that affect safety, operability, or startup validity should be corrected and verified before release.
Structure gates, evidence, open items, and advancement criteria in the Commissioning program →
How to Conduct a PSSR Step by Step
A practical methodology can be structured in seven movements. First, define the review scope and the physical/functional boundary of startup. Next, identify applicable requirements, hazards, and documents. The team verifies the status of engineering, construction, PHA/MOC, procedures, training, and commissioning actions. Then the field walkdown takes place, open items are classified, and blocking items are separated from those that can remain under control.
With the evidence consolidated, the team performs the final review and records the decision: released, released with formally accepted conditions, or not released. After the decision, the authorized configuration and residual open items need to be communicated to operations and incorporated into handover records.
The process should make clear who prepared the evidence, who verified each discipline, who holds safety authority, who represents operations, and who approves final release.
PSSR and Industrial Commissioning
PSSR fits between the readiness produced by pre-commissioning and startup itself. In a typical industrial sequence, Mechanical Completion and pre-commissioning demonstrate the technical condition of the system; PSSR confirms safety and operability readiness; startup introduces the operating condition; and hot commissioning and performance testing demonstrate behavior under actual conditions.
This relationship is developed in the article Industrial Commissioning: pre-commissioning, startup, cold and hot testing.
PSSR is a gate within the startup sequence, not the complete commissioning program.
Mechanical Completion, pre-commissioning, safety review, startup, hot commissioning, and performance need to maintain their own ownership and evidence.
Relate PSSR, startup, and cold and hot tests within the industrial sequence →
PSSR and Operational Readiness Review Are Not the Same Thing
An Operational Readiness Review — ORR has a broader operational-readiness scope and may also apply to the return of equipment that has been inactive even without relevant modifications. AIChE distinguishes ORR from PSSR: PSSR is linked to verification of systems before startup or restart of new or modified equipment, while ORR may be used to confirm readiness to return to operation across a broader spectrum.
In large projects, both approaches can coexist. PSSR focuses on the safety gate and essential startup conditions; operational readiness also considers resources, support, maintenance, supply chain, documentation, organization, and the ability to sustain operation after entry into service.
As-Built, Data Book, and Handover After PSSR
Signing the PSSR does not end project governance. The released configuration needs to be transferred to operations together with the documents that represent that condition.
Redlines and changes need to feed the As-Built. Certificates, reports, tests, records, and evidence should be organized in the Data Book. Open items and residual risks need to remain visible during Technical Handover.
This continuity avoids a recurring problem: the project team releases startup knowing about exceptions and temporary conditions, while the operations team receives only final documentation without the context of the decision.
Common PSSR Errors
One of the most serious errors is turning PSSR into a signature-collection exercise. Other recurring problems include starting the review without clear system boundaries, accepting outdated documents, considering training complete without verifying the final configuration, ignoring changes made during commissioning, failing to distinguish startup-blocking open items from minor items, performing the walkdown without representatives of the necessary disciplines, and signing the release without recording conditions or residual risk.
It is also inappropriate to use PSSR to compensate for a weak commissioning program. If tests, inspections, calibrations, and completion did not produce reliable evidence, the final review cannot create that evidence retrospectively.
Executive PSSR Checklist
Before recommending release for startup, the team should be able to answer the essential questions positively: does the as-built condition correspond to the approved design? Have changes been formally addressed? Do P&IDs and critical documents represent the field? Have risk-analysis recommendations required before startup been closed? Are safety, operating, maintenance, and emergency procedures adequate? Have protection functions and critical interlocks been verified? Have startup-blocking open items been closed? Are bypasses and temporary conditions controlled? Has the operating team been trained? Is the startup plan approved? Are responsibilities and abort authority defined? Is the documentation required for operation available?
If a negative answer can affect safety or startup validity, the item should not be treated merely as an administrative observation.
Technical Conclusion
PSSR turns the transition between construction/commissioning and startup into a verifiable safety and operability gate. Its value is not in the form, but in its ability to bring together engineering, field condition, procedures, management of change, training, evidence, and open items into an explicit technical decision.
For industrial projects and critical assets, this discipline prevents schedule pressure from converting incomplete items into operational risk. When integrated from planning onward, PSSR also improves commissioning itself because it requires each party to know in advance which conditions must be demonstrated before startup.
Technical references
[1] OSHA. 29 CFR 1910.119 — Process Safety Management of Highly Hazardous Chemicals, item (i) — Pre-startup safety review.
[2] OSHA. Appendix C to 1910.119 — Compliance Guidelines and Recommendations for Process Safety Management.
[3] CCPS / AIChE. Guidelines for Performing Effective Pre-Startup Safety Reviews. New York: Center for Chemical Process Safety, 2007.
[4] AIChE. The Impact of PSM on Mining, Ports, and Railways: A PSSR Experience. 2025 Spring Meeting and Global Congress on Process Safety.
[5] AIChE. Improving Pre-Startup Safety Review Through Subprocess Review During the Commissioning of Process Units. 2017.
Frequently asked questions
PSSR stands for Pre-Startup Safety Review, a formal review performed before startup to verify that essential safety, design, procedure, training, and management-of-change conditions are ready for operation.
No. Pre-commissioning produces technical readiness verifications for the facility. PSSR uses those and other pieces of evidence to decide whether the safety and operability conditions required for startup have been met.
The requirement cited in this article belongs to the U.S. OSHA 29 CFR 1910.119 regulation for processes covered by PSM. In Brazil, PSSR may be adopted contractually or as a process-safety and governance practice according to the project and its applicable requirements.
Under OSHA PSM, for covered new facilities and relevant modifications. As an engineering practice, it can be applied before startup after implementation, expansion, retrofit, process changes, major interventions, or modifications that affect safety and operability.
Construction/design compliance, safety/operating/maintenance/emergency procedures, treatment of hazard analyses and management of change, training, critical functions, field condition, open items, and startup authorization.
The composition depends on the project, but normally includes operations, engineering, process safety, maintenance, commissioning, and representatives of disciplines or suppliers required to assess startup conditions.
Minor items may remain under formal control when they do not compromise safety or startup validity. Safety-critical items or issues that prevent safe operation should block release until correction and verification.
PSSR focuses on safety and essential conditions before startup of new or modified systems. Operational Readiness Review has a broader operational-readiness scope and may also apply to returning inactive equipment to service without significant modifications.
PSSR is a gate before startup. Its conclusion confirms whether the conditions needed to begin the startup sequence have been verified; execution of startup remains a separate operational stage.
Complementary technical materials
Reference guides and learning paths
Process, readiness, and handover content
- Mechanical Completion in Engineering
- Pre-Commissioning in Engineering
- Industrial Commissioning
- Chernobyl and Commissioning: Critical Tests and Governance
- Construction Data Book
- Technical Handover in Engineering
Related services
