Backups and recovery in OT: the problem is not copying, it is getting back
Industrial cybersecurity spends a lot of time on prevention. Segmentation, remote access, hardening, detection. All of that matters. But bad days still happen, and when they do, the real question is not whether you have backups. It is whether you can get operations back without making up the plan under pressure.
In IT, recovery often means restoring servers, rejoining systems to the domain, and bringing business services back online. In OT, recovery is usually more fragile than that. You may need to rebuild engineering workstations, HMIs, historians, SCADA servers, process recipes, industrial network configurations, PLC backups, and sometimes legacy systems that still depend on software nobody can easily reinstall. If one critical piece is missing, the plant may stay down even if the rest of the environment is technically restored.
Why many backups fail when the incident actually arrives
This is where a lot of teams fool themselves. A nightly backup job exists, so the problem feels solved. It usually is not. In many plants, backups cover files and virtual machines but miss the elements that decide whether recovery will work at all: exact engineering software versions, communication drivers, licenses, validated PLC projects, industrial switch configurations, firewall rules, historian dependencies, or service credentials that were never documented properly.
It is also common to find backups tied too closely to the corporate environment, with the same identity infrastructure and the same storage an attacker may already be able to reach. Once ransomware hits the domain and the storage layer, the backup stops being a safety net and becomes another casualty. Norsk Hydro made that painfully clear, even for an organization with serious technical depth.
What you actually need to be able to restore
A useful OT backup strategy starts by accepting that not all assets matter equally. Some failures are annoying. Others stop production, affect quality, or leave operations blind.
At a minimum, you should be able to restore the following:
- ▹Full images of engineering workstations and HMI servers, including operating system version, vendor software, drivers, and documented licenses.
- ▹Backups of logic, projects, and configurations for PLCs, RTUs, DCS, and SIS, with version control and verification that they match what is deployed in the field.
- ▹Industrial network configuration, including firewalls, switches, jump servers, VPN access, and access control lists.
- ▹Historians, alarms, recipes, trends, and operational data whose loss would affect quality, traceability, or compliance.
- ▹Clear rebuild procedures, not just folders full of exported files.
That fifth point is usually the one that breaks first. Storing data is not the same thing as knowing how to recover.
IEC 62443, NIS2, and the uncomfortable side of resilience
IEC 62443 has been pushing toward a more serious lifecycle view for years. It is not enough to protect an asset while it is running. You also need to make sure it can be maintained, recovered, and returned to a trusted state. NIS2 adds pressure from the regulatory side. "We have backups" is not a serious answer anymore. You need to show risk management, continuity planning, and real response capability.
That forces teams into details that are not glamorous at all: realistic recovery times, dependencies between assets, change control, offline repositories, restoration testing, and clear separation between IT and OT backups where the risk justifies it. It is less flashy than a new dashboard. It is far more useful when the plant is down.
The test almost nobody runs and should run now
There is a simple way to find out whether the plan is real. Pick one critical engineering workstation or HMI server. Assume it is unusable tomorrow because of ransomware or disk corruption. How long would it take to rebuild it? Where does the image come from? Who has the license? Which exact project version needs to be loaded? How do you verify it matches the approved one? Who signs off before it goes back into production?
If the answers live in the heads of two people, you do not have resilience. You have luck.
A decent OT backup and recovery strategy does not promise miracles. It promises something much more useful: when things go wrong, the team does not have to improvise while the plant waits.
Want to check whether your OT backups would actually work in a real recovery? Contact us and we will review it with technical criteria.