OT Management of Change for Cyber: Adding Security Review to Every Plant Change

Most industrial sites already run a management of change (MOC) process that checks every plant modification for process safety, yet a PLC logic download, a firmware update or a new remote access path can pass through it without anyone asking what it does to cyber risk. MOC is the right place to fix that, because it is already mandatory, already staffed and already trusted by operations. This guide shows how to add a cyber review to an existing MOC workflow: which changes trigger it, what the reviewer checks, how to handle temporary and emergency changes, how to prove that what was downloaded matches what was approved, and how to measure whether the process works. It is written for OT security engineers, process safety and control system engineers, and site managers who own the MOC procedure. Patch qualification is covered in the OT Patch Management Guide and IT change control in the Change Management Security guide; this page covers the plant change process itself.

Key takeaways

• Extend MOC, do not build a parallel process. Engineers will route around a second approval system; a cyber section inside the existing MOC form gets used.
• Cyber changes are changes. Logic, firmware, set points held in controllers, network paths, accounts and remote access all belong in MOC scope, and "replacement in kind" needs a cyber definition, not just a mechanical one.
• Safety and security review together. NIST SP 800-82 Rev. 3 expects OT security and safety staff both to take part in change impact analysis, because a security control can create a process hazard and the reverse.
• Verify what was actually downloaded. Compare controller programs and configurations against the approved baseline after the change, and on a schedule for safety systems.
• Close the loop. A change is not finished until drawings, asset register, network diagrams, backups and access lists reflect it.

Why MOC is the right home for OT cyber change control

In regulated process industries MOC is a legal requirement, not a choice. In the United States, the OSHA Process Safety Management standard (29 CFR 1910.119(l)) requires employers to "establish and implement written procedures to manage changes" to process chemicals, technology, equipment and procedures, except for "replacements in kind", which the standard defines as a replacement that satisfies the design specification. Before any change, the procedure must address the technical basis, the impact on safety and health, modifications to operating procedures, the time period and the authorisation required. Affected operators, maintenance staff and contractors must be informed and trained before start-up, and process safety information and operating procedures must be updated. The EPA Risk Management Program rule (40 CFR 68.75) mirrors these requirements. In Great Britain, HSE guidance for COMAH sites expects formal procedures for modifications to plant, procedures, people and substances, with safety, engineering and technical review, risk assessment and formal authorisation by competent people.

Control systems are part of "technology" and "equipment" in these rules, so a controller logic change or a safety system bypass already falls within MOC. What is usually missing is the cyber question. NIST SP 800-82 Rev. 3, in its OT overlay for SP 800-53 control CM-3 Configuration Change Control, says OT change control should align with the organisation's management of change practices, and its guidance for CM-4 Impact Analyses says the organisation should consider safety and security interdependencies, with OT security and safety personnel both included in change management. That is the case for one process with two sets of eyes.

What counts as a change for cyber purposes

The first decision is scope. A MOC procedure written for pipework and vessels will not catch most control system changes unless the screening questions name them. Use a written list, and treat "replacement in kind" carefully: a replacement PLC with a different firmware version, or a switch with a different default configuration, may meet the mechanical design specification and still change the attack surface.

Two attacker techniques from MITRE ATT&CK for ICS show why logic changes need verification, not just approval: T0843 Program Download, where a modified program is loaded onto a controller, and T0873 Project File Infection, where an engineering project file is altered so that the next legitimate download carries the change. Both look like normal engineering activity. A MOC record that says what should be in the controller is the reference that makes the difference visible.

Designing the cyber screening questions

Keep screening short so engineers answer it honestly. A "yes" to any question routes the change to a named OT security reviewer; all "no" answers are recorded and the change proceeds on its normal route.

1. Logic or configuration: Does the change modify a program, configuration, firmware or set point stored in a controller, SIS, HMI or historian?
2. Connectivity: Does it add, remove or alter a network connection, firewall rule, wireless or cellular link, or data flow to IT or cloud?
3. Access: Does it create or change an account, remote access path, vendor connection or shared credential?
4. New device: Does it introduce any device with a processor, network port, USB port or wireless radio, including like-for-like replacements with a different firmware version?
5. Security controls: Does it disable, bypass or alter a security control (allowlisting, antivirus, logging, key switch position, network monitoring sensor)?
6. Consequence: Does it change the worst credible consequence of the process, which could change the target security level of the zone?
7. Temporary state: Will the plant run, even briefly, in a configuration different from the approved baseline (temporary laptop connection, bypass, test mode)?

The reviewer then checks a fixed set of items: zone and conduit impact against the site's IEC 62443-3-2 risk assessment, the integrity and source of any software or firmware, the backup and rollback plan, who will make the change and from which engineering workstation, whether new accounts follow least privilege, what monitoring will see the change, and which documents must be updated at close. Where the change alters consequence or safety functions, feed it into the next cyber process hazard review; see the OT Cyber Physical Risk and Safety Guide.

Implementing the change safely

Approval is half the control. The other half is making the change in a way that can be verified and reversed.

• Back up before you touch it: take and store a current backup of the controller program and configuration, and of the engineering project file, before work starts. A backup taken months ago may already differ from what is running. See the OT Backup, Recovery and Golden Image Guide.
• Use a controlled engineering workstation: make changes from a hardened, inventoried workstation rather than a contractor laptop, and record which one was used. See the Engineering Workstation Security Guide.
• Use physical and mode controls: NIST SP 800-82 Rev. 3 notes that physical key switches and controller mode switches (run versus program or remote) can restrict configuration changes. Return keys to run and record the position in the MOC close-out.
• Check software integrity: obtain firmware and engineering software from the supplier's authenticated channel, verify hashes or signatures where the supplier publishes them, and scan media before connecting it.
• Test where you can: a test bench, simulator or offline controller catches logic errors and compatibility issues; NIST SP 800-82 Rev. 3 advises testing patches under field conditions on a test system where possible before installing on the OT system. Where no test system exists, record that in the MOC and require a tighter rollback plan.
• Time limit temporary access: remote vendor sessions opened for the change should be approved for a window, monitored, and closed at the end. See the OT Remote Access Guide.
• Pre-start-up review includes cyber: OSHA PSM requires a pre-startup safety review for modified facilities when the modification is significant enough to change process safety information. Add cyber confirmations: keys returned, temporary connections removed, accounts disabled, monitoring sees the device, new baseline captured.

Temporary and emergency changes

Breakdowns at 3am are where cyber discipline fails. The answer is a defined fast path, not an exception from MOC.

Track open temporary changes on a register reviewed at the daily operations meeting. A temporary change that silently becomes permanent is a change that never had a full review.

Verifying that the running state matches the approved state

NIST SP 800-82 Rev. 3, discussing CM-3(7) Review System Changes, notes that safety instrumented systems may need scheduled reviews to confirm no inadvertent logic changes were made. Apply the same idea more widely.

• Post-change compare: after the download, compare the controller program and configuration with the approved version and attach the result to the MOC record.
• Scheduled compare: run periodic comparisons of running programs against the last approved baseline, most frequently for SIS and high-consequence controllers. Many control system platforms and OT monitoring tools offer program change detection or version compare; use what your estate supports and record the method.
• Network evidence: passive OT monitoring can flag program downloads, firmware updates, mode changes (T0858 Change Operating Mode) and new connections. Match each alert to an open MOC; an unmatched download is an incident until proven otherwise. See the OT Network Security Monitoring Guide.
• Configuration of security devices: firewall and switch configurations at zone boundaries should also be compared against approved versions after changes.

Where identity fits

Every OT change is made by an identity: an engineer's named account, a shared engineering login, a vendor account or a service account used by a historian or OPC server. MOC should record which identity made the change, from which workstation, and whether any account was created, elevated or left active. Shared engineering accounts make post-change verification much weaker because the log cannot show who downloaded what. Machine credentials matter too: a historian service account or a data diode configuration account that is added for a project and never removed becomes a standing path into the control zone. Close each MOC by confirming temporary accounts are disabled and credentials changed where a third party knew them. See the OT and ICS Identity and Access Guide.

Rolling out cyber MOC

1. Read the current procedure: map the site MOC workflow, forms, approvers and tooling. Identify where control system work enters it today and where it bypasses it (maintenance work orders, vendor service visits, "like for like").
2. Agree scope and definitions: write the change type list and a cyber definition of replacement in kind with process safety, controls engineering and maintenance.
3. Add screening questions and reviewer roles: seven questions or fewer; name primary and deputy OT security reviewers per site; set a review turnaround that matches MOC service levels.
4. Pilot on one site or unit: run for one quarter, including at least one planned outage, and collect engineer feedback on burden.
5. Add verification: introduce post-change program compare and the unmatched-download alert once baselines exist for the pilot controllers.
6. Extend and train: roll out site by site, aligned to turnarounds; train MOC approvers, maintenance planners and integrators. Put the requirements into integrator and service contracts; see the OT Third-Party and Integrator Access Guide.
7. Review and roll back if needed: if the cyber step is creating a backlog that pushes engineers to bypass MOC, narrow the screening triggers temporarily rather than suspend the review, and fix reviewer capacity.

Small versus large organisations: a single-site operator may have one controls engineer acting as both originator and cyber reviewer; in that case use a second competent person, possibly from the integrator under contract, for high-consequence changes. A multi-site group should set a common minimum (screening questions, verification, metrics) and allow sites to keep their own MOC tooling.

Detection and measurement

• Coverage: percentage of controller program downloads and firmware updates detected by monitoring that match an approved MOC record (target 100%).
• Screening quality: sample of MOCs answered "no cyber impact" that a reviewer later judges should have been "yes".
• Temporary change age: number of open temporary changes and bypasses past their expiry date.
• Close-out completeness: percentage of cyber-reviewed MOCs closed with baseline captured, drawings updated and temporary access removed.
• Review turnaround: median time from cyber referral to decision, so reviewer capacity is visible before it becomes a bypass reason.
• Drift findings: number of scheduled program compares that found an unapproved difference, and time to resolve each.

Framework mapping

For how the 62443 parts fit together see the IEC 62443 Guide, and for consequence-led design decisions that should then pass through MOC see the Consequence-driven OT Risk (CCE) Guide.

Common failure patterns

• "Like for like" waves changes through: a replacement controller or drive with newer firmware and new network services is treated as a replacement in kind and never screened.
• Logic changes as maintenance work orders: small set point or logic tweaks are raised as routine maintenance and bypass MOC entirely, so no baseline is updated.
• Approval without verification: the MOC is approved, but nobody compares what was downloaded with what was approved, so a wrong or tampered project file goes unnoticed.
• Temporary becomes permanent: vendor remote access, a test laptop or a bypass opened for a change stays in place for months.
• Close-out skipped: network diagrams, asset registers and backups are not updated, so the next incident responder works from a wrong picture.
• Cyber reviewer as bottleneck: one central reviewer for many sites creates delay, and engineers stop raising changes. Capacity is a control.

Practitioner checklist

• Map the current MOC workflow and every route by which control system work bypasses it.
• Write a change type list and a cyber definition of replacement in kind with process safety and controls engineering.
• Add seven or fewer cyber screening questions to the MOC form and name site reviewers and deputies.
• Require a fresh backup of controller programs and project files before every logic or firmware change.
• Specify approved engineering workstations and record which one was used for each change.
• Add cyber confirmations to pre-start-up review: keys returned, temporary access removed, accounts disabled, baseline captured.
• Run post-change and scheduled program compares, most often for SIS and high-consequence controllers.
• Alert on program downloads or mode changes that do not match an open MOC.
• Keep a register of temporary changes and bypasses with expiry dates reviewed daily.
• Report coverage, close-out completeness and drift findings to site leadership each quarter.

Standards and references

• OSHA: 29 CFR 1910.119 Process Safety Management of Highly Hazardous Chemicals
• eCFR: 40 CFR 68.75 Management of change
• NIST: SP 800-82 Rev. 3 Guide to Operational Technology (OT) Security
• ISA: ISA/IEC 62443 Series of Standards
• HSE: Plant modification and change procedures (COMAH technical measures)
• Idaho National Laboratory: Cyber-Informed Engineering
• MITRE ATT&CK for ICS: Program Download
• MITRE ATT&CK for ICS: Project File Infection

Related NHI Mgmt Group resources: OT Patch Management Guide · Consequence-driven OT Risk (CCE) Guide · Chemical Sector Cybersecurity Guide · Safety Instrumented Systems Security Guide · OT Security Guide