The short answer
Change Management for OT
Change management for a control system is a short, consistent process: a request that says what will change, why, what could go wrong, and how it will be undone; approval by the person who owns the system, with the risk weighed; a scheduled window with operations told in advance; a backup of what is about to change; the change itself, verified by a test that proves the system still does what the functional description says; and the update of the baseline, the drawings, and the documentation as the closing step. Changes are classed as standard, normal, or major so that a routine setpoint limit change is not treated like a controller replacement, and an emergency path lets an urgent fix be made first and recorded within a day. Every change, including those made by vendors and integrators, leaves a record with a number, and the record is what a program change detection or an audit is matched against.
Key points
- A change is anything that alters how the system is configured: logic, limits, firmware, network, accounts, firewall rules. Operating setpoints within limits are operations.
- Request, approve, schedule, back up, change, verify, update the baseline and documents, close: eight steps, every time.
- Three classes keep it proportionate: standard changes pre-approved, normal changes approved, major changes planned.
- Emergency changes are made first and recorded within a day, then reviewed.
- Vendors and integrators work under the same process; their session is a change record.
- The record is what makes detection meaningful: a difference that matches a record is a change, one that does not is an incident.
What is a change
| Change | Not a change |
|---|---|
| Editing controller logic, adding or removing I/O, changing a scaling or an alarm limit in the controller | An operator changing a setpoint within its configured limits |
| Editing SCADA tags, displays, alarms, scripts, or security configuration | Acknowledging or shelving an alarm |
| Updating firmware on a controller, drive, instrument, radio, switch, or firewall | Restarting a client |
| Changing a firewall rule, a VLAN, an IP address, or a radio setting | Replacing a failed module with an identical spare, configured from the baseline, and recording it |
| Creating, changing, or removing a user account or role | Changing a password |
| Installing, updating, or removing software on a control system machine | Antivirus definition updates through the approved path |
| Replacing a device with a different model or version | Calibrating an instrument, recorded in the calibration record |
| Changing a controller mode for editing, or connecting programming software | Viewing online without editing, on platforms that log it |
The steps
- 1
Request
A record with a number: what will change, on which assets, why, the risk to the process and to security, how it will be tested, and how it will be undone. Written by whoever wants the change, in a form that takes minutes for a small one.
- 2
Approve
The control system owner, or a delegate for standard changes, reads the request and approves, rejects, or asks for more. Major changes get a review meeting with operations.
- 3
Schedule
A window that operations agrees to, with the process in a suitable state and someone available to watch it. Operations is notified before the window, and the notification names the assets and the expected effects.
- 4
Back up
The current configuration of what is about to change: the controller program, the project export, the device configuration. Noted in the record.
- 5
Change
By the named person, in the window, doing what the request says and nothing else. A change that grows during execution stops and goes back for approval.
- 6
Verify
The test named in the request: the loop check, the alarm test, the sequence run, the failover. Operations confirms the system behaves. The record says pass or fail.
- 7
Update
The baseline in the repository, the expected signature in the SCADA, the drawings, the functional description, the IP schedule, the inventory. This step is mandatory and is checked before the record can close.
- 8
Close
The record closed with the date, the result, and any follow-up. Failures are rolled back per the plan and recorded as such.
Classes
| Class | Examples | Approval | Notice |
|---|---|---|---|
| Standard | A pre-approved, repeatable change with a known procedure: an alarm limit change within a documented range, a like-for-like module replacement, a display text correction | Pre-approved; the record is filed and the owner reviews the list monthly | Operations informed |
| Normal | A logic edit, a new tag and display element, a firmware update on one device, a firewall rule change | The owner approves each one | Operations agrees the window |
| Major | A controller replacement, a SCADA version upgrade, a network redesign, a new remote site | The owner and operations management approve a plan with a test and a rollback | Planned weeks ahead; operators briefed |
| Emergency | A fix to restore the process or to contain an incident that cannot wait for approval | Made by the on-call engineer with the operator; the owner told at once; recorded within 24 hours and reviewed | Operations is present by definition |
Vendors and integrators
An integrator support session is a change until proven otherwise. The session is a change record: what they will look at, what they may change, the window, the remote access enabled for it and disabled after, the person on the utility side who watches, and the export and baseline update afterward. An integrator who makes a change outside a record has made an unauthorized change, however helpful, and the utility says so. Integrators that work under many utilities know this process and prefer it, because it protects them too.
The record
- Number, date, requester, class.
- Assets affected, with their baseline versions before and after.
- Description, reason, risk assessment, test plan, rollback plan.
- Approval: who and when.
- Window, operations notification, the person who executed.
- Backup taken, verification result, baseline and documentation updated.
- Closure, and any follow-up items.
Frequently asked questions
- We are three people. Do we need this?
- A three-person utility needs a one-page form and a folder, and the same eight steps done in ten minutes for a small change. The point is the record and the backup-verify-update habit, not the bureaucracy. The utilities that suffered most from unrecorded changes were small ones where everyone assumed everyone else knew.
- Who is the system owner?
- The person accountable for the control system working: usually the operations manager or the lead control engineer, formally named. The owner approves changes because the owner answers for the consequences. It is not the integrator and not the IT department.
- What about a change made during an emergency at 3 a.m.?
- Made, with the operator, to restore the process safely. Then the owner is told at once and the record is written within a day, with the backup that was or was not taken, the verification, and the baseline update. The review afterward asks whether it was really an emergency and what would have prevented it.
- How does this connect to the security program?
- Change management is how the security controls stay in place: the firewall rules, the hardening, the accounts, and the baselines all decay without it. It is also what makes change detection useful, because a detected change can be matched to a record. Most security frameworks list it as a foundational control for that reason.
Related topics
- Configuration BaselinesA known-good record of how every part of the control system is configured, captured at acceptance and kept current through change management: what to baseline, how to capture and store it, how to compare on a schedule, and what an unexplained difference means.
- Program Change DetectionKnowing when a controller program changed and whether it was supposed to: change counters and signatures the SCADA can alarm on, scheduled compares, audit logs, mode and network monitoring, what each catches, and what to do when one fires.
- Patch ManagementApplying updates to SCADA servers and clients without breaking the plant: vendor qualification, a monthly cycle with a test system, priority from the exposed edge inward, backups and rollback, emergency patches, and handling software that cannot be patched.
- Vendor Remote AccessIntegrators and equipment vendors need to get in. How to let them without leaving a permanent door open: utility-controlled sessions, named accounts, MFA, a jump host, session recording, and what to do about the modem you did not know was there.
- Security Program BasicsWhat a control system security program is for a utility that has never had one: a named owner, an inventory, a risk assessment, a few policies, baseline controls, training, vendor rules, an exercised incident plan, and a first-year plan for a small staff.
- Commissioning ChecklistFrom energization to handover: the sequence of commissioning activities for a control system, the prerequisites and records for each, who signs what, and the checklist that keeps a project from being declared finished while half of it has never been tested.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.