Creating an IT Disaster Recovery Strategy: From Document to Capability

Many organisations have a disaster recovery plan. Far fewer have a disaster recovery strategy, and the difference between the two can become visible at the worst possible moment.

The typical pattern looks like this: a plan is written, often to satisfy an audit, an insurer, or a customer questionnaire. It's saved as a PDF, circulated once, and left behind as the environment it describes changes around it. Cloud workloads are migrated, SaaS tools are adopted, people move on. Two years later, the document still exists, but the capability it describes no longer does.

This isn’t a hypothetical risk. According to the DSIT Cyber Security Breaches Survey 2025, only 57% of medium-sized businesses and 76% of large businesses have a formal incident response plan at all - and having a document is only the first step towards having a working capability. 

Modern IT environments can make this risk spread wider. Hybrid infrastructure, SaaS dependencies, and distributed workforces mean that recovery needs to span multiple environments with different responsibilities and mechanisms - complexity that a static document written for a single server room or cloud platform was never designed to handle. This guide sets out how to build a disaster recovery strategy that reflects how your organisation operates, drawing on our experience as a disaster recovery services provider designing and testing recovery for organisations including those in finance, legal, and professional services. 

Strategy, plan, or runbook? Why the distinction matters 

These three terms are often used interchangeably, and that confusion could be the root of failed recoveries. They are different layers, each answering a different question: 

• A strategy defines recovery priorities and architecture principles. Which services matter most? How much downtime and data loss can the business tolerate? Where does recovery happen, and who is responsible for it? The strategy is a set of decisions. 

• A plan defines execution steps. Given those decisions, what is the sequence of actions that restores service - which systems, in which order, with which dependencies? 
• Runbooks define technical procedures. The specific, step-by-step instructions an engineer follows at 2 AM: commands, credential locations, configuration values, validation checks. 

An organisation with runbooks but no strategy can recover systems in the wrong order. An organisation with a strategy but no runbooks knows what matters but can’t execute under pressure. Effective disaster recovery planning builds all three layers in this order, because the strategy determines what the plan and runbooks need to contain. 

Step 1: Identify technical dependencies

Recovery rarely fails because the primary system couldn’t be restored. It typically fails because something the primary system depends on was overlooked. Before defining objectives or architecture, map what your critical services rely on:

• Application tiers: which applications are mission-critical, business-important, or non-critical? Tiering determines recovery order and the level of investment each system justifies. 

• Identity and authentication: Microsoft Entra ID and SSO platforms underpin access to almost everything else. If identity isn’t recovered correctly, users can’t log in to systems that are otherwise fully restored - our guide to disaster recovery and identity explores why this is so frequently underestimated. 
• DNS and networking: firewall rules, routing, VPN access, and DNS configuration determine whether a recovered environment is reachable. 
• Third-party integrations: payment gateways, APIs, and data feeds that your applications call. If a dependency is unavailable or unreachable from the recovery environment, the application cannot function. 
• SaaS dependencies: platforms such as Microsoft 365 sit under a shared responsibility model - the provider runs the platform, but data recovery can often remain your responsibility. 
• Cloud-native services: managed databases, storage accounts, and serverless components that exist as configuration rather than as servers. These are easy to miss in an inventory built around virtual machines. 
• Suppliers and supply chains: services your operation depends on that sit entirely outside your infrastructure, from logistics platforms to outsourced payroll. 

Many organisations only discover these dependencies during a failed recovery test. Mapping them deliberately, before an incident, is what separates a strategy from a document. 

Step 2: Define recovery objectives

With dependencies mapped, the next decision is how quickly each service needs to return, and how much data loss is tolerable. These are your Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) - and they are business decisions, not technical ones, because they define how much revenue, productivity, and customer trust the organisation is prepared to put at risk. 

Three decisions matter at this stage:

• Recovery time expectations: how long can each service be down before the impact becomes unacceptable? 
• Data loss tolerance: how much data can each system afford to lose? A transactional finance platform and an internal wiki have very different answers. 
• Service restoration order: when everything is down, what comes back first? This sequence should follow business impact and dependency chains, not convenience. 

Setting these targets properly deserves its own discussion - our guide to RPO and RTO covers how to define them and the commercial trade-offs involved in detail. 

Step 3: Define recovery environments

Your strategy must state where recovery occurs and how that environment is protected from whatever caused production to go down. Options include: 

• Secondary data centres: physically separate replicated infrastructure, operated in-house or through a colocation provider. 
• Cloud failover: recovery into a public or private cloud environment, with compute activated on demand. 
• Hybrid failover models: a combination of the two, matched to workload types and recovery objectives. 

Wherever recovery happens, three design principles apply. Network segmentation prevents an incident in production - particularly ransomware - from reaching the recovery environment. Identity separation gives the recovery environment its own administrative accounts and access paths, so compromised production credentials carry no authority there. Secure access defines how engineers reach the recovery environment when normal access methods may be unavailable - a detail that’s easy to overlook and painful to improvise.

Step 4: Plan for the human factor

Technology recovers systems; people recover businesses. Under the pressure of a live incident - often out of hours, often with incomplete information - human factors determine whether a technically sound strategy can be executed. Your strategy should address: 

• Runbook clarity: procedures written so that a competent engineer who didn’t build the system can follow them. If a recovery depends on one person’s knowledge, that person is a single point of failure. 
• Role clarity during an incident: who declares the incident, who leads recovery, who communicates with the business, who talks to customers? Ambiguity here can cost hours. 
• Escalation path validation: who has the authority to make significant decisions - to fail over, to engage a provider, to accept data loss? Document it and confirm the named people know. 
• Third-party coordination: how and when providers, suppliers, and (where relevant) insurers or regulators are engaged, with contact routes that work when internal systems are down. 

Step 5: Build the recovery runbooks

With the strategy defined, runbooks turn it into an executable procedure. A complete runbook set typically includes: 

• Technical runbooks: step-by-step recovery procedures per system, including validation checks that confirm the service is working - not just powered on.
• Contact trees: who to call, in what order, with alternatives - stored somewhere accessible when production systems are unavailable. 
• Communication plans: pre-agreed templates and channels for updating staff, customers, and partners during an incident. 
• Incident declaration criteria: the defined thresholds at which an issue becomes a disaster, and the recovery process formally begins. Without them, organisations lose critical time debating whether to act. 

Common mistakes to avoid

• Designing DR around infrastructure instead of services: the business doesn’t need servers back; it needs services back. Recovery should be defined in terms of what users can do, not what’s powered on. 
• Ignoring application dependencies: restoring an application without its database, API connections, or authentication service restores nothing usable. 
• Underestimating identity systems: a common cause of stalled recoveries is when the infrastructure is back online, but nobody is able to log in. 
• Not budgeting for cloud failover capacity: recovery compute, storage, and potential egress costs need to be planned and funded before the incident, not discovered during it. 
• Treating DR as a one-time project: a strategy written once and never revisited can drift away from the environment it protects. 
• Failing to document escalation authority: if nobody is sure who can authorise failover, the decision waits and downtime accumulates while it does. 
• Overcomplicating: a strategy nobody can follow under pressure is as risky as no strategy. Clarity beats completeness. 

A strategy is only proven when it’s tested 

Everything above can help produce a well-designed strategy on paper. What turns it into a capability is validation - structured testing that proves recovery targets can actually be met, repeated as your environment changes. An untested strategy is an assumption; a tested one provides evidence. 

How often that testing should happen depends on your risk profile and how quickly your environment changes - our guide to how often you should test your disaster recovery strategy covers this in detail. The strategy itself should also be reviewed on a defined schedule and whenever significant change occurs: cloud migrations, major application deployments, organisational restructuring, or shifts in the threat landscape. 

At DCS, we help organisations build disaster recovery strategies that are designed and tested to perform under real-world conditions. As a UK-based, engineer-led cloud and cyber resilience provider, we support every stage of this process - from dependency mapping and objective setting through to recovery architecture, testing, and ongoing validation - so that your strategy is a proven capability rather than a document on a shelf.