Many industrial incidents, whether caused by an attacker or by an honest mistake, begin with a change nobody tracked. A technician updates firmware without telling operations, a vendor adds a remote connection for convenience or an engineer modifies logic during a late-night troubleshooting session. Later, when something misbehaves, nobody can say what changed or when.
Change management sounds bureaucratic, but a lightweight version protects safety, uptime and security at once. It does not need special software. It needs a short form, a second pair of eyes and a habit of recording what happened.
Why change control is a security control
Frameworks such as ISA/IEC 62443 and NERC CIP, and general CISA guidance on industrial systems, all emphasize managing configuration and change. The reasoning is straightforward.
- Unauthorized or unreviewed changes are how attackers alter systems without being noticed.
- Mistakes are indistinguishable from malice until you can compare against a known state.
- Recovery depends on knowing the last good configuration.
- Safety depends on knowing exactly what logic is running.
What counts as a change
Define it broadly. Include:
- Changes to controller or safety logic, set points and alarm limits
- Firmware and software updates
- New devices connected to control networks
- Firewall rule changes and network modifications
- New or changed remote access methods
- New user accounts, role changes and password policy changes
- Changes to backup, monitoring and logging settings
Decide which categories need full review and which are routine, such as pre-approved maintenance tasks documented in procedures.
A lightweight process
1. Request
Someone proposes the change using a one-page form with:
- What will change and why
- Systems affected
- Who will perform the work, including vendors
- Planned date and duration
- Safety and operational impact
- Rollback plan
2. Review
A second qualified person, plus operations, reviews the request. For safety systems, include the person responsible for process safety. Ask what could go wrong and how it would be noticed.
3. Approve and schedule
Approval comes from a named role, not whoever is available. Schedule work during a window that operations accepts, and make sure the right people are present.
4. Prepare
Before the change, take a backup of the affected configuration or program, and store it in a protected location. Confirm the rollback steps. Verify that the replacement hardware or software is from a trusted source.
5. Implement
Perform the work as written. If something unexpected occurs, stop, document it and decide with operations whether to continue or roll back. No improvising on safety functions.
6. Verify
Test that the system works as intended. Compare the new configuration or program with the planned one. Confirm that temporary accounts, bypasses and test connections were removed.
7. Record
Update the change log, asset register and network diagrams. Store the new backup as the current known-good copy. Note lessons learned.
Emergency changes
Real emergencies happen. Allow an expedited path, with verbal approval from a defined authority, but require the paperwork afterward within a fixed time, such as the next business day. Review emergency changes monthly to make sure the exception is not becoming the rule.
Manage vendor changes the same way
Vendors should follow your process, not theirs. Require advance notice, a described scope and a report of what they did. Do not allow vendors to leave remote access paths open after a visit. Compare controller programs after vendor work against your known-good copies.
Use baselines to detect drift
Keep a baseline of each controller program, network device configuration and key setting. Periodically compare current state to baseline, and investigate differences that do not match the change log. Even a simple scheduled comparison can reveal unauthorized changes.
Keep it proportional
A small operator does not need a committee. A foreman, an engineer and an operations lead reviewing a one-page form on a shared drive is a perfectly good start. The test is whether you can answer, for any system, what changed in the last month and who approved it.
Common pitfalls
- Treating firmware updates as routine and skipping review.
- Letting temporary fixes become permanent without documentation.
- Backups taken after the change rather than before.
- Forms that are so long nobody completes them.
- No one enforcing the process when production pressure rises.
Where to begin
- Write a one-page change request form.
- Name the approver roles.
- Start a change log, even a shared spreadsheet.
- Capture known-good backups of controller programs.
- Add the process to vendor contracts.
Support from Ironfield Cyber
Ironfield Cyber helps operators build change processes that fit their staff and outage windows, and align them with frameworks that apply to their work. If you would like a template form and a review of your current practice, we can start with a conversation with your controls team.