Disaster Recovery (DR) — known in German as Notfallwiederherstellung — refers to the planned technical restoration of IT systems, applications and data following a serious failure, whether caused by ransomware, a data centre outage, hardware defects or a natural event. Disaster Recovery works with predefined recovery targets — in particular the Recovery Time Objective (RTO) and Recovery Point Objective (RPO) — and with documented, tested recovery plans. The authoritative reference frameworks are ISO/IEC 27031, BSI Standard 200-4 and NIST SP 800-34.
What is Disaster Recovery?
Disaster Recovery encompasses the totality of procedures, resources and plans that an organisation uses to return failed IT systems and lost data to a defined operational state following a serious incident.
The term deliberately describes the technical level: servers, networks, databases, applications, configurations and data holdings. How business units continue to operate in the interim is governed not by Disaster Recovery but by the overarching Business Continuity Management framework.
A defining characteristic of Disaster Recovery is the prior definition of target values. Two questions must be answered before an incident occurs: how long may a system be unavailable (Recovery Time Objective) and how much data may be lost (Recovery Point Objective)?
All technical decisions flow from these targets — backup frequency, replication methods, standby capacity and site selection. An organisation that does not know its target values cannot design an appropriate architecture; it can only hope.
A second characteristic is its exceptional nature. Disaster Recovery does not apply to a single failed hard drive — it applies when operations can no longer continue in the existing environment and a switchover to a fallback solution is required. This switchover — the failover — is a formally triggered process with clearly designated decision-making authority. Disaster Recovery is therefore always both: a technical capability and a regulated procedure.
Why is Disaster Recovery important?
Disaster Recovery matters because the ability to recover now determines the extent of damage more often than the ability to defend. Ransomware can encrypt production systems and backups within hours; cloud and network dependencies concentrate failure risk at a small number of points; and extreme weather events are affecting data centre locations previously considered non-critical. Under these conditions, complete prevention is no longer a reliable assumption.
The financial damage caused by an IT outage rarely accumulates in a linear fashion. In the first few hours, outages can often be bridged through improvisation. After that, damage escalates disproportionately, as deadlines are missed, contractual penalties kick in, customers look elsewhere and regulators demand answers. For operators of critical infrastructure, the damage is not measured in financial terms alone, since their services are directly relevant to supply, safety and public health.
There is also an evidential dimension: whether an organisation was adequately prepared is regularly scrutinised after an incident — by insurers, auditors, regulators and, in dispute cases, the courts. In practice, the critical question is rarely whether a plan existed, but when the last documented recovery test took place.
How does Disaster Recovery differ from backup, high availability and BCM?
Disaster Recovery differs from adjacent disciplines by its subject matter: backup creates and retains copies of data; high availability prevents failures during normal operations; Business Continuity Management organises the operational capability of the entire organisation; and Disaster Recovery restores systems and data after a failure has occurred. These terms are frequently used interchangeably, which in practice creates gaps.
| Discipline | Focus | Relationship to Disaster Recovery |
|---|---|---|
| Backup | Creating and retaining data copies | A prerequisite, not a substitute: a backup without a tested recovery procedure is not Disaster Recovery |
| High Availability (HA) | Avoiding failures through redundancy during normal operations, typically within a single site | Complementary: HA absorbs individual component failures; DR addresses the loss of entire environments |
| IT Service Continuity Management (ITSCM) | The overall continuity and availability of IT services | Overarching: Disaster Recovery is the implementation layer within ITSCM |
| Business Continuity Management (BCM) | Continuation of time-critical business processes, including personnel, buildings and service providers | Overarching: BCM defines the time targets; Disaster Recovery fulfils them technically |
| Emergency and crisis management | Acute incident response; decisions made by the crisis team | Parallel: the crisis team decides; Disaster Recovery teams execute |
In practice, this distinction matters: an organisation that only operates high availability can withstand component failures but not logical data corruption. An organisation that only holds backups has data but no target environment and no recovery sequence. Disaster Recovery combines data protection, target infrastructure and procedure into a robust recovery capability.
What metrics does Disaster Recovery use?
The central metrics in Disaster Recovery translate operational downtime tolerances into measurable technical targets. They are typically derived from the Business Impact Analysis and serve as the interface between the business and IT.
| Metric | Meaning |
|---|---|
| RTO | Recovery Time Objective: the timeframe within which a system must be available again after a failure |
| RPO | Recovery Point Objective: the maximum tolerable data loss, expressed as a time period prior to the incident |
| MTD / MTPD | Maximum Tolerable Downtime / Maximum Tolerable Period of Disruption: the duration of downtime beyond which damage becomes unacceptable; RTO must fall below this threshold |
| WRT | Work Recovery Time: the time needed for data reconciliation, re-entry and sign-off after technical recovery; RTO + WRT ≤ MTD |
| MTTR | Mean Time To Repair/Recover: the average recovery duration under normal conditions, used as a planning benchmark |
| RTA / RPA | Recovery Time / Point Actual: the values actually achieved during a test or real incident — the definitive measure of effectiveness |
The distinction between target values and actual values is the weak point of many recovery frameworks. An RTO of four hours is a requirement. Whether it is achievable can only be confirmed by the measured Recovery Time Actual during a realistic recovery exercise.
Work Recovery Time is equally important: a system may be technically available whilst the business unit still requires hours to reconcile records and verify the data state. If this element is not factored into planning, the committed timelines are systematically over-optimistic.
What does a Disaster Recovery Plan (DRP) contain?
A Disaster Recovery Plan (DRP) contains all the information a recovery team needs to act effectively under time pressure and without access to the failed environment. What matters is not the length of the plan but its usability in an incident: concise, current, unambiguous and available offline.
- Scope and trigger criteria: Which systems does the plan cover and when does it apply?
- Roles and decision-making authority: Who declares the disaster, who initiates the failover, who approves what — including deputies?
- Prioritised recovery sequence: Systems listed with their RTO and RPO, ordered according to technical dependencies.
- Technical recovery instructions: Step-by-step, with storage locations for images, backups, keys, licences and configurations.
- Alert and communication pathways: Round-the-clock contact details, escalation levels and communication with service providers.
- Third-party dependencies: Cloud providers, data centre operators, maintenance contracts and contractually committed response times.
- Verification and sign-off criteria: How integrity and operational readiness are verified before handing systems back to the business.
A recurring mistake is storage: if the Disaster Recovery Plan exists only on the file system, intranet or ticketing system, it will be inaccessible following a ransomware encryption event — precisely when it is needed most. The same applies to password safes and emergency contact lists. A tested offline copy at defined locations — whose currency is itself part of the plan — has proven to be the most reliable approach.
What Disaster Recovery strategies are there?
Disaster Recovery strategies differ in the amount of infrastructure an organisation holds in reserve for an emergency, which directly determines the achievable RTO, RPO and cost. The choice is not a matter of technical preference but a derivation from the organisation’s operational time targets.
| Strategy | Principle | Typical RTO | Effort |
|---|---|---|---|
| Backup & Restore | Recovery from backup onto freshly provisioned systems | Days | Low |
| Cold Standby / Cold Site | Prepared site with no running systems | Days | Low to medium |
| Pilot Light | Core components running minimally, scaled up in the event of an incident | Hours | Medium |
| Warm Standby / Warm Site | Reduced-capacity secondary environment running with ongoing replication | Minutes to hours | High |
| Hot Site / Active-Active | Two fully operational, parallel production sites | Seconds to minutes | Very high |
The data side is dimensioned separately. The 3-2-1 rule still applies to backups: three copies of data on two different media types, with one copy at an off-site location.
Given the current threat landscape, this is frequently extended to 3-2-1-1-0: one copy held offline or in immutable storage (air gap or WORM), and zero errors in the recovery test. For short RPOs, replication is added: synchronous replication virtually eliminates data loss but is limited by distance and latency, whilst asynchronous replication allows greater distances and accepts a defined residual loss.
For site selection, georedundancy is the key consideration. The BSI recommends a minimum distance of 200 kilometres between georedundant data centre sites and permits shorter distances only with documented justification and risk analysis — the minimum threshold is 100 kilometres. The rationale is the reach of regional events such as flooding, power grid disruptions or widespread network outages: two data centres within a few kilometres of each other are protected against component failures but not against a regional incident.
How does Disaster Recovery work during an incident?
Disaster Recovery follows a fixed sequence during an incident — one that must be defined and rehearsed before the event. Improvisation in the first few hours consumes the time that is later needed for recovery.
Detection and assessment Monitoring, the service desk or a security alert flags a disruption. The key question is whether it is a resolvable incident or a failure that requires a switchover to the fallback environment.
Disaster declaration A designated role formally declares the disaster, triggering the plan. This authority must be clearly defined — including deputies outside business hours. In practice, this step is where most time is lost.
Team activation and communication Recovery teams, the crisis team and relevant service providers are alerted. In parallel, a communication channel is established that is independent of the failed infrastructure.
Failover and prioritised recovery The switchover to the fallback environment follows the documented dependency sequence: network, name resolution and directory services first, then databases, then applications and interfaces. Determining this sequence during the incident costs hours.
Verification and sign-off Before handing systems back to the business, data integrity, completeness and functional readiness are verified against defined criteria — including checks for malicious code and persistent access in the event of a security incident.
Failback to normal operations The return to the primary environment is planned independently, with a fresh data reconciliation and its own maintenance window. This is often more demanding than the failover, as two data states must be merged.
Post-incident review Analysis of the achieved values (RTA/RPA), lessons learned, plan maintenance and documentation for regulators, insurers and internal audit.
How does ransomware change Disaster Recovery?
Ransomware fundamentally changes Disaster Recovery because the outage is not random but deliberate — and directed against the recovery process itself. Before encrypting, attackers systematically search for backup systems, backup servers and snapshots, attempting to delete or encrypt them alongside the production environment. Recovery frameworks designed for technical failures are inadequate in this scenario.
Three consequences are essential:
First, at least one backup copy must be out of reach of compromised accounts — offline, immutable or in a separate administrative domain, explicitly not accessible using the credentials of the production environment.
Second, the recovery point shifts: what matters is not the last backup but the last demonstrably uncompromised one, which may represent a greater data loss than originally planned.
Third, restoring into a still-compromised environment is futile; organisations therefore work with isolated recovery environments, known as clean room recovery.
Particular attention is required for the central directory. If Active Directory is affected, virtually every login depends on a system that itself needs to be recovered — through its own documented Forest Recovery procedure.
In practice, recovery plans are most frequently incomplete precisely here: applications are documented, but the prerequisite for using them is not. There is also an inherent tension between forensic investigation and urgency — overwriting compromised systems too quickly destroys evidence needed for regulatory reporting and insurance claims. Architectural approaches such as Zero Trust limit the spread of an attack in advance but do not replace recovery capability.
How is a Disaster Recovery Plan tested?
A Disaster Recovery Plan is tested at graduated levels of depth, because different test types uncover different classes of failure. A plan review checks the currency and completeness of documentation; a tabletop exercise tests roles and decision pathways through a dry run; a restore test verifies the actual recoverability of individual systems; a failover test covers the switchover of entire environments; and a full exercise tests the end-to-end process under realistic conditions. Only the higher levels of testing produce reliable data on RTA and RPA.
A regular recovery test is not an optional mark of maturity — it is required by many regulatory frameworks. An annual test of critical systems has become the accepted minimum, supplemented by ad hoc tests following significant changes to architecture, service providers or data volumes.
Tests are only meaningful, however, if they include the uncomfortable conditions: without the usual administrators, without access to documentation in the primary system, and with the full volume of data. In practice, recovery failures rarely stem from the procedure itself but from details — missing licence keys, expired certificates, undocumented configurations and transfer times longer than estimated.
What standards apply to Disaster Recovery?
Several complementary frameworks are authoritative for Disaster Recovery. ISO/IEC 27031 is the central guide for ICT Readiness for Business Continuity (IRBC), connecting technical recovery with the continuity management requirements of ISO 22301.
ISO/IEC 27001 (2022 edition) addresses the topic through controls A.5.29 (information security during disruption), A.5.30 (ICT readiness for business continuity) and A.8.13 (information backup).
In German-speaking countries, BSI publications serve as the practical reference. BSI Standard 200-4 situates recovery and restoration within the continuity process and explicitly distinguishes between contingency operations and the return to normal operations. The IT-Grundschutz Compendium provides the technical detail, particularly through building blocks CON.3 (data backup concept) and DER.4 (emergency management).
In the international context, NIST SP 800-34 (Contingency Planning Guide) is widely used, covering the planning framework from Business Impact Analysis to the testing programme. ITIL provides the framework for IT Service Continuity processes.
What are the legal requirements for Disaster Recovery?
For many organisations, Disaster Recovery is not a voluntary precaution but a legal obligation.
The NIS 2 Directive (EU) 2022/2555 requires risk management measures under Article 21 that explicitly include backup management, disaster recovery and crisis management; essential and important entities across a broad range of sectors are covered. In Germany, this is implemented through the NIS 2 Implementation Act.
In the financial sector, the DORA Regulation (EU) 2022/2554 requires an ICT business continuity policy including response and recovery plans (Article 11), as well as explicit backup, recovery and restoration procedures with separate environments (Article 12), and mandates a documented testing programme. The supervisory requirements of MaRisk, BAIT, VAIT and KAIT apply additionally.
For operators of critical infrastructure, obligations arise from the KRITIS regulation and the BSI Act, which requires state-of-the-art measures to prevent disruptions to availability.
Under data protection law, Article 32 GDPR is relevant: paragraph 1 identifies availability as a protection objective and explicitly requires in subparagraph (c) the ability to restore the availability of and access to personal data in a timely manner in the event of a physical or technical incident. A functioning recovery procedure is therefore a component of GDPR compliance — not merely a question of IT operational quality.
What is Disaster Recovery as a Service (DRaaS)?
Disaster Recovery as a Service (DRaaS) is the outsourcing of recovery capacity to a service provider that supplies target infrastructure, replication and failover processes as a managed service. For organisations without a second data centre, DRaaS significantly lowers the barrier to entry, as standby capacity does not need to be permanently maintained and financed.
Responsibility, however, cannot be outsourced. Key questions must be clarified: the contractually committed RTO and RPO values and the evidence supporting them; how the provider will respond during a regional large-scale event affecting many clients simultaneously; the right to conduct independent tests; where data is held and processed; and the process for returning to in-house operations or migrating to a different provider.
From a regulatory perspective, such providers are regularly classified as critical ICT third-party providers, with corresponding requirements for contractual design and exit strategies. For smaller organisations, the same principle applies as in Business Continuity Management: a lean procedure with tested backups, a documented recovery sequence and an annual restore test is more effective than an ambitious architecture that never reaches completion.
What role does communication play in Disaster Recovery?
Communication is a critical resource in Disaster Recovery — and is notably often affected by the very incidents it is needed to manage. When primary infrastructure fails or is compromised, email, telephony, chat platforms and the intranet are frequently part of the damage. It is precisely at that moment that recovery teams need to be coordinated, decisions need to be communicated, service providers need to be engaged and reporting deadlines need to be met. A plan whose alerting mechanism relies on the failed system cannot be triggered when it is needed.
From a Disaster Recovery perspective, three requirements are decisive:
Independence from the incident: Contact details, escalation pathways and plan documents must be accessible without the affected environment.
Separation of communication channels: Technical recovery teams, the decision-making level and the wider organisation require separate, clearly assigned channels, so that status updates do not become lost in the general flow of information.
Traceability: Alerts, approvals and decisions made during recovery subsequently serve as evidence for regulators, insurers and internal audit.
Where approved and rehearsed alternative channels are absent, participants will typically fall back on personal consumer messaging apps. This creates shadow IT precisely at the moment when confidentiality and evidential integrity are most critical — with consequences for data protection and documentation.
Organisations typically address this through pre-provisioned communication solutions that are independent of the primary infrastructure, whose availability is verified during Disaster Recovery tests and which form part of the overall emergency communication framework.
Teamwire can demonstrate how secure communication for recovery teams and crisis management can be implemented — in a demo or a free trial.
What mistakes are most common in Disaster Recovery?
The most common mistake in Disaster Recovery is confusing data backup with recovery capability: backups are running but have never been fully restored. Further typical weaknesses from practice include:
- Backups reside in the same domain and network segment as production systems and can be deleted using compromised administrator accounts
- Recovery plans and emergency contacts exist only digitally in the system that has failed
- RTO and RPO targets have been set without the measures, bandwidth and capacity needed to support them
- The dependency sequence for recovery is not documented — particularly for directory services, name resolution and certificate infrastructure
- Tests are limited to individual files or virtual machines rather than end-to-end application chains
- Failback to normal operations is unplanned, despite requiring the merging of two data states
- Communication and alerting are taken for granted rather than being planned as an independent, separately resourced capability
Key takeaways
- Disaster Recovery (DR) is the planned technical restoration of IT systems, applications and data following a serious failure.
- Disaster Recovery is the implementation layer within IT Service Continuity Management; the operational time targets are defined by Business Continuity Management.
- RTO and RPO are the defining metrics: they set the permissible downtime and data loss, and thereby determine the entire architecture.
- Backup is a prerequisite, not a substitute: Disaster Recovery requires a tested recovery procedure with a target environment and a documented recovery sequence.
- Strategies range from Backup & Restore through Pilot Light and Warm Standby to Active-Active — with RTOs from days to seconds and correspondingly increasing costs.
- In ransomware scenarios, what matters is not the last backup but the last demonstrably uncompromised one; immutable or offline backups and isolated recovery environments are essential.
- Authoritative frameworks include ISO/IEC 27031, ISO 22301, ISO/IEC 27001, BSI Standard 200-4 and NIST SP 800-34; the BSI recommends a minimum distance of 200 kilometres between georedundant sites.
- NIS 2, DORA, the KRITIS regulation and Article 32 GDPR make recovery capability a legal obligation — including the requirement to demonstrate regular testing.
- A Disaster Recovery Plan is only as good as its last recovery test; the measured actual values (RTA/RPA) are the only reliable measure — not the targets.
- Communication is a critical resource: alerting, team coordination and regulatory reporting require channels that are independent of the failed system.