When an industrial controller fails, or a ransomware attack takes out an engineering workstation, recovery depends on one thing: do you have the program, the configuration and the software needed to rebuild? In many small plants and field operations, the honest answer is that the only copy lives on a laptop that an integrator last touched years ago.
OT backups are not the same as office backups. They involve different data, different tools and different consequences when they fail.
What counts as an OT backup
Controller programs and configuration
Logic for programmable logic controllers, remote terminal units and similar devices, along with their configuration settings, tags, network addresses and security settings.
HMI and SCADA projects
Operator screens, alarm configurations, historian settings, trend definitions and database content.
Engineering workstation images
Programming software often requires specific versions, licenses and drivers. A full system image of the workstation can save days of rebuilding.
Network device configurations
Switches, firewalls, routers and wireless devices need their configurations saved so they can be replaced and restored quickly.
Documentation and credentials
Drawings, IP address lists, firmware versions, vendor contacts, license keys and passwords or keys needed for recovery, stored securely and separately.
Why OT backups often fail
- No one owns them. The integrator or a retired engineer made a copy once.
- Backups are old. Programs change, but the backup does not.
- Software is missing. Having the program is not enough if you cannot open it.
- Copies live on the same system. A single failure or attack removes both.
- Nobody has tested a restore. Hardware differences, firmware versions and licenses can block recovery.
Build a practical OT backup process
Step 1: Inventory what you have
List each controller, HMI, server and network device that matters to operations. Note model, firmware version, location, vendor and who has the program. Rank them by importance to production and safety.
Step 2: Capture current versions
Back up each critical device, using tools recommended by the manufacturer. Record the date and the firmware and software versions that go with each backup. Where possible, compare the running program with the stored copy and confirm they match.
Step 3: Store copies safely
- Keep a copy in a secure location on the OT side with limited access.
- Keep another copy offline or in an isolated location, protected from ransomware.
- Encrypt backups that contain sensitive configuration or credentials.
- Include backups in your regular IT backup program only if you can do so without opening risky paths between networks.
Step 4: Preserve the tools
Store installers, license files, drivers and documentation for programming software. Keep a known-good workstation image or virtual machine configured for each platform you maintain.
Step 5: Back up after every change
Treat changes to logic or configuration like a change to a safety-critical process. Require a backup before and after, along with a note explaining what changed and who approved it. This habit makes it easier to spot unauthorized modifications as well.
Step 6: Test restores
Restore to spare hardware or a test setup, when practical, and confirm that the device runs correctly. At minimum, verify that you can open the backup in the right software and that nothing is missing. Do not test on production equipment unless operations staff approve and a safe window exists.
Involve vendors and integrators
Many operators rely on outside integrators. Ask:
- Do you keep copies of our programs, and where?
- How do you protect them?
- Will you provide current copies on request, and how often?
- What is your process for returning or deleting our data if we part ways?
Put these expectations in your service agreements so you are not dependent on one person's memory or goodwill.
Keep spares and plan for hardware
A backup helps only if you have hardware to restore onto. Consider keeping spares for critical controllers, or know the lead time to get replacements. Record firmware levels so a spare can be brought to the right version.
Protect the backup system itself
- Restrict who can read, change or delete backups
- Log access and changes
- Keep credentials for the backup system separate from general IT accounts
- Review the backup list quarterly for gaps
A hypothetical example
Consider a hypothetical water treatment contractor whose only copy of a controller program lives on an integrator's laptop. When the controller fails and the integrator is unreachable, the plant spends days reconstructing logic from memory and paper drawings. A current, tested backup stored locally would have turned a multi-day outage into a few hours of work.
Getting organized
Ironfield Cyber helps operators and energy service companies inventory OT assets, set up backup routines and test recovery in ways that respect operational constraints. If your controller programs live on one laptop or in one person's head, we can help you fix that.