OT Disaster Recovery: Restoring Industrial Operations After an Incident

01Key takeaways

1. 01

   OT disaster recovery restores the physical process to a safe, controllable state, not just the servers and databases behind it.

2. 02

   Recovery objectives in OT must include safety and process integrity, not only recovery time and recovery point in hours and minutes.

3. 03

   Tested, isolated, offline or one-way-protected backups are the difference between a recovery and a rebuild from memory.

4. 04

   Recovery sequence matters: safety systems, controllers and engineering tooling come back in a defined order, often before enterprise IT is fully restored.

5. 05

   A data diode does not recover anything by itself, but it can keep golden backups and recovery images out of reach of the same attack path that took down production.

02What is OT disaster recovery?

OT disaster recovery is the capability to restore operational technology and the physical process it controls after a disruptive event. It covers the engineering workstations, controllers, HMIs, historians, network gear and configuration data needed to run a plant, plus the documented procedure for bringing the process back safely.

It sits next to, but is distinct from, OT incident response. Incident response is about detecting, containing and eradicating a threat. Disaster recovery is about getting operations back. The two overlap during a real event, and the recovery plan should assume the environment may still be partly compromised when restoration begins.

Short version: OT incident response stops the bleeding; OT disaster recovery rebuilds the patient and gets the process running safely again.

03Why OT recovery is different from IT recovery

In enterprise IT, the worst case is usually lost data and downtime measured against a service-level agreement. In OT, the worst case can be a physical safety event, environmental release, equipment damage or a regional outage of a critical service. Recovery decisions carry consequences that a rollback in a data center never does.

The constraints are different too. Many controllers cannot simply be reimaged on demand. Some run for a decade without a reboot. Vendor support may be required to touch safety-instrumented systems. Restoring controller logic out of sequence can energize equipment that should stay isolated. So OT recovery is governed first by the process and its safety case, and only then by classic IT recovery mechanics.

IT recovery priority

Confidentiality and data integrity first, then availability, measured against business service levels.

OT recovery priority

Safety and availability of the physical process first, with data integrity supporting a safe, controllable restart.

04Recovery objectives: RTO, RPO and the safety dimension

Every recovery plan rests on two numbers. The recovery time objective (RTO) is how long the process can be down before the impact is unacceptable. The recovery point objective (RPO) is how much configuration or historian data you can afford to lose, expressed as a point in time before the incident.

In OT these numbers need a third dimension that IT rarely tracks formally: the safe state. Before any restart, the plan must define what a safe, known process state looks like and how to confirm the system is actually in it. A fast RTO that skips this verification is not recovery; it is a gamble with physical equipment.

• Set RTO and RPO per system, not as one number for the whole site. A safety controller and a reporting historian do not share priorities.
• Record the safe-state definition for each process area alongside its RTO and RPO.
• Account for vendor lead time and spare-parts availability, which often dominate real-world RTO.
• Validate that backup frequency actually meets the RPO. A nightly backup cannot deliver a one-hour RPO.
• Document who is authorized to declare a disaster and who authorizes a restart.

05Backups that survive the incident

A recovery plan is only as good as the backups it depends on. The recurring failure in real ransomware incidents is that backups were reachable from the same network as production, encrypted along with everything else, or never tested. A backup you cannot restore from is not a backup; it is a false sense of security.

The widely cited 3-2-1 rule remains a sound baseline: three copies of the data, on two different media, with one copy kept offsite. For OT, harden it further with at least one copy that is offline or write-once, and isolate the backup repository so that compromise of the production network does not automatically reach the recovery copies.

• Back up controller logic, HMI projects, network device configs, historian data and engineering-workstation images, not just servers.
• Keep at least one immutable or air-gapped copy that cannot be altered by a compromised production account.
• Store the golden images and configuration baselines separately from the live engineering network.
• Encrypt and access-control the backup repository, and monitor it as a high-value target in its own right.
• Record exact firmware and software versions so a restore matches what was actually running.

06Sequencing the recovery: order is a safety control

Restoration order is not an IT housekeeping detail in OT; it is part of the safety case. Bringing systems back in the wrong order can command actuators before interlocks are live, or restore controller logic before the network that supervises it. The plan should define a deliberate sequence and the verification gate between each step.

A common pattern is to recover the foundation first: clean, trusted infrastructure and the engineering tooling needed to rebuild. Then restore safety and protection systems, confirm they are healthy, and only then bring process controllers and HMIs back online toward a defined safe state. Enterprise connectivity and data flows to IT are often restored last, deliberately, to avoid reintroducing the attack path.

Foundation

Trusted network, domain or authentication services, and a clean engineering workstation to drive the rest of the recovery.

Protection layer

Safety-instrumented systems and protective relays restored and verified before process control is energized.

Process layer

Controllers, HMIs and historians brought to a defined safe state, with operators confirming readings before handover.

Connectivity layer

External and IT-facing data flows reconnected last, ideally one-way first, to avoid reopening the path the attacker used.

07The ransomware case: assume the network is dirty

Most modern OT disasters with a cyber cause are ransomware that started in IT and either crossed into OT or forced a precautionary shutdown. The lesson from publicly documented incidents is consistent: organizations often halt operations not because the OT was encrypted, but because they lost confidence in the boundary between IT and OT.

That changes how you recover. You cannot trust the existing network to be clean. Restoring from backups onto a still-compromised environment can simply re-encrypt the recovery. The recovery plan should include a known-good rebuild path: trusted media, verified images, credential resets, and a staged reconnection that proves each segment is clean before the next is joined.

Plan for the bad day, not the brochure day. Assume backups are a target, credentials are compromised, and the IT-to-OT link is how the adversary will try to return. Design the recovery so none of those assumptions causes a second outage.

08Standards and compliance mapping

OT disaster recovery maps cleanly onto established frameworks, and using them helps justify investment and satisfy auditors. NIST SP 800-82 Rev. 3 addresses contingency planning and recovery for OT, and points to NIST SP 800-34 for contingency-planning detail. The NIST Cybersecurity Framework 2.0 places this work under the Recover function, alongside Respond.

On the IACS side, ISA/IEC 62443-3-3 includes requirements that bear directly on recovery, including foundational requirement FR 7, Resource Availability, with system requirements such as SR 7.3 for control system backup and SR 7.4 for control system recovery and reconstitution. Sector regimes layer on top: for the North American bulk electric system, NERC CIP-009 mandates recovery plans for BES Cyber Systems.

• NIST SP 800-82 Rev. 3 - OT-specific contingency and recovery guidance.
• NIST Cybersecurity Framework 2.0 - Respond and Recover functions and outcomes.
• ISA/IEC 62443-3-3 - FR 7 Resource Availability, SR 7.3 backup, SR 7.4 recovery and reconstitution.
• NERC CIP-009 - recovery plans for bulk electric system cyber assets.
• MITRE ATT&CK for ICS - techniques such as Data Destruction and Loss of Availability to test recovery assumptions against.

09Common pitfalls that turn recovery into rebuild

Most failed recoveries do not fail because of one missing tool. They fail because the plan was never exercised under realistic conditions, so the gaps only appear when the pressure is highest and the people who knew the system are unavailable.

• Backups stored on the same network as production, so ransomware encrypts the recovery copies too.
• Backups that are never test-restored, so corruption or version drift is discovered only during a real outage.
• No documented safe-state or restart sequence, leaving recovery to improvisation by whoever is on shift.
• Recovery procedures stored only inside the systems being recovered, with no offline copy.
• Single points of knowledge: one engineer who understands the controller logic and is unreachable.
• Restoring IT connectivity before the OT network is verified clean, reopening the original attack path.

The fix is unglamorous: tabletop exercises, periodic restore tests, offline runbooks, and cross-training so recovery does not depend on a single person. Treat the recovery plan as a living document that is rehearsed, not a binder that is filed.

10Where one-way transfer fits in recovery

A data diode does not recover anything. It transfers nothing inbound by design. So why does it matter for disaster recovery? Because the most dangerous failure in an OT incident is losing the clean copies you need to recover from. If backups and golden images live on a network the attacker can reach, they become part of the blast radius.

A one-way path lets you push backups, historian data and configuration baselines outward from the protected OT zone to a recovery repository, without giving anything on the destination side a route back into production. The same enforcement that keeps command traffic out also keeps ransomware from following the replication path back to encrypt the copies. The recovery store becomes a publication-only destination, not a reachable share.

It is one control among many. Segmentation, immutable storage, offline copies, monitoring and tested procedures all carry weight. But for the specific question "how do I keep my recovery copies out of reach of the same attack that hit production," reducing bidirectional reachability with an AIRGAPNET controlled connectivity pattern or a data diode is a clean, provable answer worth evaluating alongside the rest.

11Closing thought

OT disaster recovery is ultimately a promise about the physical world: when something goes wrong, the process can be brought back to a safe, known state within a time the organization can survive. That promise is kept long before the incident, in tested backups, documented safe states, rehearsed sequences and protected recovery copies.

Start with the question the plan must answer: if this process line went dark today and the network could not be trusted, what would it take to bring it back safely, and is every dependency of that answer something you can prove rather than hope?

FAQFrequently asked questions

SRCSources of record