Management of change, or MOC, is the disciplined way a facility evaluates a proposed change before making it, instead of just doing it and hoping for the best. Plants are full of interlocking assumptions - the equipment, the procedures, the chemicals, the operating limits, and the safety systems were all designed to fit together, and altering any one of them can quietly break that fit. MOC is the process that stops a well-meaning change from introducing a hazard nobody thought through: it requires the change to be described, its risks reviewed, its approvals obtained, and the affected drawings and procedures updated, all before it goes live. It is one of the core elements of process safety management.
Management of Change in one line: Management of change (MOC) is the formal process for reviewing, approving, and documenting changes to equipment, procedures, chemicals, or operating limits before they are implemented. It requires a hazard review of the proposed change, appropriate approvals, and updates to affected drawings, procedures, and training - ensuring a change does not introduce an unrecognized hazard.
The reach of management of change is broad, because a hazard can hide in far more than new hardware. Physical changes obviously qualify - installing different equipment, rerouting piping, adding a vessel, changing a pump for one with a different capacity. But so do changes that touch nothing metal. Revising an operating procedure, altering a safe operating limit such as a maximum pressure or temperature, switching to a different chemical or a different supplier's product, or changing the control system's setpoints and logic are all changes that can alter how the facility behaves and what can go wrong. MOC is meant to catch all of them.
The dividing line most facilities draw is replacement in kind versus change. Replacing a failed valve with an identical valve to the same specification is replacement in kind and does not need an MOC, because nothing about the facility's behavior is altered. Replacing it with a different valve - a different size, material, or trim, or one from a different manufacturer with different characteristics - is a change, because it may behave differently and its effects need to be thought through. Getting this distinction right matters, because treating every like-for-like repair as a change buries the system in paperwork, while treating a genuine change as a mere repair is exactly how unreviewed hazards slip in.
This breadth is why MOC is deliberately broader than any change control aimed at a single system. Alarm changes, for instance, have their own focused management of change discipline aimed specifically at the alarm system, but facility MOC sits above that, governing changes to the process and its equipment, chemistry, procedures, and limits as a whole. The general MOC is the one that asks whether a proposed change to the plant itself has been thought through across every dimension it could affect, not just within one subsystem.
An MOC follows a recognizable arc. It starts with a change request that describes what is being changed, why, and what it is expected to achieve - a written proposal rather than a verbal instruction, so the change is on the record from the outset. That request then goes through a technical and hazard review, where people with the right knowledge examine what the change could affect: does it alter the process safety information, introduce a new hazard, invalidate an existing safeguard, or change how the equipment should be operated. The depth of this review scales with the significance of the change, from a brief assessment for a minor one to a full hazard study for a major modification.
If the review is satisfactory, the change moves to approval, where a defined authority - or several, for a significant change - formally signs off that the change may proceed. Approval is a deliberate gate, not a rubber stamp: it is the point at which someone accountable confirms the risks have been assessed and are acceptable. Only after approval is the change implemented, and even then the MOC is not finished, because a change is not truly done until the facility's records catch up with it.
The final and most-neglected part is updating everything the change touches. Piping and instrumentation diagrams, operating procedures, safe operating limits, training materials, and the process safety information all have to reflect the new reality, so the next person who consults a drawing or follows a procedure is not misled by an out-of-date document. A change that is physically installed but never reflected in the P&IDs leaves a trap for everyone who relies on those drawings afterward. This is also where MOC hands off to the pre-startup safety review, which confirms these updates and other readiness items are complete before the changed facility is started.
Many changes managed through MOC land directly on the control and SCADA system, because the control system is where the plant's operating envelope is expressed. Changing a safe operating limit means changing an alarm or trip setpoint; adding equipment means adding tags, displays, and possibly interlocks; revising a procedure often means revising the sequence the control system follows. On a site with a cloud SCADA platform such as Merobix, these are the changes that alter what the operator sees and what the system does, so they belong squarely within the MOC discipline rather than being made informally at the keyboard.
The control system also holds evidence of whether a change was actually implemented as approved. The current setpoints, alarm limits, and configuration reflect the state the plant is really in, so after an MOC that revised an operating limit, the control system should show the new limit in force - and if it still shows the old one, the change was approved but not completed. Being able to see the live configuration gives a facility a way to check that what the MOC authorized is what the system is actually running, closing the gap between the paperwork and the plant.
For remote and multi-site operations, a cloud-based control system makes the state of every site visible from one place, which supports MOC governance across a fleet rather than site by site. When a change is rolled out across many similar remote assets - a revised limit, a new alarm, a control logic update - being able to confirm from a central dashboard that each site's configuration now matches the approved change is what stops a fleet-wide change from being applied everywhere except the two sites someone forgot. The MOC governs the decision; the visibility of the control system confirms the decision reached the field.
A replacement in kind swaps a component for an identical one to the same specification, so nothing about the facility's behavior is altered and no MOC is needed. A change substitutes something different - a different size, material, manufacturer, chemical, procedure, or operating limit - which may behave differently and could introduce a hazard, so it requires an MOC. Drawing this line correctly avoids burying like-for-like repairs in paperwork while ensuring genuine changes are reviewed.
Management of change applies to far more than new equipment. It covers physical changes to equipment and piping, but also changes to operating procedures, safe operating limits such as maximum pressures or temperatures, chemicals or their suppliers, and control system setpoints and logic. Any of these can alter how the facility behaves and what can go wrong, so MOC is designed to catch changes across all of them, not just physical modifications.
A change is not truly complete until the facility's records reflect it, because people rely on drawings and procedures to understand and operate the plant safely. A change that is physically installed but never captured in the piping and instrumentation diagrams or the operating procedures leaves a trap for everyone who consults those documents afterward. Updating them is a required part of MOC, and the pre-startup safety review confirms these updates are done before the changed facility starts up.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.