What makes OT change different from IT change
IT change management is mature. ITIL ships a template, every ITSM tool implements the workflow, and most engineering organisations can run a CAB in their sleep. The trouble starts when teams try to drop that same template on top of a plant floor.
Three things are different. First, the change target is physical: a bad PLC deploy doesn't degrade a service, it stops a line or breaks a product. Second, the artefact is not source code in a Git repository, it's a vendor-specific project file that lives on a laptop in a cabinet. Third, the approval cadence is tied to the production schedule — most major OT changes wait for a planned shutdown, and an emergency change has to be deployable in minutes.
The framework below assumes those constraints and is the basis for the OT change management software we build at VEM.
The six-step process
Every OT change, regardless of size, moves through the same six steps. Tiering decides the depth of each step, not whether the step happens.
| # | Step | What happens |
|---|---|---|
| 1 | Capture the request | Engineer files a change with scope, justification, target controller and the proposed diff or work instruction. |
| 2 | CAB or single-approver review | Risk-tiered: major changes go to the CAB; standard changes follow a pre-approved template with a single approver. |
| 3 | Stage and validate | Approved change is deployed to a staging or simulated controller; validation steps are recorded against the test plan. |
| 4 | Deploy with signed capture | Production deployment captures the running controller's signature before and after the change, tied to the approver. |
| 5 | Audit and link | Immutable record links request, approval, diff and deployment into a single evidence pack. |
| 6 | Archive against the baseline | Approved post-change state becomes the new baseline; drift detection runs against it from the next backup. |
A RACI that survives contact with the plant
The single biggest reason OT change processes fail in practice is ambiguous ownership. A controls engineer thinks the OT security team approves; the OT security team thinks plant engineering approves; the auditor finds neither did. The matrix below is the minimum.
| Activity | Controls eng. | Plant eng. mgr | OT security | Quality / compliance |
|---|---|---|---|---|
| File the request | R | A | C | I |
| Risk assessment | R | A | C | C |
| CAB approval (major) | C | R | A | A |
| Single approver (standard) | C | R/A | I | I |
| Stage & validate | R | A | C | C |
| Production deploy | R | A | I | I |
| Evidence-pack sign-off | C | R | C | A |
R = Responsible, A = Accountable, C = Consulted, I = Informed.
Worked example: a 24-line packaging plant
Picture a packaging plant in the US Midwest. 24 lines, three PLC vendors on the floor — Allen-Bradley CompactLogix on the older lines, Siemens S7-1500 on the newer lines, a handful of Beckhoff TwinCAT 3 systems on a recent labeler retrofit. Two shifts, six days a week.
The plant runs roughly 30 OT changes a month across the fleet. Old posture: a shared spreadsheet, an email thread per change, and an engineer pulling PLC backup software snapshots after each deploy. The audit team found that 4 in 30 changes had no documented approver and 11 in 30 had no post-deployment verification on file. The quarterly CAPA backlog had grown to 60 hours.
New posture, using VEM as the system of record for OT change:
- Tier-1 lines (3 lines, $530+/hr lost margin): full CAB, 48-hour notice, mandatory staging deploy.
- Tier-2 lines (14 lines): single-approver workflow, 24-hour notice, mandatory diff review.
- Tier-3 lines (7 lines): single-approver workflow, same-shift deploy permitted.
Decision points named in the runbook: which tier the line sits in (set quarterly by plant engineering), whether the change touches safety configuration (auto-escalates to CAB regardless of tier), whether the change is an emergency fix (fast-path with retrospective CAB at the next cycle).
Six months in: 100% of changes had a documented approver, 100% had a before/after signature on file, average lead time on standard changes dropped from 3.4 days to 0.9 days because the approver no longer had to chase context. The quarterly CAPA backlog for change-documentation gaps went to zero. The 11-hour outage caused by an undocumented setpoint change in March did not repeat.
Compliance crosswalk: one change, three audits
Plants running under multiple regimes don't want to run three parallel change processes. The same captured artefacts can satisfy IEC 62443, NERC CIP and GxP simultaneously, if they're collected consistently.
| Requirement | IEC 62443 | NERC CIP | GxP / 21 CFR 11 | VEM capability |
|---|---|---|---|---|
| Documented change procedure | SR 7.6 (2-4) | CIP-010 R1 | Annex 11 §10 | Approval workflow |
| Configuration baseline | SR 7.6 | CIP-010 R1.1 | Validated state record | Signed version history |
| Drift detection | SR 7.6 verification | CIP-010 R2 | Periodic review | Continuous diff vs baseline |
| Attributed approval | SR 7.6 evidence | CIP-010 R1.4 | Part 11 §11.50 e-sig | Authenticated approver record |
| Tamper-evident audit log | SR 2.8, 2.9 | CIP-007 R4 | Part 11 §11.10(e) | Hash-chained immutable log |
Common failure modes (and how to avoid them)
Four patterns surface in almost every plant where OT change management is struggling. Naming them is half the fix.
- The shadow change. A technician tweaks a setpoint during a troubleshoot and never logs it. Fix: continuous drift detection against the approved baseline — the change surfaces the same shift even if nobody filed a ticket.
- The unsigned approver. An email thread says "approved" but the approver's identity isn't bound to the artefact. Fix: cryptographic signature on the captured controller state, tied to an authenticated approver.
- The ITSM-only ticket. The ticket has a description but not the diff. Auditors can't tell what was actually deployed. Fix: capture the actual change artefact, not just the description.
- The PPAP drift. Customer-approved baseline says one thing, the running controller says another, and nobody can reconstruct how they diverged. Fix: link every approved change to the customer baseline so divergence is impossible without a documented re-PPAP.
Where change management ends and PLC backup begins
The two layers share the same version history and should never be treated as separate systems of record. Change management answers who decided what, and on what basis. PLC backup answers what state the controller is in, and how does it compare to the last in-control baseline. Together, they're the proof that the running plant matches the plant the auditor approved.
For the capture-and-restore layer specifically, see our PLC backup software page. For the approval-and-audit layer, see the OT change management software overview.