What is Disaster Recovery?
Disaster Recovery (DR) is the planned and tested set of processes, resources and technology through which an organisation restores its critical systems, data and infrastructure within an agreed time after a serious disruption, such as a cyber attack, fire, flood, prolonged power outage or human error. Where Business Continuity determines how the organisation keeps delivering during a crisis, DR covers the technical recovery of the underlying systems. In environments where IT and OT converge, that means not only servers and databases, but also PLC programs, SCADA servers and network configurations that control a physical process.
🎯 Which scenarios does Disaster Recovery protect against?
A disaster recovery plan (DRP) is worked out per scenario, because each scenario needs a different recovery route:
| Category | Examples | Typical recovery |
|---|---|---|
| Cyber attack | Ransomware, wipers, sabotage, prolonged DDoS | Clean rebuild from offline backups, after forensic investigation |
| Physical disasters | Fire in a server room, flooding, lightning strike | Failover to a second site or replacement hardware |
| Human error | Deleted configurations, corrupt databases, failed updates | Rolling back to the last known good version (restore) |
| Technical failure | Faulty servers, storage, network equipment or power supply | Failover to redundant components |
| OT incidents | Lost PLC logic, broken HMI, failed SCADA server | Reloading approved projects onto spare hardware |
The key difference between these scenarios: after a technical failure your backups are trustworthy, after a cyber attack that is not a given. An attacker may have been inside the network for weeks, so recent backups may be compromised as well.
🔄 What is the difference between backup, Disaster Recovery and Business Continuity?
These terms are often used interchangeably, but they build on each other:
| Term | Question it answers | Result |
|---|---|---|
| Backup | Do I have a usable copy of data and configurations? | Recovery points, determined by the RPO |
| Disaster Recovery | How do I get systems working again within the RTO? | Recovery procedures, alternate site, spare hardware |
| Business Continuity | How does the organisation keep delivering while systems are down? | Emergency procedures, manual operation, communication |
| Incident response | How do I contain and investigate a security incident? | Isolation, analysis, notification |
A backup without a recovery procedure is therefore not yet DR, and a DR plan without a continuity plan leaves open what the plant does during the hours or days that recovery takes. In practice all four sit in one coherent framework, often driven by ISO 22301.
🔢 Which recovery objectives and alternate site types are there?
DR design starts with two figures from the Business Impact Analysis: the RTO (Recovery Time Objective, the maximum time a system may be down) and the RPO (Recovery Point Objective, the maximum amount of data you may lose, expressed in time). Both must fit within the MTPD, the period after which an outage becomes unacceptable. Afterwards you use the MTTR to check whether the actual recovery time stayed within the RTO.
The shorter the RTO, the more expensive the recovery option. The common classification, with indicative recovery times:
| Recovery option | What is ready | Indicative recovery time | Use in OT |
|---|---|---|---|
| High Availability pair | Active second server with real-time synchronisation | Seconds to minutes | Redundant SCADA servers, DCS controllers |
| Hot site | Fully equipped second location with current data | Minutes to hours | Second control room at utilities |
| Warm site | Hardware and network in place, data and software still to be loaded | Hours to days | Standby servers running virtual machines |
| Cold site | Space, power and cooling, but no configured systems | Days to weeks | Rarely suitable for production |
| Spare hardware | Identical PLCs, power supplies and I/O cards in stock | Hours | Standard for critical controllers |
A safety function falls outside this list: it is not “recovered” but designed so that a fault leads to a safe state (fail-safe), often with redundancy.
🔐 Which laws and standards require Disaster Recovery?
- NIS2, Article 21(2)(c) - literally lists “business continuity, such as backup management and disaster recovery, and crisis management” as a mandatory measure
- Cybersecurity Act - the Dutch transposition of NIS2 (Cyberbeveiligingswet), in force since 15 August 2026; Article 9 of the Cybersecurity Decree requires recovery procedures, periodically verified backups and a continuity, recovery and crisis plan that is tested periodically
- ISO 27001:2022 - controls A.5.30 (ICT readiness for business continuity), A.8.13 (information backup) and A.8.14 (redundancy of information processing facilities)
- IEC 62443-3-3 - system requirement SR 7.3 (control system backup, from security level 1) and SR 7.4 (control system recovery and reconstitution to a known secure state)
- NIST CSF 2.0 (February 2024) - the Recover function with categories RC.RP (incident recovery plan execution) and RC.CO (incident recovery communication); RC.RP-03 requires you to verify the integrity of backups before restoring from them
- NIST SP 800-34 Rev. 1 - the US guide to contingency planning from 2010, still a widely used reference for structuring a DR plan
🏭 Why is Disaster Recovery different in OT?
You do not recover an OT environment simply by restoring a server image. Key differences:
- Order matters - first the network and Active Directory, then engineering stations and licence servers, then SCADA and the historian, and only then the start-up of the process
- Software is time-bound - an HMI project only runs on the right software version; old installers and licences are often no longer downloadable and must be kept by you
- Online versus offline - the program in the PLC may differ from the project file on the laptop; without change management and version control you do not know which version is the right one
- Firmware - must match the project and is usually not part of a project backup, so keep the correct vendor firmware files yourself
- Physical start-up - after recovery a plant has to be started up in a controlled way, with operators and process engineers, not just by IT
- Network Segmentation - good separation between IT and OT limits how much you have to recover; at Colonial Pipeline (May 2021) only IT was hit, yet the pipeline was shut down for six days as a precaution
The best-known lesson comes from NotPetya (June 2017). Maersk had to reinstall around 4,000 servers and 45,000 PCs. Server backups existed, but all domain controllers had been wiped at the same time; Active Directory could only be restored thanks to a single domain controller in Ghana that had been offline because of a power cut.
🔧 How do you draw up a disaster recovery plan?
- Take inventory - record which systems exist, with versions and dependencies, based on an up-to-date asset inventory
- Assess risks and set recovery objectives - a risk analysis, plus RTO and RPO per system from the business impact analysis, agreed with production
- Choose the recovery strategy - HA, alternate site, spare hardware or rebuild, per system in line with its RTO
- Secure the backups - 3-2-1-1-0 with at least one offline or immutable copy, separated from the domain; also keep installation media, licences and golden images
- Write runbooks - step-by-step recovery procedures per system, with recovery order, contacts and suppliers, also available on paper
- Test and exercise - from a tabletop exercise to a full recovery test on spare hardware; an annual recovery test is a common minimum, and train the people who have to carry out the plan
- Evaluate and improve - feed test results and incidents back into the plan, and update it after every change to the installation
After a cyber attack there is one extra step: restore nothing until it is clear how the attacker got in. Check backups for malware and, if in doubt, rebuild from clean installation media, otherwise you restore the attacker along with your systems.
❓ Frequently asked questions
What is a disaster recovery plan (DRP)?
A disaster recovery plan is the documented playbook that describes how an organisation restores its critical IT and OT systems after a serious disruption. It contains the recovery objectives (RTO and RPO), the recovery order, step-by-step procedures per system, the people responsible and the contact details of suppliers.
How often should you test a disaster recovery plan?
A disaster recovery plan should be tested at least once a year and after every major change to the installation. The Dutch Cybersecurity Decree sets no fixed interval, but it does require periodic tests that you can demonstrate. A recovery test of a PLC program on spare hardware provides more evidence than a paper check alone.
Is a backup the same as Disaster Recovery?
No, a backup is a copy of data or configurations, whereas Disaster Recovery covers the complete recovery process: hardware, network, software, licences, recovery order and people. A backup is a necessary part of Disaster Recovery, but without a tested recovery procedure you do not know whether, or how quickly, you can recover with it.
Is Disaster Recovery mandatory under NIS2?
Yes, Article 21 of NIS2 explicitly lists backup management and disaster recovery as a mandatory measure for essential and important entities. In the Netherlands this is worked out in the Cybersecurity Act and Article 9 of the Cybersecurity Decree, which have applied since 15 August 2026.
What is the difference between RTO and RPO in Disaster Recovery?
The RTO is the maximum time a system may be down before the consequences become unacceptable, while the RPO is the maximum amount of data that may be lost, expressed in time. The RTO determines the recovery strategy and type of alternate site; the RPO determines how often backups or replication must take place.
Can Disaster Recovery for OT be done in the cloud?
Partly: backups of projects, historian data and virtual servers can be stored in the cloud, and some SCADA servers can run there temporarily. Control of the physical process, however, stays local, and recovering PLCs always requires access to the installation itself. An offline copy on your own site therefore remains necessary.
📌 In summary
Disaster Recovery is the planned and tested recovery of critical systems after a serious disruption, driven by RTO and RPO and mandatory under NIS2 and the Dutch Cybersecurity Act. In IT/OT environments it is not just about backups, but about the right recovery order, retained software and licences, spare hardware and trained people who can safely start a plant up again.