OT Disaster Recovery (DR): Having Backups Does Not Mean You Can Recover

In OT environments, “Disaster Recovery” often starts with a comforting sentence: “We have backups.” But DR is not the existence of a backup file. DR is the ability to restore the process—correctly, safely, and quickly—under pressure. The real DR question is: How fast can you return to stable operations, in what order, with what validations?

A frightening scenario: ransomware begins in IT, pivots through the DMZ, and reaches OT. HMIs won’t boot, the historian database is encrypted, engineering workstation project files are locked. PLCs may still be running, but operators can’t safely see or control the process. Production stops. The IT team says, “We’ll restore from backups.” Then OT reality hits: Which HMI image? Which driver versions? Which SCADA runtime dependencies? Which license dongles or certificates? Which PLC project is the last validated version? Which IP plan and VLAN rules? If those answers aren’t documented and tested, recovery becomes days, not hours.

A strong OT DR capability is built from three parts: backup discipline, architectural resilience, and scenario runbooks.

1) Golden images and configuration management

• Known-good images for HMI/SCADA servers with exact versions (OS, runtimes, drivers, patches).

• Engineering workstation toolchains and project repositories with version control or controlled baselines.

• PLC/RTU program backups, plus change tracking: who changed what, when, and why.

2) Criticality and restoration order

In OT, you don’t “restore everything.” You restore in a sequence that protects safety and continuity. A typical order:

1. Core network controls (switch/firewall configs, VLANs, routing)

2. Access control (VPN/jump hosts, MFA, session logging)

3. Control logic (PLC/RTU baseline function)

4. Operator visibility (HMI)

5. Supervisory control (SCADA)

6. Historian and reporting

7. Integrations (MES/ERP)

3) Realistic RTO/RPO

• RTO: how fast you need services restored.

• RPO: how much loss you can tolerate.

  In OT, RPO is not just “data.” It’s configuration drift. If the PLC logic and the operational state diverge, “restored” can still be “wrong,” which is worse than down.

4) Offline and tamper-resistant backups

Modern ransomware targets online backup storage and shared drives. OT backups should include:

• Immutable storage / WORM options

• Offline copies

• Separate identities and access control

• Regular restore tests (not just “backup succeeded” logs)

5) DR drills

A DR plan that isn’t drilled is a wish. At minimum:

• Rebuild an HMI server from a golden image

• Restore a PLC project and validate checksums/versions

• Confirm SCADA licensing and driver compatibility

• Validate segmentation rules and firewall policies after recovery

DR also has a security dimension: during a crisis, teams often create “quick bypasses” (disabling firewalls, opening wide RDP, sharing admin passwords). Those shortcuts often enable the second wave of compromise. Good DR is not only about restoring—it’s about restoring without re-infecting.

The business case is straightforward: without DR readiness, decision-making becomes panic-driven. OT downtime costs can be catastrophic: lost production, quality issues, safety risk, and reputational damage. DR in OT is not a “nice to have.” It is an engineering requirement for operational continuity.