Management of Change (MOC) Process: Template and Implementation Guide
The change looked routine. A pump swapped for a slightly different model, a setpoint adjusted, a procedure tweaked to save a few minutes per shift. No one filled out a form because no one thought it needed one. Months later, an investigator is reconstructing exactly when and why the change happened, and nobody can answer cleanly.
This is the failure mode that Management of Change exists to prevent. Most organizations have an MOC procedure on paper. Far fewer have one that catches the small, well-intentioned changes that accumulate into the conditions for a serious incident. This guide covers what a working MOC process actually requires, how to run the risk assessment and approval workflow that sit at its core, and a template you can adapt.
Track changes and their risk reviews in WhyTrace Plus
WhyTrace Plus links each change request to its risk assessment, approvals, and post-implementation review in one auditable record — so the trail an investigator needs is built as the change happens, not reconstructed afterward.
What Management of Change (MOC) Means
Management of Change is a structured process for reviewing, approving, and documenting any change to equipment, materials, procedures, technology, or organizational structure before it is implemented, so that the safety and operational risks introduced by the change are identified and controlled.
The concept originates in process safety. Under OSHA's Process Safety Management standard, 29 CFR 1910.119(l), employers must "establish and implement written procedures to manage changes (except for 'replacements in kind') to process chemicals, technology, equipment, and procedures; and, changes to facilities that affect a covered process." But the logic applies far beyond regulated chemical processes. Any change that alters how work is done can introduce hazards that the original design controls were never built to handle.
The core distinction MOC draws is between a change and a replacement in kind:
| Term | Definition | MOC required? |
|---|---|---|
| Replacement in kind | A substitution that meets the original design specification exactly | No |
| Change | Any modification to equipment, chemicals, technology, procedures, or facilities outside the original specification | Yes |
| Temporary change | A change intended to be reversed after a defined period | Yes — with an expiry and removal step |
| Emergency change | A change made under time pressure to address an immediate risk | Yes — with expedited review and retroactive documentation |
The trap most programs fall into is treating "replacement in kind" too generously. A pump from a different manufacturer with the same nominal rating is not always a replacement in kind — different seal materials, tolerances, or failure modes can matter. When the question is ambiguous, the safe answer is to run the MOC.
Why MOC Failures Drive Serious Incidents
MOC failure is one of the most consistent contributors to major process safety incidents, because changes bypass the hazard analysis and design controls that protected the original system.
The evidence is direct. The U.S. Chemical Safety Board issued Safety Bulletin No. 2001-04-SB in August 2001 specifically because uncontrolled change had caused fatal incidents — including a 1998 refinery fire in Anacortes, Washington that killed six workers. Analyses of CSB investigation data have found that MOC deficiencies contribute to roughly 9% of chemical process industry accidents, and that a large share of major incidents trace back to changes that were never properly reviewed.
The reason the numbers stay stubborn is structural, not technical. Changes happen constantly, most of them small, and the cost of running a review on each one feels disproportionate at the moment the change is made. The pattern looks like this:
- Small changes escape the net. A setpoint adjustment or a procedure shortcut does not feel like a "change," so no MOC is opened.
- Temporary changes become permanent. A bypass installed "just for this outage" stays in place because nothing forces its removal.
- Cumulative drift. Individually minor changes accumulate until the operating reality no longer matches the documented design basis — and the safety case built on that design basis no longer holds.
- Organizational change is ignored. Restructuring, headcount reductions, and role consolidation change who knows what and who is watching for what. OSHA's interpretation letters confirm that organizational change falls within MOC scope, yet it is the category most often skipped.
The connection to root cause analysis is tight: when an incident investigation reaches the management-system level, an uncontrolled or poorly reviewed change is one of the most common findings. A disciplined MOC process and a disciplined investigation process are two ends of the same loop. (See Human Error and Systems Thinking for why blaming the person who made the change usually misses the system that allowed it.)
The MOC Process: Six Stages
A working MOC process moves a change request through six stages, from initiation to closure, with a documented decision at each gate. Skipping a stage is where most programs break.
1. Initiation and classification
The requester documents what is changing, why, and which systems, processes, and people are affected. The change is then classified — permanent, temporary, or emergency — and screened against the replacement-in-kind test. A change that is genuinely a replacement in kind exits here with a recorded decision; everything else continues.
2. Risk assessment
The proposed change is evaluated for the hazards it introduces or alters. This is the analytical heart of MOC and is covered in detail in the next section.
3. Technical review and approval
Qualified reviewers — engineering, operations, maintenance, EHS, and process safety as applicable — assess the risk assessment and either approve, reject, or send the request back for more information. Approval authority should scale with risk: low-risk changes need a supervisor sign-off; high-risk changes need senior technical and EHS approval.
4. Implementation
The approved change is carried out under defined controls. Pre-startup safety review (PSSR) confirms that affected equipment is fit for service, procedures are updated, and controls are in place before the change goes live.
5. Training and communication
Operators, maintenance staff, and affected contractors are informed and trained on the change before startup of the affected process. This is an explicit OSHA PSM requirement, and it is the step that prevents a correctly engineered change from failing because the people running the process were never told.
6. Documentation update and closure
All affected records — P&IDs, procedures, training materials, the risk register, and process safety information — are updated to reflect the new reality. For temporary changes, the closure step schedules removal and confirms the system returns to its original state. The change is not closed until documentation matches the field.
Build the approval workflow into the record
In WhyTrace Plus, each change request carries its classification, risk assessment, named approvers, and training confirmation in a single workflow. Approvals are gated by risk level, and a temporary change cannot be closed until its removal is confirmed — so drift does not accumulate silently.
Running the Change Risk Assessment
A change risk assessment evaluates the new hazards a change introduces, the existing controls it might defeat, and the likelihood and severity of the resulting outcomes — producing a risk rating that determines the level of review the change needs.
The assessment does not have to be elaborate to be effective. For most changes, a structured question set answered honestly catches the issues that matter:
- What new hazards does this change introduce? (chemical, mechanical, electrical, thermal, ergonomic, environmental)
- Does the change defeat, bypass, or weaken any existing safety control or interlock?
- Does it affect the design basis, operating limits, or process safety information?
- Does it change how operators interact with the process, or what they need to know?
- Are there downstream or upstream systems affected that the requester might not see?
- What happens if the change fails? How is it detected, and how is it reversed?
Score the change on a likelihood-by-severity matrix and use the rating to route it. A typical structure:
| Risk rating | Review depth | Approval authority | Example |
|---|---|---|---|
| Low | Documented checklist, single reviewer | Area supervisor | Minor procedure wording update |
| Medium | Structured risk assessment, multi-function review | EHS + engineering | New non-critical equipment, same duty |
| High | Full hazard analysis (HAZOP, what-if, FMEA) | Senior engineering + EHS + plant management | Change to process chemistry or safety-critical equipment |
For high-rated changes, the risk assessment should connect to a formal hazard analysis method rather than a checklist. A risk matrix keeps the prioritization consistent across reviewers, so a change is not under-reviewed because the requester underestimated its severity. The single most important discipline here is that the requester does not set their own risk rating unchallenged — an independent reviewer confirms it, because the person proposing a change is rarely the best judge of the risk it carries.
MOC Template: Fields You Need
An MOC template captures the information required to review, approve, implement, and close a change in a consistent, auditable form. The following fields cover the requirements of OSHA PSM 1910.119(l) and adapt cleanly to non-regulated changes.
| Section | Fields |
|---|---|
| Identification | MOC number, title, date raised, requester, department, change classification (permanent / temporary / emergency) |
| Description | What is changing, current state, proposed state, reason for change, systems and areas affected |
| Replacement-in-kind screen | Decision and rationale, screener name |
| Risk assessment | Hazards introduced, controls affected, likelihood, severity, risk rating, method used (checklist / what-if / HAZOP / FMEA), assessor |
| Technical basis | Design specifications, codes and standards affected, process safety information impacted |
| Approvals | Reviewer names, roles, approval decision, date, conditions of approval |
| Pre-startup review | PSSR checklist complete, equipment fit for service, procedures updated, confirmed by |
| Training and communication | Affected personnel, training completed before startup, confirmed by |
| Documentation update | P&IDs, procedures, risk register, PSI, training materials — each marked updated |
| Temporary change control | Expiry date, removal responsibility, removal confirmed |
| Closure | Post-implementation review, effectiveness confirmation, closed by, date |
Two fields are routinely omitted and routinely cause audit findings: the replacement-in-kind decision rationale (auditors want to see the thinking, not just the conclusion) and the temporary change expiry with confirmed removal (the field that prevents "temporary" from becoming "forever"). Build both in as mandatory.
The template is only as good as the workflow behind it. A PDF form in a shared folder captures the data but cannot enforce that an approval happened before implementation, that training preceded startup, or that a temporary change was removed on time. That enforcement is exactly where MOC programs fail — the same closed-loop discipline that corrective action management requires, applied to change instead of to findings.
Implementing MOC Without Killing Throughput
A common objection to MOC is that it slows everything down. The fix is not to weaken the process but to scale review depth to risk, so that the 80% of changes that are low-risk move quickly while the few that matter get full scrutiny.
A few principles keep an MOC program usable:
- Tier the workflow. A low-risk change should clear in hours with a single sign-off. Reserve multi-function review for medium and high ratings. Applying full HAZOP rigor to every wording change guarantees that people route around the system.
- Make initiation cheap. The harder it is to open an MOC, the more changes happen without one. A short, mobile-friendly intake form catches more changes than a 12-page document that requires a meeting to complete.
- Define replacement-in-kind tightly but clearly. Give people a concrete test so they are not guessing. Ambiguity defaults to "no MOC," which is the wrong default.
- Audit for the changes that didn't get an MOC. The metric that matters is not how many MOCs you processed — it is how many field changes happened without one. Periodic walkdowns comparing the field to the documentation surface the gaps.
- Close the loop with investigations. When an incident investigation finds an uncontrolled change, feed that back into MOC training and the replacement-in-kind criteria. The two systems should learn from each other.
Organizations regulated under PSM also need to reconcile MOC with the ISO 45001 incident investigation and management-system requirements they operate under. The overlap is substantial: both demand documented decisions, competence and training records, and updated risk assessments when conditions change.
Frequently Asked Questions
Q. Is Management of Change required by OSHA?
Yes, for covered processes. OSHA's Process Safety Management standard, 29 CFR 1910.119(l), requires written MOC procedures for changes to process chemicals, technology, equipment, procedures, and facilities affecting a covered process — with the only exception being replacements in kind. Outside PSM-covered processes, MOC is not a federal mandate, but it is widely treated as a best practice and is referenced in EPA's Risk Management Program and in many ISO management-system implementations.
Q. What is the difference between a change and a replacement in kind?
A replacement in kind is a substitution that meets the original design specification exactly — same material, same rating, same function. A change is any modification that falls outside that specification. When the equivalence is uncertain (for example, a same-rated component from a different manufacturer with different materials or failure modes), the conservative and correct decision is to treat it as a change and run the MOC.
Q. Does MOC apply to organizational changes?
Yes. OSHA interpretation letters confirm that organizational changes — restructuring, staffing reductions, and role consolidation — fall within MOC scope when they affect a covered process, because they alter who has critical knowledge and who is monitoring for hazards. Organizational change is one of the most frequently overlooked MOC categories.
Q. What are emergency changes under MOC?
Emergency changes are modifications made under time pressure to address an immediate risk, where the standard review sequence cannot be completed beforehand. A sound program permits expedited approval by a defined authority, requires the same risk thinking in compressed form, and mandates full retroactive documentation and review once the immediate situation is controlled.
Q. How does MOC connect to root cause analysis?
They are two ends of the same loop. Uncontrolled or poorly reviewed change is one of the most common management-system findings in incident investigations. A strong MOC process prevents the conditions that investigations later uncover, and investigation findings should feed back to tighten MOC criteria and training.
Key Takeaways
- Management of Change controls the safety and operational risk introduced by any modification to equipment, materials, procedures, technology, or organization — and is required for OSHA PSM-covered processes under 29 CFR 1910.119(l).
- The most damaging failures come from small changes that escape the net, temporary changes that become permanent, and organizational changes that are never reviewed. CSB analyses tie MOC deficiencies to a meaningful share of major process safety incidents.
- A working MOC process runs six stages — initiation, risk assessment, approval, implementation, training before startup, and documentation update with closure — with a documented decision at each gate.
- Scale review depth to risk. Tier the workflow so low-risk changes clear quickly and high-risk changes get full hazard analysis; never let the requester set their own risk rating unchallenged.
- A template captures the data, but only a workflow can enforce that approval precedes implementation, training precedes startup, and temporary changes get removed. That enforcement is where most MOC programs succeed or fail.
Related Resources
| Resource | Description | Best For |
|---|---|---|
| Corrective Action Management: Stop Losing Track of Your CAPA Items | Closed-loop tracking with named owners, due dates, and effectiveness verification | Applying the same enforcement discipline MOC needs to findings and actions |
| Risk Matrix Prioritization | How to score likelihood and severity consistently across reviewers | Standardizing the change risk assessment rating |
| ISO 45001 Incident Investigation: Requirements and Best Practices | Clause 10.2 investigation obligations and how change control connects | Reconciling MOC with management-system requirements |
For changes that touch safety-critical work, pair your MOC process with field-level controls. Teams running construction and high-risk operations use AI-assisted hazard prediction for KY activity (AnzenAI) to catch the hazards a change introduces at the point of work, and document near-miss signals through structured near-miss and 4M reporting (AnzenPost Plus). For the root-cause side of the loop, cause analysis and quality improvement workflows (GenbaCompass) connect change failures back to systemic fixes.
Sources:
- 1910.119 - Process safety management of highly hazardous chemicals | OSHA
- Management of Organizational Change | OSHA Interpretation 2009-03-31
- 29 CFR 1910.119 Compliance Guidelines and Enforcement Procedures | OSHA
- CSB Safety Bulletin Says "Managing Change" Is Essential to Safe Chemical Process Operations | CSB
- The Contribution of Management of Change to Process Safety Accidents in the Chemical Process Industry | AIDIC
- Insights into process safety incidents from an analysis of CSB investigations | ScienceDirect