Most major incidents don’t happen when everything is stable.

They happen when something changes.

A pump is swapped for a “similar” model. A line is rerouted. A valve spec is adjusted. Control logic is updated. Contractors come in for shutdown work. Production pressure speeds up decisions. Documentation trails behind. People assume the change is small because it feels familiar.

That is exactly how risk sneaks in, through normal work that didn’t get treated like a new hazard.

This is why Management of Change (MoC) and Pre-Startup Safety Review (PSSR) exist as a chain, not as separate checkboxes. MoC prevents gaps before the change. PSSR prevents gaps before restart. When they operate as one “no-gaps chain,” your site stops relying on memory and heroics and starts relying on controls you can prove.

This blog explains how to run that chain in a practical, operations-friendly way, without turning it into paperwork theatre.

What “management of change” means in real life (not in a policy document)

Management of change is a structured process to evaluate, approve, and control changes before they are implemented.

That’s the formal definition.

Operationally, MoC is the discipline of asking:
When something changes, what else must change with it to keep risk controlled?

Because a change is rarely just a part replacement. It can trigger:

• new failure modes
• new energy sources or isolations
• new startup steps
• altered alarm logic
• new training needs
• revised procedures and drawings
• different PPE requirements
• contractor-specific hazards
• new inspection or maintenance routines

MoC makes those dependencies visible, assigns owners, and ensures completion before the site moves forward.

What PSSR actually protects you from

PSSR is the “readiness gate” before you start up a new or modified system, equipment, or process.

It answers one question:
Is it safe to start?

PSSR exists because approvals on paper do not guarantee readiness in the field.

Even a well-run MoC can leave gaps if:

• installation differs from design intent
• safety critical devices are not validated
• procedures aren’t updated where people actually use them
• training didn’t reach the last-mile workforce
• isolations are incomplete or unclear
• instruments and interlocks were not function tested
• outstanding actions are rationalized as “we’ll close later”

PSSR prevents the “almost ready” restart, which is one of the most dangerous operational states.

MoC vs PSSR (simple distinction that removes confusion)

MoC and PSSR are often described separately, so teams treat them separately. That’s where gaps open.

Here’s the clean way to think about them:

• MoC controls the thinking before the change.
  What is changing, why, what hazards are introduced, what controls are required, and what must be updated?
• PSSR controls the reality before restart.
  Are the required controls actually implemented, verified, and ready in the real world?

When you run them as a chain, MoC produces a clear readiness plan and action set. PSSR confirms that plan is truly complete before startup.

Why “no-gaps” matters: the hidden failure pattern

In most incident learning, the failure is rarely “no one cared.” It’s usually this:

1. A change happened under time pressure.
2. Risk controls were assumed, not verified.
3. Documentation, training, and field readiness were partially complete.
4. The system restarted.
5. The first abnormal condition escalated faster than teams could respond.

The no-gaps chain prevents partial completion from being treated as completion.

The chain is especially important for:

• critical equipment replacement
• process parameter changes
• control system or logic changes
• temporary bypasses becoming permanent
• contractor-led shutdown and turnaround work
• modifications that affect isolation, ventilation, drainage, relief systems, or interlocks

The no-gaps chain: how MoC flows into PSSR

A strong MoC → PSSR system doesn’t feel like two processes. It feels like one operational path with clear gates.

Gate 1: Define the change with boundaries (so you don’t miss the real impact)

MoC quality starts with clarity.

A change description must be precise enough to prevent “scope drift” but practical enough for site execution. The change boundary should clearly state:

• what equipment/process/document is changing
• what stays unchanged
• which locations, shifts, or teams are impacted
• whether the change is temporary or permanent
• whether it affects safety critical elements or safeguards

This boundary prevents the common trap where teams evaluate one change but execute a slightly different one.

Gate 2: Identify hazards and required controls (not generic risk language)

A MoC hazard review becomes useful when it focuses on:

• what could realistically go wrong because of this change
• what existing safeguards might be weakened
• what new hazards are introduced
• what must be true for the change to be safe

This step works best when it produces explicit control requirements, not just risk scores.

If your site uses HIRA registers, MoC should reference or update them. If it doesn’t, MoC should at least produce “new hazard → control → verification method.”

Gate 3: Convert controls into owned actions (so nothing disappears)

This is where many MoC systems break. Controls stay in meeting notes instead of becoming trackable work.

A no-gaps chain converts required controls into verification actions with:

• an owner
• a due date
• acceptance criteria (what “done” means)
• evidence requirements (what proof is needed)

When actions are vague, teams mark them done by intention. When actions are specific, teams close them by proof.

Gate 4: Update the operational layer (docs, drawings, procedures, training)

Changes rarely fail because engineering drawings weren’t updated. They fail because frontline execution didn’t shift with the change.

A safe change requires the operational layer to be current:

• operating procedures reflect the new steps
• lockout/isolation references match the new configuration
• alarm response guidance matches new logic
• maintenance instructions match new parts and tolerances
• permit controls match revised hazards
• training reaches those who execute, not only those who approve

This is the difference between compliance and readiness.

Gate 5: Execute the work with work control (PTW, isolations, field discipline)

Most MoC changes are implemented through real work, shutdowns, tie-ins, hot work, electrical work, working at height, confined space tasks.

This is where permit-to-work and MoC should connect.

When MoC defines required controls but PTW execution doesn’t enforce them, risk leaks during implementation. When PTW is aligned with MoC, work control becomes consistent.

Gate 6: PSSR confirms readiness before restart (not just completion)

PSSR should be treated like a startup gate, not an administrative wrap-up.

A strong PSSR confirms, in practical terms:

• the change was installed as intended (field reality matches design intent)
• safety critical devices and controls are functional (not assumed)
• procedures and drawings are updated where people use them
• training/communication has reached impacted roles
• outstanding actions are either closed or formally risk-assessed with a temporary control plan
• the startup plan is clear and owned

This gate is where “almost ready” gets stopped.

A real-world example: equipment replacement that looks simple until it isn’t

A pump fails and is replaced with a similar model.

What could change?

• seal type and leak behavior
• vibration characteristics
• motor load profile
• coupling alignment requirements
• spares and maintenance intervals
• isolation points and lockout steps
• startup sequence timing
• trips and alarms if control logic is tweaked

If the change is rushed, teams may restart with:

• incomplete alignment checks
• undocumented changes in isolation references
• untested trips and alarms
• operators unaware of new abnormal signals

In the no-gaps chain:

• MoC captures the boundary and control requirements early.
• Actions assign responsibility for testing, documentation, and training updates.
• PSSR verifies readiness before restart, including functional checks and field validation.

The benefit is not theoretical. It’s operational confidence: a safe restart you can defend.

How to design a PSSR checklist without turning it into a template exercise

A good PSSR checklist is not a long list of generic statements. It is a readiness confirmation aligned to the specific change.

Instead of aiming for “completeness by volume,” aim for “completeness by relevance.”

PSSR becomes meaningful when it confirms:

• process safety-critical controls for the change (interlocks, alarms, relief, isolation integrity)
• mechanical completion and integrity checks relevant to the modified system
• procedures and operating steps that people must follow on day one
• training and communication for those who will operate, maintain, or permit the work
• open items governance with formal risk justification when something cannot be closed before start

If your checklist can be used unchanged for every change, it’s probably too generic to protect you.

Verification actions: the missing link most teams underestimate

Verification actions are the backbone of a no-gaps chain.

They do three things:

1. They prevent MoC controls from living only in documents.
2. They prevent “done” from being defined by intention.
3. They create auditable proof that readiness existed before restart.

The most effective verification actions are those that define:

• what must be tested
• who must sign off
• what evidence is acceptable
• what conditions block startup

This is where operational discipline becomes measurable.

Where OQSHA fits into MoC → PSSR (workflow-first, not feature-first)

OQSHA supports MoC → PSSR execution when it’s treated as a connected workflow:

• MoC is captured with a clear change boundary and required controls
• controls become owned actions with due dates and evidence
• training requirements are tracked so competence matches the new state
• PSSR becomes a readiness gate with proof, not a late-stage formality
• closure and verification remain traceable across teams and sites

Teams typically connect:

• MoC for change initiation, reviews, approvals, and action generation
• PSSR for pre-startup readiness confirmation and gatekeeping
• Training Management for role-based communication and completion proof
• Action Tracker for verification actions, escalations, and effectiveness confirmation

The outcome is one connected record of change controls and pre-startup readiness, useful for safety performance and audit defensibility.

FAQs

---

Closing thought

A safe change is not the same as a completed change.

The difference is whether your site can prove a clean chain:
Change defined → hazards controlled → actions verified → people prepared → startup confirmed.

That is the MoC → PSSR no-gaps chain.