IT disaster recovery planning guide

An IT disaster recovery plan explains how to restore technology services after disruption. It should connect business recovery needs to systems, data, people and tested procedures. A backup job marked successful does not establish that the whole service can recover.

A recovery test may reveal missing data, unavailable credentials or a dependency that takes longer to restore than expected. Record those gaps and resolve them before claiming the target can be met.

If you are an IT leader responsible for keeping systems running, this guide covers how to build an IT disaster recovery plan that can be used during an actual disaster. If you need outside support to turn that plan into an operating model, my IT management consulting is built for that kind of resilience work.

Why DR plans fail

The following problems can prevent a plan from supporting recovery.

The document problem

Most DR plans are documents. Long, detailed, meticulously formatted documents that were written once, reviewed in a committee, approved by leadership, and then filed away. They describe the infrastructure as it existed on the day they were written.

The problem is obvious: infrastructure changes constantly. New services get deployed. Old ones get retired. Cloud providers update their APIs. Staff leave and take institutional knowledge with them. Review the plan when systems, suppliers or responsibilities change, as well as on an agreed schedule.

The assumption problem

DR plans are built on assumptions. The network will be available. DNS will resolve. The backup site has enough capacity. The team will be reachable. Each assumption is reasonable in isolation. An untested dependency can prevent the recovery sequence from working.

For example, a backup site is not usable if the only access route depends on failed equipment at the primary site. Test that dependency in the design rather than assuming a second location is sufficient.

The people problem

Technical recovery procedures mean nothing if the people who need to execute them are unavailable, untrained, or overwhelmed. Disasters do not wait for convenient timing. They happen at 3 AM on a bank holiday weekend when your lead engineer is on a flight to Tenerife.

As I discussed in my post on lessons from major IT incidents in 2025, people and coordination affect recovery alongside the technical design. Technical systems can be designed for resilience. People need training, cover and support.

Building and testing a DR plan

A working disaster recovery plan combines documented procedures with people and systems able to execute them.

Step 1: define what matters

Start with a business impact assessment. Agree the recovery time objective, or RTO, which is the target time to restore the service, and recovery point objective, or RPO, which describes the tolerable data-loss period. The tier labels and numbers below are illustrative, not universal requirements. Validate targets against operational needs, dependencies and cost.

Tier 1 - Critical: Systems where downtime directly costs revenue or creates legal exposure. Payment processing, customer-facing applications, authentication services. Recovery time objective (RTO): under one hour. Recovery point objective (RPO): near zero.

Tier 2 - Important: Systems that significantly impact operations but have workarounds. Email, internal tools, reporting systems. RTO: four to eight hours. RPO: up to four hours.

Tier 3 - Standard: Systems that support normal operations but can tolerate extended outages. Development environments, internal wikis, non-critical batch jobs. RTO: 24 to 48 hours. RPO: up to 24 hours.

Tier 4 - Low priority: Everything else. Archive systems, legacy tools, training environments. Recover when possible.

This classification exercise is more valuable than most people realise. It forces difficult conversations about what the business actually needs versus what people assume they need. If nearly every system receives the highest priority, ask business owners to compare the consequences of delayed recovery and identify the genuine dependencies.

Step 2: map your dependencies

Every system depends on other systems. Your web application needs a database. The database needs storage. Storage needs networking. Network services may depend on DNS. Record each dependency rather than stopping at the application.

Draw these dependency maps explicitly. Include external dependencies such as cloud providers, SaaS tools, payment processors and CDNs. These are the things most DR plans forget because they feel like someone else's problem.

Pay special attention to shared dependencies. If your Tier 1 application and your monitoring system both depend on the same DNS provider, you will lose visibility at exactly the moment you need it most.

Step 3: design for recovery, not just resilience

Resilience includes the ability to withstand, adapt to and recover from disruption. Redundancy and availability controls can reduce some failures; recovery procedures address what happens when services or data must be restored. Assess both against the business requirement.

For each tier, define specific recovery procedures:

• A recovery method that meets the agreed target for critical systems. Automatic failover may help, but a tested manual method can be appropriate. Consider split-brain, replicated corruption, safety and the authority to fail over.
• Documented manual procedures for Tier 2. Step-by-step runbooks that a competent engineer who has never seen the system before can follow.
• Rebuild procedures for Tier 3 and below. Infrastructure as code, configuration management, and tested restoration scripts.

The key principle from boring IT infrastructure applies here: use proven, well-understood recovery mechanisms. Your DR plan is not the place to experiment with cutting-edge technology.

Step 4: automate bounded, tested recovery actions

Manual work can fail under pressure, while an automated defect can repeat the wrong action quickly. Choose automation where it can be tested and observed, and retain a usable fallback.

Consider the following recovery capabilities:

• Infrastructure as code for rebuilding environments. Use a suitable tool such as Terraform, CloudFormation or Pulumi.
• Automated backup verification. Do not just check that backups completed. Restore them regularly and verify the data is intact.
• Controlled failover testing. Start in an isolated representative environment. Define expected behaviour, data checks, rollback and abort conditions. A production exercise needs explicit change approval, a supported maintenance window and accountable business owners.
• Runbook automation. Where scripts support a procedure, test their inputs, permissions, failure reporting and rollback. Dry-run flags can help preview actions but do not replace an exercised recovery procedure.

Review both manual and automated steps for errors, hidden dependencies and missing evidence.

Step 5: test relentlessly

Set an exercise schedule from criticality, changes and previous failures. Testing should continue as the service changes.

Tabletop exercises (for example quarterly where risk justifies it): Walk through scenarios with your team. No actual systems involved. Focus on decision-making, communication, and identifying gaps in the plan. These are cheap and surprisingly effective.

Component testing (at a risk-based frequency): Test individual recovery procedures. Restore a backup. Fail over a database. Spin up infrastructure from code. Verify each building block works in isolation.

End-to-end recovery exercises: Restore a representative service and its dependencies into an isolated environment, using approved test data or protected copies. Prevent restored systems sending live messages, taking payments or writing to production. Test the business workflow and record elapsed time and data loss against the targets.

Production failover exercises: Use only when justified and formally approved. Specify the affected services, customer impact, staffing, rollback, abort thresholds and decision authority. Confirm that backups and the rollback route have been tested before the exercise. A lab result does not prove every production dependency, but an unapproved production failure is not a responsible substitute.

Fault-injection exercises: These require a defined hypothesis, bounded targets and monitoring. Do not terminate random instances or introduce failures into production merely to create a test. Begin in a non-production environment and stop when an abort condition is met.

These are planning recommendations. NIST's contingency planning guide provides a broader framework for determining recovery requirements and priorities; it is US federal guidance, not a UK statutory requirement.

Step 6: document for humans, not auditors

Your DR documentation should be written for the person executing it at 3 AM after being woken by a PagerDuty alert. That means:

• Short sentences. Clear instructions. No ambiguity.
• Screenshots and diagrams where they help. A network diagram is worth a thousand words when you are trying to understand traffic flow during an outage.
• Decision trees, not novels. If X, do Y. If Z, do W. Make the next action obvious.
• Contact lists with multiple channels. Phone numbers, not just Slack handles. People do not always have laptop access during an emergency.
• Control document versions. Use a system with change history, access control and an offline recovery copy. Check that responders can reach it when normal identity or collaboration services fail.

Step 7: plan for communication

Technical recovery also needs a communication plan. During a major incident, you also need to communicate with stakeholders, customers, regulators, and the press. Your DR plan should include:

• Internal communication templates. Pre-written messages for different severity levels that can be quickly customised and sent.
• External communication procedures. Who authorises public statements? What channels do you use? Which reporting duties apply to this organisation, and who tracks them? Do not assume that every outage or every SME has the same regulatory obligations.
• Status page management. If you have a public status page, who updates it? How often? What level of detail is appropriate?

Report what is known, what remains uncertain and when the next update is due. Keep technical recovery and notification assessment running in parallel.

The cloud does not solve this

A common misconception is that moving to the cloud eliminates the need for disaster recovery planning. It does not. It changes the nature of the risks, but it does not remove them.

Cloud providers offer remarkable infrastructure resilience, but they cannot protect you from:

• Application-level failures. A data corruption event may replicate to a secondary region if replication copies the affected changes.
• Configuration errors. An identity policy change may affect access across regions, depending on its scope.
• Provider-wide disruption. Consider a scenario where shared provider services or control-plane access affect more than one region. Check which dependencies your design actually separates.
• Account-level issues. Billing disputes, compliance holds, or compromised credentials can affect your entire cloud presence.

Assess the risk of provider or account loss against your business requirements. Independent backups or a second provider can help, but cross-provider recovery adds complexity and must be tested. This does not necessarily mean multi-cloud (which brings its own complexity). It might mean having critical data backed up to a different provider, or maintaining the ability to rebuild core services on alternative infrastructure.

What good looks like

Use these checks to assess the programme:

• Recovery is tested more often than it is documented. The team knows how to recover because they practice regularly, not because they read a runbook.
• Recovery time is measured, not estimated. Actual recovery times from tests are tracked and reported. Targets are adjusted based on reality, not wishful thinking.
• The plan evolves with the infrastructure. DR documentation is updated as part of the change management process, not as a separate annual exercise.
• Everyone knows their role. Not just the infrastructure team. Developers, product managers, communications staff. Everyone involved in incident response has a defined role and has practiced it.
• Leadership is engaged. DR is a board-level concern, not just an IT problem. Budget for testing is protected. Recovery targets are aligned with business risk appetite.

Getting started

If your current DR plan is a dusty document that has not been tested in over a year, here is where to start:

1. Run a tabletop exercise this month. Pick a realistic scenario (ransomware attack, cloud provider outage, data centre fire) and walk through your response with your team. Document every gap you find.
2. Test one backup restoration this week. Pick a critical system and restore it in an approved isolated environment. Prevent production writes and messages, time recovery, verify the data and compare the result with the RTO and RPO.
3. Update your contact list today. Check every phone number, every email address, every escalation path. Remove people who have left. Add people who have joined.
4. Schedule regular testing. Set frequency from criticality and material change, with owners and resources. Include both discussion and isolated technical tests, and retest failed actions.

The plan needs tested recovery procedures, current contacts and agreed responsibilities.

Schedule the next recovery test and assign someone to close the gaps it identifies.

---

If you need help designing or stress-testing your disaster recovery plan, my IT project management service covers resilience planning and programme delivery, and my IT management consulting can help you build the operating model around it. Book a consultation with your recovery targets, dependency map and latest test results. We can identify the first safe exercise and the gaps that stop the service meeting its target.

Turn a failed test into a decision

In a hypothetical exercise, restoring an order database takes two hours but rebuilding the application and validating stock data takes another four. A four-hour RTO has therefore failed even though the database restore succeeded. The service owner can fund automation or capacity to close the gap, change the recovery design, or formally accept a revised target after assessing the business impact. Record the decision and repeat the full workflow test. Do not report the two-hour database result as service recovery.