In an industrial environment, a small change can have outsized consequences. A new firmware version, an edited ladder logic block or a modified network setting can stop production or create a safety hazard. The same applies to malicious changes: if nobody tracks what changed, nobody notices when an attacker alters a controller.
Change management is the discipline of deciding, recording and testing changes before and after they happen. For small operators it does not have to be heavy. A simple, consistent process catches most problems.
Why It Matters for Security
- Reliability. Many outages trace to well-intentioned changes made without a plan.
- Detection. If every legitimate change is logged, an unlogged change stands out.
- Recovery. Knowing the previous configuration lets you roll back quickly.
- Compliance. Regulated operators and customers often expect documented change control.
What Counts as a Change
Define it broadly. Include:
- Controller programs and logic.
- Firmware and software updates on PLCs, HMIs, historians and engineering workstations.
- Network changes, such as new devices, firewall rules and remote access paths.
- User accounts and permissions.
- Setpoints, alarm limits and safety-related parameters.
- Replacement of failed hardware.
A Lightweight Process
1. Request
Anyone proposing a change submits a short description: what, why, which systems, when and who will perform it. A shared form or ticket is enough.
2. Assess
An operations or engineering lead reviews the request. Questions to ask:
- What could go wrong, including impact on safety and production?
- Does the change affect the network or remote access?
- Is the vendor involved, and do they need supervision?
- Is a maintenance window needed?
- How will we know it worked, and how do we undo it?
3. Back up first
Before touching any controller, save the current program and configuration. Store the backup securely, with a label for the date and version. Keep multiple versions. This is the step that makes rollback possible.
4. Approve
Someone with authority signs off. For higher-risk changes, require a second person. Record the approval.
5. Test where possible
If you have a test bench or simulator, try the change there first. If not, plan carefully, work in a maintenance window and have operators standing by.
6. Implement and observe
Perform the change as planned, with the right people present. Monitor the process afterward for unexpected behavior.
7. Document and close
Record what was actually done, any deviations and the results. Update network diagrams, asset inventories and documentation. Store the new configuration backup.
Managing Vendors and Integrators
Outside technicians often make changes. Treat them like anyone else.
- Require them to follow your change process.
- Escort or supervise remote sessions.
- Require that they leave copies of programs and configurations.
- Review what they changed, especially any new accounts or remote access they added.
- Revoke temporary access when the work is complete.
Detecting Unauthorized Changes
Compare controllers to known-good backups on a regular schedule. Some industrial platforms and tools can detect program changes automatically. Even a manual quarterly comparison for critical controllers can reveal surprises. Investigate any difference that does not match a change record.
Also watch for:
- New or unexplained user accounts on engineering stations.
- Changes to firewall rules or new remote connections.
- Devices appearing on the network that are not in your inventory.
Emergency Changes
Emergencies happen, and a process that cannot handle them will be ignored. Define an expedited path: a verbal approval from a named person, a minimum record made at the time, and a review afterward to document and learn. Emergency should not mean unrecorded.
Keep It Proportionate
A change to a non-critical office printer does not need the same rigor as a modification to a safety system. Classify changes by risk and scale the process: low-risk changes need a log entry, moderate ones need approval and a backup, high-risk ones need testing and a rollback plan.
Common Pitfalls
- Backups taken but never verified or stored only on the engineering laptop.
- Changes made by vendors with no records left behind.
- Documentation updated months later, if at all.
- A process so heavy that people work around it.
Getting Started
Begin with the controllers that matter most. Create a simple log, make a backup, and require approval for changes to those systems. Ironfield Cyber helps small energy and industrial operators design practical change control that fits their staffing, and can help you review vendor access at the same time.