Recovery

What is Recovery?

Recovery is the planned process by which an organisation returns systems, data and processes to a reliable, working and secure state after an incident such as data loss, Ransomware, human error or a system crash. Recovery is therefore more than putting a backup back: it also covers choosing a clean recovery point, deciding the order of restoration, checking integrity and formally releasing systems back to production. In OT environments, it also includes safely starting up a physical process.

Backup is the preparation. Recovery is the moment of truth.

Without good backups, recovery is often impossible. But a backup alone is not enough: recovery determines whether you can restore quickly, completely and reliably.

🔄 What is the difference between backup, restore and recovery?

The three terms form a chain. The backup makes recovery possible, the restore puts data or configurations back, and recovery is the entire journey until the process runs normally again.

🎯 Which recovery scenarios occur?

Each type of incident calls for a different recovery route. The key distinction: after a technical failure you can trust your backups, after a cyberattack you cannot take that for granted.

🔢 How do RTO and RPO shape recovery?

Two figures from the Business Impact Analysis drive the entire recovery design:

• RTO (Recovery Time Objective) - the maximum time a system may be down before the consequences become unacceptable
• RPO (Recovery Point Objective) - the maximum amount of data you may lose, expressed in time; this determines the backup frequency
• MTPD (Maximum Tolerable Period of Disruption) - the longest disruption the organisation can tolerate; the RTO must stay comfortably within it
• MTTR (Mean Time to Repair, also Mean Time to Recovery) - the average recovery time actually measured, which tells you afterwards whether the RTO was achievable

A short RTO requires prepared resources, such as spare hardware, ready-made images or virtualised servers. An RPO of zero can only be achieved with replication or redundancy, not with periodic backups.

🏭 Why is recovery different in OT environments?

In OT you do not only restore IT systems, but also the control of a physical process. That makes recovery more complex and sometimes even a matter of safety.

• Configurations and Firmware - restoring PLC programs, firmware versions and parameters of drives and field devices after corruption
• Rebuilding servers - redeploying SCADA servers with the correct drivers, licences and communication links
• Engineering stations - without working engineering software in the right version you cannot restore a single controller
• Historian data - synchronising Historian data from local buffers after the network is restored
• Recipes and settings - validating operator settings, the integrity of recipe data and alarm settings from backup sources
• Safe start-up - a plant starts up in a fixed sequence, with operators and process safety first; a system that technically works has not yet been safely released
• Testing - rehearse recovery in an offline test environment or digital twin where possible

Vendors are often indispensable here: old hardware may no longer be available, and some software can only be reactivated with the manufacturer’s help.

🔧 How do you approach recovery step by step?

The NIST CSF 2.0 (February 2024) describes recovery in the Recover function, with the categories RC.RP (incident recovery plan execution) and RC.CO (incident recovery communication). Translated into practice:

1. Start the recovery plan from incident response - recovery only begins once the threat has been contained; otherwise you restore systems that will be reinfected.
2. Determine scope and priority - first restore what supports safety and critical processes, such as Active Directory, the network and control systems, and reporting later.
3. Check your recovery assets - verify the integrity of backups and images before use and choose a recovery point from before the first intrusion; forensic investigation helps pinpoint that moment.
4. Rebuild in a clean environment - use prepared golden images, place restored systems in a separate network segment and only add systems that are demonstrably clean.
5. Verify and release - check the integrity of restored systems, test communications and have the process and safety owners release the plant.
6. Communicate and close - keep internal and external stakeholders informed, declare recovery complete based on criteria agreed in advance, and document everything.

Rehearse these steps beforehand, for example with a tabletop exercise and a real restore test on spare hardware. Only then will you know whether your RTO is realistic.

🔐 Which laws and standards require demonstrable recovery?

📚 What do major incidents teach us about recovery?

• NotPetya (2017) - Maersk had to rebuild around 49,000 laptops and 4,000 servers. Active Directory could only be restored thanks to a single domain controller in Ghana that had been offline due to a power cut. Lesson: keep offline copies of identity systems.
• Colonial Pipeline (2021) - after a ransomware attack on IT, the pipeline was shut down for six days. The decryption tool obtained by paying the ransom was so slow that the company relied largely on its own backups. Lesson: paying is not a recovery strategy.

Both incidents show that network segmentation and an air gap for backups greatly limit the scale of recovery.

❓ Frequently asked questions

What is the difference between recovery and disaster recovery?

Recovery is any restoration of systems, data or processes after an incident, from a single lost file to an entire plant. Disaster recovery is the planned restoration after a severe disruption, with predefined procedures, fallback resources and recovery times. Disaster recovery is therefore a specific, organised form of recovery.

How often should you test recovery?

You should test recovery periodically and demonstrably; the Dutch Cybersecurity Decree sets no fixed interval, but an annual restore test is a common minimum. Also test after major changes, such as a migration or a new control system. Only a tested recovery gives you confidence that your RTO is achievable.

Why is recovery after ransomware harder than after a failure?

With ransomware, attackers may have been in the network for weeks, so recent backups may also be compromised. Recovery then first requires a forensic investigation to establish the moment of intrusion and a rebuild in a clean environment. Otherwise you risk restored systems being reinfected immediately.

What should you at least be able to recover in OT?

In OT you should at least be able to recover PLC programs, HMI and SCADA projects, firmware versions, network configurations and the engineering software needed to load them. Keep an approved, offline, version-controlled copy of each. Without an engineering station and licences, OT recovery is often impossible.

Who decides that a system may return to production after recovery?

After recovery, the process owner and the person responsible for process safety decide, together with IT or OT operations, that a system may return to production. That release follows criteria agreed in advance, such as integrity checks and a successful functional test. Record the decision as part of closing the incident.

Is paying a ransom a form of recovery?

Paying a ransom is not a reliable form of recovery: there is no guarantee that decryption works, and it is often slow or incomplete. At Colonial Pipeline, the company relied largely on its own backups even after paying. Invest instead in offline and immutable backups and rehearsed recovery procedures.

📌 In summary

Recovery is the practical side of Backup - the moment when it becomes clear whether you really are prepared. Good recovery starts with RTO and RPO, uses verified, clean recovery points and only ends when the process demonstrably runs safely. Without a tested recovery plan, a backup is only a false sense of security.