OSHA PSM makes management of change a pre-startup control
For covered processes, a change record is not just an approval ticket: it must address safety and health effects, update affected information, and reach employees before startup.
Editorial figure by Safety Operations Standard. Source context: U.S. Occupational Safety and Health Administration — 29 CFR 1910.119, Process safety management of highly hazardous chemicals.
A change ticket is not the control
Management-of-change software is often demonstrated as a configurable request-and-approval workflow. OSHA's process safety management standard gives covered operations a more exact test. The procedure must distinguish a change from a replacement in kind and address the proposed change's technical basis, safety and health effects, operating-procedure impact, duration, and authorization.
Those requirements make the record a safety argument, not an administrative receipt. A buyer should be able to see who established the technical basis, what hazards were considered, which documents and safeguards were affected, and which authorization allowed the change to proceed. A completed checklist with no supporting evidence does not show that the operating risk was understood.
The boundary starts with scope
The standard applies management of change to process chemicals, technology, equipment, procedures, and facilities for covered processes, while excluding replacements in kind. That boundary should be explicit in the product and in local procedure. If users can label a material modification as routine replacement without evidence or review, the workflow can route the most important decisions around the control.
A useful evaluation set includes one clear replacement in kind, one temporary change, one procedure change, and one equipment or chemistry change. The provider should show how each is classified, what evidence the classification requires, and how contested scope decisions are escalated. The system should preserve the original request and later revisions rather than overwriting the reasoning.
Startup is the control point
OSHA requires affected employees and contract employees to be informed of and trained in the change before startup. The rule also requires affected process safety information and operating procedures to be updated. That turns startup readiness into a cross-record dependency: approval alone should not release the change if training or controlled information remains incomplete.
Buyers should test whether the product can identify the affected population, assign training against the approved change, confirm completion, update controlled procedures and process safety information, and prevent premature closure. Temporary changes need an expiration and an explicit decision to restore, extend, or make permanent. The evidence should remain reviewable after the asset returns to service.
Test one change from proposal through operation
A bounded proof can follow a representative change from initiation through technical review, hazard consideration, authorization, document update, employee and contractor communication, training, pre-startup checks, and final closeout. The acceptance evidence should include identities, timestamps, versions, approvals, exceptions, and the state transition that permitted startup.
OSHA's standard defines legal requirements for covered processes; it does not endorse a software provider or decide whether a particular facility or change is in scope. EHS, process-safety, engineering, operations, and legal owners should establish the facility's applicability and procedure. The product decision is whether the system reliably enforces and evidences that approved procedure.
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
Safety Operations Standard will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.