MOC — Management of Change

In the process industry the consequences of an unmanaged change can be exceptionally severe. A valve is swapped for a different type, a pressure limit is raised, a line is re-routed, an interlock is bypassed. The original hazards of the equipment were analysed at design time; this new state, however, may never have been analysed by anyone. Management of Change (MOC) closes exactly this gap: it makes sure that every modification is reviewed before it is introduced. Let’s look at what MOC is, when it is mandatory, and how it works.

Management of Change (MOC) reviews, assesses and approves every change that is not a like-for-like replacement, before it is implemented.

MOC covers every change affecting technology, equipment, software/logic, organization or procedure; after approval it documents the change, and before startup it verifies it (PSSR). Its purpose is that the change should not introduce an unidentified hazard or an unmanaged risk, that is, the modified state should stay just as safe as the original, designed one. Its cardinal approval criterion is that the risk level after the change may not be higher than the current one; if it would be higher, a risk-reducing measure must bring it back to the pre-change level. MOC is a central element of the process safety management (PSM) system, and in Seveso plants it is a mandatory tool for preventing major accidents.

Figure 1 — the MOC lifecycle: from the proposal through the risk assessment and the two approval gates to the PSSR and the close-out.

Who is this for?

For those who meet change management in practice: plant manager · shift supervisor · process engineer · maintenance engineer · process safety engineer · HSE specialist · reliability engineer.

Learning objectives

After reading this article you will be able to:

• decide what counts as a change and what counts as a like-for-like (in-kind) replacement;
• list the steps of the MOC lifecycle from the proposal through the PSSR to the close-out;
• distinguish permanent, temporary and emergency MOC, and justify why the temporary one is the most dangerous;
• choose the appropriate analysis in a risk-proportionate way (What-If ↔ HAZOP ↔ LOPA/SIL);
• recognize where MOC on its own is not enough, and what has to complement it.

In brief

• MOC = the controlled processing of every change that is not a like-for-like replacement: technology, equipment, material, software/logic (DCS, interlock, alarm), procedure and organization alike.
• The guiding principle: “like-for-like” (in-kind replacement) is NOT MOC; everything else IS. The question is always: could it introduce a new hazard, or could it modify the level of an existing risk?
• The hard decision criterion: the risk level after the change may not be higher than the current one. If it would be higher, approval is conditional on a risk-reducing measure that brings it back to the pre-change level.
• The process has two separate approval gates: the pre-approval gives the green light for design, the approval for implementation; and the PSSR for startup.
• Three MOC types by time: permanent, temporary (max. 1 year, with a mandatory expiry date) and emergency/urgent, which starts on a fast-track route but with full documentation completed afterwards.
• MOC is what ties together HAZOP, LOPA/SIL, the IOW (Integrity Operating Window), alarm management and the ESD system: any modification to them can only go through MOC.
• MOC draws a boundary, it does not forbid: most front-line improvements stay within existing authority, but breaking into a pressure-containing or hydrocarbon-containing envelope can never be a stand-alone decision.
• It is measurable: proposals not assessed within 30 days, overdue actions, expired temporary MOCs, close-out ratio; the indicators must be reviewed monthly, at the site process safety meeting.

Why it matters (the stakes)

In the process industry the consequences of an unmanaged change can be so severe that the industry traditionally permits almost no change that is not the result of disciplined engineering work (Floyd, Liquid Lean). This is why both the OSHA process safety standard and the CCPS model name Management of Change as a stand-alone, mandatory element. A single unreviewed change is cheap in itself; the trouble is the chain reaction it sets off.

Figure 2 — the escalation of an unmanaged change: from the hidden hazard to the major accident. MOC breaks the chain at its very start (with the review before implementation).

The lesson: the cheapest and safest place to control a change is before implementation.

What is MOC, and why is it mandatory in a Seveso plant?

MOC is a systematic procedure for the analytical review of changes made to the documented process technology and/or facilities: it exists so that potential hazards introduced into the process, system or operation are identified before implementation, and then eliminated or controlled. In a Seveso plant every technology change must be routed through it because the major accident prevention policy and the associated safety management system (SMS) explicitly prescribe the management of changes. The hazards of a well-designed plant are identified at design time, so the hazard analysis that underpins the permit loses its validity with the very first unreviewed modification.

This is why MOC is one of the central elements of process safety management (PSM). The regulatory background is given by the US OSHA PSM standard (29 CFR 1910.119), the CCPS Risk-Based Process Safety model and the EU Seveso III Directive (2012/18/EU, in the Hungarian context Government Decree 219/2011); from the functional safety side, IEC 61511 prescribes the management of changes across the whole lifecycle, and ISO 45001 (§8.1.3) as a stand-alone clause.

In practice MOC is not a single sheet of paper but a workflow with a register: every change proposal gets a unique identifier, runs through an approval chain, and its status is trackable (proposed → under assessment → approved → under implementation → closed). Plant MOC registers show exactly this structure: every item has an identifier, an originator, an organizational unit, a technical location (tag number), a description of the change, its reason and a proposed solution, plus an attached PHA / What-If risk analysis.

Process safety systems (following the DuPont taxonomy) distinguish three MOC domains as separate elements: technological change, the small, unnoticed “subtle” change (for example installing a temporary line or using an equipment item temporarily, where isolation or removal is mandatory once the purpose has been reached), and personnel/organizational change. An important boundary: a greenfield investment is not subject to MOC, because there is no existing documented technology to modify.

How does MOC work?

Every change runs through the same chain, but the depth of the process is risk-proportionate: a small procedural modification travels a shorter route than a modification affecting a protection layer.

1) The trigger question: is this a change at all?

A single question opens the MOC gate: “Is this a like-for-like (in-kind) replacement, or a change?”

• In-kind replacement (NOT MOC): replacing a failed part with a piece of exactly the same specification (same type, material grade, pressure rating, characteristic curve). This is handled by the normal maintenance / work permit process.
• Change (MOC needed): everything else, in the five subject areas below.

The subject of the change may be:

• Technological — a parameter limit (pressure, temperature, flow), a modification of the technology instruction / technology card, a feedstock or catalyst change, an operating mode change.
• Equipment / mechanical — construction material, piping, heat exchanger, pump, valve, a new tie-in, installing a bypass, an online probe instead of a corrosion coupon.
• Instrument / control (software), the most frequently underestimated category — DCS configuration, modification of an alarm threshold or logic, a change to a SIL function. A hard threshold: bypassing an interlock from the DCS can be handled with a work permit for up to 1 month, but beyond 1 month it is a change subject to MOC, with a HAZOP/LOPA/SIL analysis.
• Procedure / documentation — SOP, startup/shutdown procedure.
• Organizational / personnel — every headcount and position change must be handled according to pre-defined criteria, because the movement of experienced people invalidates the earlier hazard analysis just as much as a technical modification: the analysis was built on the assumption that competent people are present and accountable for the area. For this, the site must define the process safety critical positions and the knowledge, skills and abilities required for them.

The traps of like-for-like (selection matrix)

It is not the obvious modifications that cause the trouble, but the “almost the same” replacements. The rule: even a change believed to be an improvement is a change, and it may have unintended consequences.

Change	What is the concern?	Suggested analysis
Stainless steel instead of carbon steel	pitting corrosion in a chloride-bearing medium	HAZID / What-If
Thicker-wall (higher pressure rating) pipe	the heavier wall may invalidate the pipe flexibility calculation	HAZID / What-If
A larger impeller in the pump	the downstream equipment cannot take the increased flow, the higher discharge head lifts the relief valves	HAZID / What-If
A single seal instead of a tandem seal	greater chance of leakage, different maintenance requirement	HAZID / What-If
Installing a new valve where there was none	a new leak point, a new “no flow” cause, an isolatable pipe section without overpressure protection	HAZOP / LOPA
Throughput above the nameplate capacity	the capacity of the relief system and the basis of the installation studies become questionable	HAZOP / LOPA
Moving a trip point outside the safe range	a hazardous operating state may arise	HAZOP / LOPA / SIL

Figure 3 — risk-proportionate choice of analysis: the nature of the change decides how deep a hazard analysis is mandatory.

2) MOC types

Beside the three domains (technological, subtle, personnel), the other axis is the planned duration of the change:

Type	When	Characteristics
Permanent	The planned duration of the change is indefinite (typically until the end of the plant’s life cycle)	Full review, documentation update, often an investment (CAPEX)
Temporary	A state set for a fixed period, to be restored afterwards (e.g. bypass operation)	A planned duration of at most 1 year, with a mandatory expiry date and an owner for the restoration; it must be reviewed at least annually to check whether the risk has increased significantly. If it does not continue, the unit must return to the original design envelope
Emergency / urgent	Immediate intervention, no time to procure the proper equipment	Execution may be authorized by the business unit leader. An immediately documented trace (e.g. in the plant log) is required of the pre-hazard analysis performed (pre-PHA), and once the situation is made safe, every step must be completed properly afterwards. Generally to be treated as temporary; it can be made permanent only through an appropriate, documented risk assessment procedure

3) The steps of the lifecycle

Digital MOC systems run a 12-step lifecycle with two separate approval gates: the pre-approval gives the green light for design, the approval for implementation. Every step has a maximum lead time, so that a proposal does not get stuck.

#	Step	What happens	Max. lead time
1	Change initiation	technical location (tag), background, the reason for the change, proposed solution	5 days
2	Preliminary assessment	is it feasible, who is affected	30 days
3	Evaluation	full evaluation of the scope, the impacts and the risks, actions	30 days
4	Pre-approval (for design)	can only be given if the checklist of steps 2 and 3 is 100% fulfilled	7 days
5	Detailed design / technical solution	implementation solution, project documentation, CAPEX	1–150 days
6	Pre-implementation analysis	risk review of the finished technical solution	15 days
7	Approval (for implementation)	the responsible manager confirms: the risks are acceptable	7 days
8	Implementation, documentation update, training	only in line with the approved proposal; on postponement it must be re-evaluated	1–1100 days
9	PSSR	pre-startup safety review (see below)	30 days
10	Go-live	the team watches the change under real conditions	7 days
11	Finalize documentation	P&ID, as-built drawings, procedures, equipment manuals finalized	1–120 days
12	Validation and close-out	every action closed with documented evidence	7 days

At approval the question is always the same: does the process safety risk level increase? If it would, approval is conditional on a measure that brings it back to the starting level. Approval is often tied to further conditions (“can only be implemented during a turnaround”, “an additional measurement is required”).

In parallel with the implementation, every affected document is updated: P&ID, technology instruction / card, SOP, alarm database (Master Alarm Database). If this is left out, the documentation and reality diverge, which is a source of incidents in itself. The MOC dossier must be retained for the whole lifetime of the facility.

The critical success factor of MOC: inherent safety

The risk assessment should not merely accept the proposed solution but look for the safer variant. Four principles: Minimize (less hazardous material present), Substitute (swap to a less hazardous material), Moderate (milder conditions, for example a dilute or cold form instead of high-pressure gas), Simplify (design the problem out, do not manage it with yet more equipment).

The 10-point minimum checklist of the PSSR. Startup may be authorized by the responsible plant manager only after a signed PSSR; for a technology change a detailed one is required, for other types a simplified PSSR may suffice.

1. does the implementation conform to the design specification;
2. have the inspection and testing programmes been adjusted;
3. has the change been carried through into the “as-built” update of the P&ID;
4. have all actions arising from HSE studies been closed;
5. have the regulatory inspections taken place;
6. has the training been completed;
7. have the safety interlocks been tested, and has the logic description been updated;
8. are the safety data sheets available;
9. are the (temporary) operating instructions available;
10. has the fire protection been adjusted, and have the plans been updated.

Figure 4 — the discipline of the temporary MOC: without an expiry date and an owner, the “temporary” becomes permanent.

Process industry context + safety

MOC is not an administrative burden but the guardian of the integrity of the protection layers. Five typical cases where it decides on safety:

• Construction material change (e.g. a heat exchanger bundle or piping to a different material grade): corrosion, temperature tolerance, crack sensitivity may change → it may also affect the parameters of the IOW (Integrity Operating Window). Reliability practice holds that a working MOC belongs to the IOW, one that identifies every change affecting the integrity of pressure-containing equipment.
• Modification of a pressure / temperature limit (a real case: on the technology card of a tubular reactor, lowering the lower inlet temperature limit for energy optimization, without any physical modification): this is a technology instruction / card modification, hence MOC.
• Modification or removal of an interlock (e.g. deleting a high-level interlock because the protected function has ceased): this is a SIL/LOPA-sensitive change. Alarm and ESD modifications must comply with the HAZOP/LOPA/SIL expectations.
• Feedstock change (e.g. processing a by-product gas as feedstock): new components, coke formation, furnace integrity → new hazards that must be assessed before the change.
• Installing a new tie-in / bypass: a new flow path, a new possibility of mixing or overpressure → a P&ID update and a PHA are mandatory.

Alarm management and the ESD system are also MOC-driven: the redesign of faulty alarms and logics starts with an MOC procedure, and the ESD lifecycle has “Modification through MoC” as a distinct phase. The bypass register and the trip test belong here too: every disabled protection must be registered and restored.

Key message for the HSE manager: MOC is the place where HAZOP / LOPA / SIL does not remain a one-off design act but becomes a living, up-to-date protection system.

Putting it into practice (roadmap)

Introducing MOC is not a software question: it needs up-to-date base documentation, a written scope definition and a single register in which every change proposal appears.

Phase 0 — Foundations (prerequisite). Up-to-date P&IDs, technology cards, SOPs. Building MOC on outdated documentation is an illusion.

Phase 1 — Policy, scope and the sources of change. A written MOC procedure: what counts as a change, what is “like-for-like”, what types there are, what risk categories. The most frequent implementation failure is that the change simply bypasses the system, so identify every source from which an MOC proposal may arrive: normal operation, efficiency improvement, other improvement, test run / trial run, organizational change, change made permanent, action arising from a risk assessment, action arising from an incident investigation, legal requirement. Define the roles (originator, evaluator/process engineer, safety engineering, approver, PSSR owner, closer), and name the MOC coordinator: they are the main administrator of the system, involve the affected organizations, check, track the task statuses, report the overdue actions, and they close the MOC.

Phase 2 — Register and template. A single, central MOC register with a unique identifier. The mandatory fields of the proposal template: organizational unit, technical location (tag), background, the reason for the change, proposed solution, risk classification; with an extract of the P&ID, a What-If/PHA and a drawing attached.

Phase 3 — Risk assessment and PSSR gate. Tie the depth of the mandatory analysis to the risk category (What-If ↔ HAZOP ↔ LOPA/SIL); if a protection layer is affected, a SIL review is mandatory. The change may not start without a signed PSSR.

Phase 4 — Temporary MOC discipline. Every temporary MOC gets an expiry date and an owner, with an automatic reminder before expiry and a review at least annually.

Phase 5 — Integration and audit. Tie a document-update checklist to the MOC (P&ID, technology card, SOP, Master Alarm DB). Introduce MOC KPIs (below) and an annual audit.

Phase 6 — Culture (the Lean bridge). Make the process transparent and fast, so the front line does not want to avoid it. The goal: colleagues improve on their own initiative, always within the MOC framework.

Hands-on / mini-scenario

Walk a change all the way through. A process engineer wants to raise the inlet pressure limit of a reactor. Work through the MOC logic:

1. In-kind replacement? No: a parameter limit changes → MOC is needed (even if not a single bolt is replaced).
2. Type and risk? Permanent, technological; does it affect the integrity of pressure-containing equipment (IOW) or a protection layer (relief valve, high-pressure interlock)? If yes → LOPA/SIL review.
3. The areas to be examined as a minimum in the review report: is a plant test run, a simulation run or a laboratory experiment needed, how do product quantities and qualities change; and depending on the case, isolatability, overpressure protection, drainability, the fit with the connected plant sections, the control system change and the interaction of the materials. The report has a threefold structure: Opinion → a separate statement from a process safety point of view → Further tasks and owners (with a named owner and a deadline).
4. Approval with conditions? E.g. “only with an additional pressure measurement”, “can be implemented during a turnaround”.
5. PSSR before startup: documentation (P&ID, technology card) updated, operators trained, PHA recommendations closed.
6. Close-out + trace: what, why, who, when.

Homework. Pick a recent change in your own area and reconstruct it: was it subject to MOC, what type was it, how deep an analysis would have belonged to it, and would it have had a PSSR gate?

Measurement / audit (indicators, with formulas where available)

MOC is alive only if it is measured. Process industry practice prescribes four basic indicators, and also that these must be reviewed regularly, monthly, at the site process safety (PSM) meeting:

1. The number of change proposals not preliminarily assessed within 30 days (is the front end of the system clogging up);

2. the number of overdue actions;

3. the number of overdue, expired temporary MOCs, the most telling health indicator:

   Expired temporary MOC ratio = (open temporary MOCs past their expiry deadline) / (all open temporary MOCs) × 100%

   Target: durably towards 0. (Analogous to reducing the number of disabled interlocks.)

4. the ratio of closed / implemented changes (%).

Professionally recommended supplementary indicators: MOC lead time (if it is too long, the front line bypasses it; if it is suspiciously short, the evaluation is superficial), PSSR coverage (target: 100%), the age of open MOCs, documentation synchronization and MOC-originated incidents / near-misses.

Audit focus points: sample-based checking that (a) closed MOCs have a risk assessment and a PSSR; (b) the P&ID really reflects the change (field walk vs. drawing); (c) there is no “orphan” temporary change in the field without an open MOC; (d) the interlock/bypass register is up to date.

Common mistakes

MOC rarely fails because of a bad procedure: almost always it fails because a change slips past the system unnoticed, or because nobody closes a state that was opened. The most typical failure patterns:

• “Just a quick modification”, that is, a change disguised as like-for-like. A different type, a different material, a different characteristic curve is NOT an in-kind replacement any more. The most frequent trap.
• A temporary that lasts forever. Without an expiry date and an owner, the “temporary” bypass survives for years, undocumented, and nobody remembers why. A long interlock bypass is not a work permit matter either: beyond 1 month it is subject to MOC.
• Forgetting the software/logic change. Many people “MOC” only the physical modification; a DCS, interlock, alarm and SIL modification is just as subject to MOC.
• Skipping the PSSR under pressure. The “let’s start it up and document it afterwards” attitude leads to startup incidents.
• The documentation is not updated. Because the P&ID, the technology card and the SOP are left behind, reality and paper diverge; the next HAZOP starts from a wrong baseline.
• Emergency MOC as a loophole. The emergency route exists so that we can act fast, not so that we can save ourselves the documented trace of the pre-hazard analysis and the subsequent completion.
• Over-bureaucratized MOC. If every trifle travels the same heavy route, people go around it. Risk-proportionate depth (What-If ↔ HAZOP ↔ LOPA) is the answer.
• Leaving out organizational change. The loss of a key competence and a headcount reduction invalidate the earlier hazard analysis just as much as a technical modification, which is why they must be brought under MOC, on the basis of pre-defined criteria and the list of process safety critical positions.

When NOT to use MOC on its own? (the limits of the method)

MOC is indispensable, but it is not omnipotent. Knowing where it is not the answer is just as important:

Situation	Why MOC does not solve it	What is needed instead / alongside
In-kind replacement (like-for-like)	there is no change, there is no new hazard	normal maintenance / work permit (PTW)
Greenfield investment	there is no existing documented technology to modify	project and design HAZOP, then PSSR
The basic design is weak	MOC keeps a faulty system going “by the book”	design review, HAZOP at the root
The base documentation is outdated	building MOC on an outdated P&ID is an illusion	documentation restoration first, MOC afterwards
A human/cultural cause	even the strictest MOC can be circumvented	a fast, proportionate process + leadership commitment

Rule of thumb: MOC controls the change. It does not replace good design, up-to-date documentation and the HAZOP, but keeps them alive.

Take it home (keys)

• The risk may not increase: this is the single hard approval gate of MOC; if it would increase, the risk-reducing measure has to come first.
• “Like-for-like” is NOT MOC; everything else IS, including software, logic and the organization.
• The temporary is the most dangerous: at most 1 year, a mandatory expiry date and owner, an annual review.
• No startup without a PSSR: ready-to-implement is not the same as ready-to-start, and the signature is the gate.
• MOC is what keeps the HAZOP alive: it is precisely the series of non-MOC’d changes that makes a hazard analysis obsolete.

Self-test

1. A pump is replaced with the same type, but with an impeller one size larger for a better yield. Is this subject to MOC? Justify your answer.
2. List the steps of the MOC lifecycle from the proposal to the close-out, and say which gate prevents startup with unclosed conditions.
3. Why is a temporary MOC more dangerous than a permanent one, and which two elements make it controllable?

How does this show up in digital practice?

MOC works on paper too, but it becomes truly enforceable as a digital workflow: not a single step can be skipped, and the whole trace stays auditable.

MOC principle	Digital implementation	What it prevents
Enforced approval chain	the proposal does not move on without the mandatory approvals (and the 100% checklist)	approval given without authority, or skipped
PSSR gate	the “ready/startable” state is locked until the PSSR checklist is ticked off	startup with an unclosed PSSR
Risk-proportionate analysis	the risk classification automatically makes the HAZOP/LOPA a mandatory field	a missing risk assessment
Expiry of a temporary MOC	expiry date, automatic reminder and annual review	the “everlasting” temporary change
Documentation synchronization	close-out checklist: P&ID / SOP / alarm DB update acknowledged	documentation that differs from reality
Full lifecycle trace	every status change is recorded with a timestamp and an owner	the untraceable change

Connection to OPEREX (shift log)

An MOC rarely fits into a single shift: days to weeks pass from the proposal to the PSSR and the close-out, and the greatest information loss arises at the shift change, where the formal MOC system is blind. The OPEREX shift log adds this layer: the interim state of an MOC in progress can be handed over (what has been implemented, what the open condition is), the temporary changes (an active bypass, a disabled interlock) are visibly recorded together with their restoration deadline, and the early observations stay there too. The emergency MOC carries particular weight: for an urgent intervention an immediately documented trace of the pre-hazard analysis must be left in the plant log, and it is precisely this entry from which the subsequent, proper documentation can be built up.

Terminology (HU / EN)

Hungarian	English	Note
Változáskezelés	Management of Change (MOC)	The process as a whole
Azonos csere	Like-for-like / in-kind replacement	NOT MOC
Indulás előtti biztonsági felülvizsgálat	Pre-Startup Safety Review (PSSR)	Mandatory gate before startup
Folyamat-veszélyelemzés	Process Hazard Analysis (PHA)	The collective name for HAZOP / What-If / HAZID
Védelmi réteg elemzés	Layer of Protection Analysis (LOPA)	Risk ↔ protection layers
Integritás-üzemeltetési ablak	Integrity Operating Window (IOW)	The parameter range that guards integrity
Ideiglenes / állandó / rendkívüli MOC	Temporary / Permanent / Emergency MOC	The three main types
Folyamatbiztonság-irányítás	Process Safety Management (PSM)	MOC is an element of it
Vészleállító rendszer	Emergency Shut Down (ESD)	Its modification goes through MOC

FAQ

What kind of change does not require an MOC?

The “in-kind replacement” (like-for-like): replacing a part with a piece of exactly the same specification (type, material grade, pressure rating, characteristic curve). This is handled by normal maintenance. As soon as the replacement differs in any essential characteristic, an MOC is needed.

Is resetting a DCS parameter or an alarm threshold subject to MOC?

Yes, if it is relevant from a safety point of view (interlock, alarm, SIL function, technological limit value). A “software/logic” change can introduce just as much hazard as a physical modification — indeed it is often less visible, and therefore more dangerous. A concrete threshold: bypassing an interlock from the DCS can be handled with a work permit for up to 1 month, beyond that it is subject to MOC, with a HAZOP/LOPA/SIL analysis.

What is the difference between an emergency MOC and a normal MOC?

An emergency MOC comes into play when the change has to be introduced quickly and there is no time to procure the proper equipment; execution may in that case be authorized by the business unit leader. In exchange, an immediately documented trace (for example in the plant log) must be left of the pre-hazard analysis performed, and once the situation is made safe, every step must be completed properly afterwards. By default it must be treated as a temporary change; it can be made permanent only through an appropriate, documented risk assessment procedure.

How does MOC relate to the HAZOP?

The HAZOP analyses the hazards of the designed state. MOC makes sure that every later modification is reviewed as well, in a risk-proportionate way, with a What-If, HAZOP or LOPA/SIL tool. It is precisely the series of non-MOC’d changes that makes a HAZOP obsolete.

In a Lean/Kaizen culture, do the many front-line improvements not clash with a strict MOC?

No, on the contrary, they presuppose each other. Most Lean practices do not require formal change management and fit within existing authorities: MOC does not forbid, it draws a boundary. The boundary, however, is hard, and it is worth saying out loud: breaking into a pressure-containing or hydrocarbon-containing envelope can never be a stand-alone front-line decision. By stating exactly what is not allowed, we make clear what is; a well-built MOC therefore does not brake improvement but releases it.

Related concepts

HAZOP | LOPA and SIL | near-miss | safety cross | kaizen

Next step

If you understand MOC, the process safety picture builds on from here:

1. HAZOP — the hazard analysis that is the risk assessment engine of MOC for high-risk changes.
2. LOPA and SIL — the protection layers and functional safety (SIL); mandatory for an interlock or ESD change.
3. near-miss — the weak signals that often point back to an unmanaged change.

References / further reading

• US OSHA: Process Safety Management of Highly Hazardous Chemicals — 29 CFR 1910.119 (“Management of Change” as a mandatory PSM element).
• CCPS (AIChE): Guidelines for Risk-Based Process Safety — Management of Change as a stand-alone RBPS element.
• Seveso III Directive: 2012/18/EU on the control of major-accident hazards involving dangerous substances (change management is part of the safety management system).
• IEC 61511 — functional safety: the handling of changes under MOC across the whole lifecycle.
• ISO 45001:2018 — §8.1.3 “management of change”.
• Raymond C. Floyd: Liquid Lean: Developing Lean Culture in the Process Industries. CRC Press, 2010.
• Trevor Kletz: the principles of inherently safer design (Minimize, Substitute, Moderate, Simplify).