Creating a Disaster Recovery Plan: From Incident Back to Normal Operations

What a disaster recovery plan is -- and what it is not

A Disaster Recovery Plan (DR plan) describes how you restore your systems, applications, and data after a severe IT outage. It answers the question: what do we do when our IT infrastructure fails in whole or in part, and how do we return to a functional state?

The term is often confused with or used interchangeably with Business Continuity Plan (BCP). That is incorrect. The BCP addresses business processes and asks: how do we maintain business operations even when systems fail? The DR plan is the technical component of the BCP and focuses on IT recovery. A BCP may include measures such as "employees temporarily work with paper forms," while the DR plan describes how the ERP system comes back online.

Likewise, a DR plan is not an incident response plan. The incident response plan describes how you detect, contain, and analyze a security incident. The DR plan picks up where the incident response plan leaves off: the threat is contained, and now it is about recovery.

In practice, all three plans interlock. The incident response plan determines that a ransomware attack has occurred and initiates immediate measures. The DR plan describes how the encrypted systems are restored from backups. The BCP governs how business operations are maintained during recovery.

Why every organization needs a DR plan

Three driving forces make a DR plan necessary: regulatory requirements, economic reality, and increasing dependence on IT systems.

Regulatory requirements

NIS2 Article 21 explicitly requires in paragraph 2(c) "business continuity management, such as backup management and disaster recovery, and crisis management." This is not a vague recommendation but a concrete obligation for all organizations falling under NIS2.

BSI IT-Grundschutz dedicates module DER.4 (Emergency Management) to the topic. It requires, among other things, an emergency preparedness concept, an emergency manual with concrete instructions, and regular tests and exercises.

ISO 27001 addresses the topic in Annex A, Control A.5.30 (ICT readiness for business continuity). The control requires that IT readiness is planned, implemented, maintained, and tested.

Economic reality

The costs of an IT outage are higher for most organizations than they expect. A simple calculation: if a company with 100 employees generates annual revenue of 20 million euros, one day of downtime equates to roughly 55,000 euros in lost revenue. Add to that overtime costs, external service providers, contractual penalties, and reputational damage that cannot be easily quantified.

Ransomware attacks result in an average of 21 days of business interruption when no functioning DR plan exists. With a tested DR plan and clean backups, this time can be reduced to a few days.

IT dependency

Hardly any business process functions today without IT. When the ERP system fails, no orders can be processed, no invoices written, and no deliveries planned. When the email system fails, internal and external communication collapses. When Active Directory fails, nobody can log in. The question is not whether such an outage will occur, but when -- and how well you are prepared for it.

The building blocks of a DR plan

A complete DR plan consists of several sections that together form a coherent whole. Here are the essential building blocks.

1. Scope and objectives

Define which systems and locations the DR plan covers. Not every system needs the same DR plan. An internal wiki has different recovery requirements than the ERP system. Specify which scenarios the plan covers: hardware failure, ransomware, natural disasters, cloud provider outage, human error.

2. Roles and responsibilities

Name the people who will make decisions and implement measures in an emergency. Each role needs at least one deputy. The typical roles in a DR scenario are the DR coordinator (leads the recovery process, coordinates all participants), IT recovery teams (execute the technical recovery measures), the communications lead (informs executive management, employees, clients, and authorities as needed), and the escalation contact to executive management (makes decisions beyond the DR team's authority, e.g., engaging external forensic specialists).

Each role requires up-to-date contact details: mobile number, personal email address (corporate email may not work in an emergency), and weekend availability. This contact list must be available outside the affected IT systems -- printed and stored at a known location.

3. Critical systems inventory

List all IT systems covered by the DR plan and assign the following information to each:

• System name and function: e.g., "ERP system SAP Business One, order processing and accounting"
• RTO (Recovery Time Objective): Maximum tolerable downtime. How long may the system be offline at most?
• RPO (Recovery Point Objective): Maximum tolerable data loss. How many hours or minutes of data may be lost?
• Dependencies: Which other systems must be running first for this system to function? (e.g., Active Directory, DNS, database server)
• Backup location and method: Where are the backups stored and how are they created?
• Recovery procedure: Cross-reference to the detailed recovery instructions
• Responsible person: Who performs the recovery?

4. Recovery sequence

The recovery sequence is one of the most critical aspects of the DR plan and is frequently underestimated. You cannot simply restore all systems simultaneously because they depend on each other.

A typical recovery sequence for a mid-market company looks like this:

Phase 1 (Infrastructure foundation, 0-4 hours): Network infrastructure (firewalls, switches, routers), virtualization platform (VMware, Hyper-V, Proxmox), storage systems.

Phase 2 (Core services, 4-8 hours): Active Directory and DNS, DHCP, certificate authority (if applicable), monitoring system (so you can observe progress of further recovery).

Phase 3 (Business-critical applications, 8-24 hours): Database server, ERP system, email system, file server with the most important shares.

Phase 4 (Important applications, 24-48 hours): Line-of-business applications, intranet, time tracking, print server.

Phase 5 (Lower-priority systems, 48-72 hours): Development and test environments, archiving systems, non-critical services.

These time estimates are examples. Your actual times depend on the size of your environment, backup speed, and available resources.

5. Detailed recovery instructions

For each critical system, you need step-by-step instructions detailed enough that a competent IT staff member can execute them even under stress, even if they are not intimately familiar with the system. In an emergency, the person who normally manages the system may not be available.

Good recovery instructions include the prerequisites (what hardware, software, licenses, and credentials are needed), the concrete steps (with screenshots or command-line instructions), verification (how you confirm that recovery was successful), and known issues (pitfalls discovered during previous tests and their solutions).

6. Communication plan

During a disaster, various stakeholders need to be informed. The communication plan defines who is informed when, through which channel.

Executive management must be informed immediately when a DR scenario occurs. Employees need clear instructions on what to do (and what not to do). Clients must be informed when services are impacted. For personal data, the DSGVO (GDPR) notification obligation to the supervisory authority applies (72 hours). NIS2 requires an initial notification to the BSI within 24 hours.

Prepare message templates for each stakeholder group that only need to be adapted in an emergency. Under stress, important details are easily forgotten or poorly worded.

7. External service providers and contracts

Document all external service providers you may need in a DR scenario: system integrators, cloud providers, hardware suppliers, forensic service providers, attorneys with IT expertise. For each provider, record contact details (emergency hotline, not just the regular support number), contract numbers and SLA response times, the services included in the contract, and escalation paths.

Verify in advance what SLAs your providers can actually meet in an emergency. An SLA of "4-hour response time" does not mean the problem is resolved in 4 hours. It means someone will respond within 4 hours.

Creating a DR plan: step by step

Now it gets concrete. Here is how to build a DR plan from scratch.

Step 1: Business Impact Analysis (BIA) as the foundation

Before writing the DR plan, you need a Business Impact Analysis. The BIA answers the question: which business processes are how critical, and which IT systems support them?

Without a BIA, you define RTOs and RPOs in a vacuum. You do not know whether an RTO of 24 hours for the ERP system is appropriate or whether it must be 4 hours because the production process stalls without ERP access and every hour costs 10,000 euros.

The BIA does not have to be extensive. For an SME, a table with the following columns often suffices: business process, supporting IT systems, impact of outage (financial, operational, regulatory, reputational), maximum tolerable downtime, and maximum tolerable data loss.

Step 2: Inventory and prioritize IT systems

Based on the BIA, create an inventory of all IT systems and classify them by priority. A proven classification is:

Priority 1 (critical): Outage leads to significant business damage within hours. Examples: ERP, Active Directory, email, firewall.

Priority 2 (important): Outage is tolerable for 1-3 days, after which serious impairments occur. Examples: file server, time tracking, CRM.

Priority 3 (normal): Outage can be tolerated for several days to weeks. Examples: intranet, archive, test environments.

Step 3: Define RTO and RPO for each system

For each system in the inventory, define RTO and RPO. These values derive directly from the BIA. Important: RTO and RPO must be realistic. An RTO of 1 hour for a system whose bare-metal restore takes 6 hours by experience is a lie on paper. Either you invest in infrastructure that enables faster restoration (e.g., hot standby, replication), or you adjust the RTO to reality.

Step 4: Define recovery strategy per system

For each system, determine how it will be recovered. The common strategies are:

Restore from backup: The standard procedure. You restore the system from the last available backup. Suitable for systems with an RTO of several hours and an RPO matching the backup interval.

Failover to standby system: You operate a second system that replicates the primary system's data. On failure, you switch to the standby. Suitable for systems with very short RTOs (minutes to a few hours).

Cloud-based DR: You replicate your on-premises systems to the cloud (e.g., Azure Site Recovery, AWS Elastic Disaster Recovery, Zerto). On failure, you start the systems in the cloud. Suitable for organizations that do not want to operate a second location.

Reinstallation: You install the system from scratch and import data from backup. Suitable for non-critical systems whose configuration is documented or automated (e.g., via Ansible, Puppet).

Step 5: Write detailed runbooks

For each critical system, write a runbook: a step-by-step guide for recovery. The runbook must be written so that a qualified IT staff member can execute it without prior knowledge of the specific system.

A good runbook starts with a prerequisites checklist: what hardware must be available? What software media? What licenses? What credentials? Where are the backups? Then follow the concrete steps, numbered and unambiguous. Each step should be verifiable: "Start the SQL Server service and verify in SQL Server Management Studio that all databases show status 'Online.'"

Step 6: Test the plan

A DR plan that has never been tested is a hope document. Tests uncover problems nobody considered while writing: missing credentials, incompatible hardware, incorrect recovery sequence, unrealistic time estimates.

There are various test levels. Tabletop exercises (annually) are walk-through exercises where the DR team discusses a scenario without actually restoring systems. Cost: a few hours. Benefit: reveals logical errors and missing information.

Partial recovery tests (quarterly) are tests where individual systems are actually restored, typically in an isolated test environment. Cost: half a day to a full day. Benefit: verifies the technical viability of the runbooks.

Full-scale DR tests (annually) are tests where the entire infrastructure or a significant portion is restored, ideally at an alternate location or in the cloud. Cost: 1-3 days. Benefit: the ultimate proof that the DR plan works.

After each test, create a test report documenting what worked, what did not, and what corrective actions will be taken. These reports are your evidence for auditors that you take your DR plan seriously.

Step 7: Maintain the plan

A DR plan is a living document. It must be updated when the IT landscape changes (new systems, decommissioned systems, changed dependencies), when personnel changes occur (new responsible persons, changed contact details), after every test (incorporate findings), after every real incident (incorporate lessons learned), and at least annually even without a specific trigger.

Scenarios: which disasters should the DR plan cover?

A good DR plan is not limited to a single scenario. The most common scenarios you should consider are:

Ransomware attack: The most probable scenario. All or most systems are encrypted. Active Directory is compromised. Recovery first requires a clean environment (new AD or verified backup) before the remaining systems can be restored.

Hardware failure of central server/storage: A classic. A single system fails; the rest of the infrastructure is intact. Recovery occurs on replacement hardware or in a VM.

Data center / server room outage: Fire, flooding, power failure with UPS failure. All local systems are affected. Recovery must occur at an alternate location or in the cloud.

Cloud service outage: Your SaaS provider has a total outage. Here the DR plan is limited because you have no control over the provider's infrastructure. The plan describes workarounds and alternative communication channels.

Insider sabotage or human error: An employee accidentally or intentionally deletes critical data. Recovery is from backups, but you must ensure the backups themselves are not also affected.

Practical example: DR plan for a 100-employee company

Here is a realistic example of what a DR plan for a typical mid-market manufacturing company might look like.

Baseline

The company operates a VMware cluster with 15 virtual machines (Active Directory, ERP, file server, database server, line-of-business applications), Microsoft 365 for email and collaboration, an on-premise phone system (VoIP), and 100 Windows clients. Backups are stored locally on a NAS and additionally in the cloud (Wasabi S3 with Object Lock) as immutable backups.

Prioritization

Priority 1 (RTO 4h): Active Directory, DNS, firewall, ERP system, database server. Priority 2 (RTO 24h): file server, VoIP phone system, time tracking. Priority 3 (RTO 72h): intranet, development environment, print server.

Recovery strategy

In case of a ransomware attack, the company proceeds as follows: first, the incident response team isolates all affected systems from the network. Then a clean VMware environment is set up on the existing hardware (or on replacement hardware if the primary hardware is compromised). Active Directory is restored first from the last clean backup, followed by DNS and DHCP. After AD verification, the ERP system and database are restored. In parallel, Microsoft 365 can continue to be used since it is not affected by the local infrastructure.

The estimated total time for restoring Priority 1 systems is 8 to 16 hours, depending on backup size and available hardware.

Common mistakes in DR plans

The plan is too theoretical. It describes principles but no concrete steps. In an emergency, people do not need explanations of why disaster recovery matters -- they need a list of steps they can work through.

No offline copy of the plan. The DR plan resides on the file server that just went down. Or in the wiki running on the server that was just encrypted. Always keep a printed copy at a known location and store a digital copy outside the affected infrastructure (e.g., as a PDF in cloud storage or on a USB drive in the safe).

Credentials are missing or outdated. The plan refers to "the backup credentials from the password manager," but the password manager runs on the server that is currently unavailable. Keep critical credentials (backup accounts, cloud admin, firewall admin) in a sealed envelope in the safe.

The recovery sequence was never tested. On paper it sounds logical to restore AD first, then the database server, then the ERP. But during testing, it turns out the ERP requires a specific DNS configuration not included in the standard AD backup. You only discover such dependencies through testing.

No regular updates. The company migrated to a new ERP version two years ago, but the DR plan still describes the old version. The new storage system has a different snapshot logic, but the runbooks reference the old commands. An outdated DR plan is worse than no plan because it creates a false sense of security.

Underestimated time requirements. The plan allocates 2 hours for restoring the file server, but restoring 5 TB from cloud backup takes 20 hours at the available bandwidth. Measure actual restore times during tests and record them in the plan.

DR plan and regulatory requirements

BSI IT-Grundschutz

Module DER.4 (Emergency Management) requires, among other things, creating an emergency preparedness concept, defining an emergency team with clear roles, creating recovery plans for critical business processes, regular emergency exercises, and evaluating and reviewing exercises and real emergencies.

NIS2

NIS2 requires in Article 21 paragraph 2(c) measures for business continuity, including backup management and disaster recovery. The implementing regulation will likely specify more concrete requirements, but a documented and tested DR plan already fulfills the core of the requirement.

ISO 27001

Annex A, Control A.5.30, requires the planning, implementation, maintenance, and regular testing of IT readiness for business continuity. A DR plan is the central evidence for this.

Tools and templates

You do not need expensive software to create a DR plan. A structured text document (Word or Markdown) with clear sections is sufficient. The content matters more than the format.

Helpful tools for implementation include Veeam Recovery Orchestrator (automates recovery workflows and tests them regularly), Zerto (continuous replication with automated failover), Azure Site Recovery (DR to the Azure cloud), and VMware Site Recovery Manager (orchestration of DR for VMware environments).

For smaller environments, a manual process with well-documented runbooks is often sufficient. Orchestration tools pay off only above a certain environment size, typically starting at 20 to 30 virtual machines or when RTO requirements are under 2 hours.

From theory to practice

The hardest step with a DR plan is not writing it but getting started. Many organizations postpone the topic because it seems labor-intensive and there is no immediate pressure -- until an emergency strikes.

Start pragmatically: identify your five most critical systems, define RTOs and RPOs, write a runbook for each system, and test the recovery of one system. This takes days, not weeks. Then expand the plan incrementally to cover less critical systems.

An incomplete DR plan that covers the most critical systems and has been tested is infinitely more valuable than a perfect plan that was never written. In ISMS Lite, you can document your DR plan in a structured way, define RTO/RPO values per system, and log test results with auditable evidence.

Related articles

• Defining RPO and RTO Correctly: How to Find the Right Values
• Testing Bare-Metal Recovery: From Total Failure to a Running Machine
• Creating a Recovery Plan: Step-by-Step Guide to a Structured Restart
• Business Impact Analysis (BIA): Identifying Critical Processes
• Data Backup per BSI: The 3-2-1-1-0 Principle in Practice