Industrial Cyber Recovery: Restoring OT Systems Safely After a Cyber Incident

"We restored from backup, we're done" is the point where a lot of industrial recovery efforts go wrong — not because the restore failed, but because restoring a backup was treated as the finish line instead of one step in a longer process. Industrial cyber recovery is the work of safely bringing an operational environment back to a trustworthy, functioning state — and that's a materially bigger job than getting files back.

Recovery Is Not Simply Restoring Backups

A backup restores a system to a point in time. It says nothing about whether that system, once restored, will behave correctly alongside everything else it depends on and everything that depends on it — or whether the backup itself predates the compromise and is quietly bringing the problem back online with it.

Mapping System Dependencies First

Before restoring anything, map what depends on what. A historian is only useful once the SCADA server feeding it is back and validated. An HMI is only useful once the controllers it displays are confirmed to be in a known-good state. Recovering systems in the wrong order wastes effort at best, and at worst brings something online in a state that looks fine on a screen but isn't behaving correctly in the process.

Identity Infrastructure

If Active Directory or another identity system was in scope of the incident, it typically needs to be trustworthy before much else can be safely restored — since authentication for engineering workstations, historians, and other supporting systems usually depends on it. Recovering downstream systems against a still-compromised identity layer just reintroduces the problem.

Networking

Confirm network segmentation and access controls are in the state you intend before reconnecting recovered systems — an incident is a natural point to discover that segmentation had degraded over time, and recovery is the moment to fix that rather than reproduce the same exposure.

Engineering Workstations

These are high-value recovery targets because they often hold PLC programs, HMI configurations, and project files used to validate and rebuild control system logic elsewhere. They also need particular scrutiny — a compromised engineering workstation is a plausible path for an attacker to have altered control logic, so validating its integrity matters as much as restoring its availability.

HMIs and SCADA

Beyond restoring the software, confirm that displayed values and control functions match what the underlying controllers are actually doing. A HMI that looks normal but is misrepresenting process state is arguably more dangerous than one that's visibly offline, because it can lead operators to make decisions based on inaccurate information.

Historians

Restore historians after the systems that feed them are validated, and check for gaps or inconsistencies in the data around the incident window — both to support any investigation and because downstream reporting or compliance processes may depend on that data being complete and accurate.

Vendor and OEM Systems

Specialized vendor-supported systems often need the vendor involved in recovery directly, particularly where proprietary configuration or licensing is involved. Loop vendors in early rather than attempting to reverse-engineer a recovery process for equipment you don't have full visibility into.

Backup Validation

Before trusting any backup as a restoration source, verify it predates the compromise and is actually usable — not just that a backup job completed successfully. A backup that includes the compromise, or that turns out to be corrupted when you actually need it, is worse than no backup, because it creates false confidence at exactly the wrong moment.

Sequencing the Rebuild

Prioritize safety-critical and safety-adjacent systems first, then core process control, then supporting infrastructure like historians and reporting systems. This sequence should be informed by the dependency map built earlier, not by which systems happen to be easiest to restore first.

Operational Signoff

A system isn't "recovered" because it powers on and passes a basic connectivity check. It's recovered when engineering and operations teams have validated that it's behaving correctly within the process it supports and are willing to put their name behind returning it to production. This signoff step is what actually closes the loop on recovery — treating it as optional is how organizations end up rediscovering problems days after they declared the incident over.

Monitoring After Restoration

Recovery doesn't end the moment systems are back online. Elevated monitoring in the days and weeks following restoration helps catch anything that wasn't fully resolved — a persistence mechanism that was missed, an integrity issue that wasn't obvious immediately, or a dependency that was overlooked during the rebuild.

Recovery done this way takes longer than a straight backup restore, and that's the point — it's the difference between operations resuming and operations resuming safely, with confidence that what's running is what you intended to be running. If you're navigating recovery after an incident, or want to strengthen recovery readiness before one happens, our Industrial Cyber Recovery and Recovery & Resilience teams can help.