What is Change Management?

Change Management is the process by which an organisation requests, assesses, approves, tests, implements and records changes to systems, applications, infrastructure and configurations in a controlled way, so that each change delivers its intended result without unplanned disruption or new risk. The process industries have a closely related variant: Management of Change (MOC), the process safety discipline for changes to plant, chemicals, procedures and organisation. Almost every framework for IT and OT requires some form of change control, from ITIL and ISO 27001 to IEC 62443, IEC 61511 and GxP rules such as GMP.

Note that the same term is also used for organisational change management, meaning guiding people through a reorganisation. This article covers technical change management and MOC.


🎯 Why is Change Management important?

Changes are a common cause of outages: a wrong firewall rule, a patch that breaks a driver, or a PLC modification with an unintended side effect. Change Management makes sure someone thinks about impact and fallback options before the work starts.

  • Managing risk - every change gets an impact and risk assessment proportionate to its size
  • Preventing unplanned downtime - changes are scheduled in maintenance windows, with a back-out plan
  • Aligning departments - IT, OT, production, Security and quality know what is changing and when
  • Traceability - decisions, approvals and test results are recorded, which is the basis for any audit
  • Compliance - demonstrable conformity with ISO 27001, GMP, NIS2 and the Dutch Cybersecurity Act
  • Configuration integrity - together with Configuration Management and a CMDB, you keep knowing what your systems actually look like

πŸ” What types of changes are there?

ITIL 4 distinguishes three types of change. In ITIL 4 the practice is now called change enablement; the 2019 Foundation edition still used the term change control.

Type Characteristic Approval OT example
Standard change Low risk, frequent, fixed procedure Pre-approved as a model; not reassessed every time Replacing a faulty transmitter with an identical model
Normal change Risk and impact must be assessed each time By the change authority, advised by a CAB for high-impact changes New version of PLC logic or a SCADA upgrade
Emergency change Must happen as soon as possible, for example during an outage or for an actively exploited vulnerability Expedited, by a small authorised group; documentation and review follow afterwards Blocking traffic with a firewall rule during a cyber incident

ITIL 4 no longer makes a Change Advisory Board (CAB) mandatory for every change. The change authority can differ per type: a team lead for minor changes, a CAB or management for major ones. That way a small adjustment does not wait weeks for a meeting.


πŸ“„ How does the Change Management process work?

  1. Request (RFC) - a Request for Change describes what changes, why, which systems are affected and who owns it.
  2. Classification - determine the type, impact, risk and urgency. Does the change touch a safety function, a validated system or a security zone?
  3. Assessment and approval - by the change authority or a CAB, with the right disciplines involved.
  4. Preparation and testing - in a test environment, a simulation or on a spare installation; take a backup and write the back-out plan.
  5. Implementation - as planned, within the agreed window and with the appropriate work permit when work is done on the plant.
  6. Verification and closure - check the result, update documentation and drawings, record the configuration and capture lessons learned.

If a change fails and causes an outage, the process hands over to incident management and, where needed, a root cause analysis.


πŸ” How is Change Management different in OT environments?

In a factory, water treatment plant or power grid, a change affects not just data but physical processes. That brings extra considerations:

  • Safety first - changes to a SIS fall under clause 17 of IEC 61511: first an impact analysis, then a return to the appropriate phase of the safety lifecycle and re-verification and re-validation of the affected safety functions and their SIL.
  • Production sets the timing - many OT changes can only be made during a planned shutdown or turnaround, which is why patching often happens months later than in IT.
  • Online changes to PLCs - many PLCs accept changes while the process keeps running. That is convenient, but without records you lose track. Regularly compare the loaded logic with the approved version in version control.
  • Temporary changes - jumpers, forces and bypasses are changes too. Set an expiry date and check that they are removed.
  • Engineering access - changes should go through a managed engineering station, not an arbitrary laptop. Suppliers work through controlled remote access within an approved change.
  • Operation and HMI - alarm limits, setpoints and screens are configuration as well; include them in the assessment, together with changes to alarm management, especially where Real-time control is affected.
  • Validated systems - in pharma, changes must be validated according to GMP and GAMP, with an audit trail as required by 21 CFR Part 11 that keeps the data integrity of every change demonstrable.

🏭 What is Management of Change (MOC) in process safety?

Management of Change (MOC) is the process safety procedure that requires every change to the process chemicals, technology, equipment, procedures or organisation of a hazardous installation to be assessed, approved and recorded before it is made. Where IT change management mainly protects the availability and integrity of systems, MOC looks at the potential for fire, explosion, toxic release and injury.

The classic lesson is the Flixborough disaster in the United Kingdom on 1 June 1974. After a crack was found in reactor 5 of a cyclohexane plant, that reactor was removed and replaced by a temporary bypass pipe between reactors 4 and 6, without design calculations, drawings or a pressure test. The pipe failed, the released vapour exploded and 28 people were killed. Ever since, the rule has been that a temporary or β€œminor” modification is still a change.

What do regulations require of MOC?

  • OSHA PSM, 29 CFR 1910.119(l) - the US process safety standard requires written procedures for changes to process chemicals, technology, equipment, procedures and facilities. Before the change, the technical basis, the impact on safety and health, modifications to operating procedures, the time period of the change and the required authorisation must be addressed. Affected employees are informed and trained before start-up, and the process safety information and procedures are updated.
  • Replacement in kind - a replacement that satisfies the design specification falls outside MOC. A pump made of a different material or with a different capacity is therefore a change.
  • Pre-startup safety review (PSSR) - required for new facilities and for modifications that change the process safety information.
  • Seveso III Directive - management of change is one of the seven elements of the safety management system, alongside organisation and personnel, hazard identification, operational control, emergency planning, performance monitoring and audit and review. In the Netherlands those rules moved from the Brzo 2015 into the Environment and Planning Act (Omgevingswet) on 1 January 2024 (see Seveso and Cybersecurity).
  • Management systems - ISO 45001:2018 has a dedicated clause 8.1.3 Management of change; ISO 9001:2015 requires planning of changes (6.3) and control of changes in production (8.5.6).

Which changes fall under MOC?

Type of change Examples Typical risk analysis
Technical New pump, different PLC, rerouted piping HAZOP or what-if study
Software and automation SCADA update, modified SIS logic, new alarm limit Impact analysis per IEC 61511, possibly LOPA
Procedural Different work instruction or cleaning procedure Checklist and task risk analysis
Organisational New allocation of tasks, fewer operators per shift Staffing and competence analysis
Recipe and production Different raw material or process parameter FMEA or HAZOP of the modified process

Which systems support MOC?

System Role in MOC
QMS Recording, approving and tracking change proposals
LIMS Re-evaluating analytical methods after a change
SCADA and DCS Logging and comparing software and configuration changes
ERP Updating product structures, bills of materials and work instructions
SIS Verifying and validating modified safety logic

πŸ”„ How do Change Management and MOC relate to each other?

Aspect Change Management Management of Change (MOC)
Focus Changes to IT and OT systems, software and configurations Changes to process, plant, chemicals, procedures and organisation
Origin IT service management (ITIL, ISO/IEC 20000) Process safety (OSHA PSM 29 CFR 1910.119(l), Seveso III Directive)
Owner IT, OT operations or the ISMS HSE, engineering, process safety
Risk analysis Impact on availability, integrity and security Safety and environmental impact, often using HAZOP or LOPA
Exempt Standard changes Replacement in kind: replacement that meets the design specification

In practice the two overlap. A new version of SIS logic is both a software change and a process safety change. Mature organisations link the processes: an MOC refers to the related IT/OT change and vice versa, so neither team misses a change.


πŸ“š Which standards and laws require Change Management?

Framework Where What it requires
ISO 27001:2022 Annex A, control 8.32 Changes to information systems and processing facilities follow change management procedures; ISO 27002 provides the guidance
IEC 62443-2-1:2024 Asset owner security programme Controlled change as part of the OT security programme; edition 2 was published in August 2024
IEC 62443-2-4 Requirements for service providers, functional area SP.06 (configuration management) Integrators and maintenance providers must make and record changes in a controlled way
IEC 61511 Clause 17, modification Management of change for every modification to a SIS
NIST SP 800-53 Rev. 5 CM-3, Configuration Change Control Assess changes for security impact, approve, document and monitor them; NIST SP 800-82 Rev. 3 applies this to OT
EU GMP Annex 11 Section 10 Changes to computerised systems, including configuration, only in a controlled manner according to a defined procedure
Cybersecurity Decree Article 11 Configuration and change management as part of acquisition, development and maintenance

For digital service providers under NIS2, such as cloud and managed service providers, Implementing Regulation (EU) 2024/2690 is even more specific. Section 6.4 requires procedures for releases, modifications, emergency changes and configuration changes, risk-based testing, and a record of why the normal procedure was bypassed in an emergency.


🧭 How do you set up Change Management in OT in practice?

  1. Map your assets - without an up-to-date inventory you cannot tell what a change affects.
  2. Define what counts as a change - record which items fall under the process: PLC logic, firmware, network and firewall configuration, HMI screens, alarm limits and accounts.
  3. Create a catalogue of standard changes - for example replacing identical parts or adding a user according to procedure. This keeps the process workable.
  4. Form a mixed change authority - with process experts, OT operations, security and, where needed, functional safety and quality.
  5. Link to MOC - have the IT/OT change form ask whether the change affects process safety; if so, an MOC is started automatically.
  6. Always write a back-out plan - with a tested backup of the previous configuration and a clear decision point for rolling back.
  7. Check afterwards - compare the configuration with the approved version and detect unauthorised changes using version control or network monitoring.
  8. Measure and improve - track how many changes succeed, how many emergency changes there are and how many outages are caused by changes.

A high share of emergency changes is a signal that planning or the regular process is not working well.


❓ Frequently asked questions

What is an RFC in Change Management?

An RFC (Request for Change) is the formal request used to propose a change in Change Management. The RFC describes what changes, why, which systems are affected, the risk and the back-out plan. Based on the RFC, the change authority decides whether to approve it.

Is a CAB mandatory?

A Change Advisory Board is no longer mandatory for every change in ITIL 4. ITIL 4 uses a change authority that can differ per type of change, and a CAB mainly advises on high-impact changes. Standards such as ISO 27001 do require controlled approval, but they do not prescribe a CAB meeting.

When do you start a Management of Change (MOC)?

You start a Management of Change (MOC) for every change to the process chemicals, technology, equipment, procedures or organisation of a process plant that is not a replacement in kind. Temporary modifications, such as a bypass pipe or a bypassed safety function, are included. Before start-up, staff are trained and the process safety information is updated.

How should you handle emergency changes in OT?

An emergency change in OT is approved on an expedited basis by a small, authorised group, but it still falls under Change Management. Record the change immediately afterwards, justify why the normal process could not be followed and review whether the change should become permanent. Implementing Regulation (EU) 2024/2690 likewise requires such emergency deviations to be documented.

Is patching a change?

Yes, installing a patch is a change and should go through Change Management. In OT, a patch is first tested for compatibility with the vendor’s configuration and then rolled out in a maintenance window with a back-out plan. Regular, well-tested patches can be classified as standard changes.

Does a PLC modification fall under Change Management?

A modification to PLC logic, parameters or firmware falls under Change Management, even when the PLC allows online changes. If the modification affects a safety function, it is also an MOC and the modification requirements of IEC 61511 apply. Keep every approved version in version control so you can roll back and unauthorised changes stand out.


πŸ“Œ In summary

Change Management ensures that every change to IT and OT systems is assessed, approved, tested and recorded in advance, with a back-out plan if things go wrong. Management of Change (MOC) does the same for process safety, built on OSHA PSM and Seveso III. ISO 27001, IEC 62443, IEC 61511, EU GMP Annex 11 and the Dutch Cybersecurity Decree make change control a firm requirement.