IT Disaster Recovery Plan Guide for Real-World Recovery

Every IT leader has a disaster recovery plan. Most of them do not work. That is not cynicism - it is what the data tells us. Industry research consistently shows that over 70% of organisations that test their DR plans discover critical gaps. Recovery times exceed targets. Backups turn out to be incomplete. Runbooks reference systems that were decommissioned months ago.

I have been through enough real incidents to know that the gap between a DR plan document and actual recovery capability is often enormous. The plan says four hours. Reality says four days. The plan says failover is automatic. Reality says someone needs to SSH into a server that nobody has credentials for any more.

If you are an IT leader responsible for keeping systems running, this guide covers how to build an IT disaster recovery plan that survives contact with an actual disaster.

Why most DR plans fail

Before building something better, it is worth understanding why existing plans fall short. The patterns are remarkably consistent across organisations of all sizes.

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. Within six months of writing, most DR plans are already partially obsolete.

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. Stack them together and you have a house of cards.

I learned this the hard way early in my career when a data centre power failure also took out the network equipment we needed to reach our backup site. The DR plan assumed network connectivity. Nobody had questioned that assumption because it seemed so fundamental.

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, the human factor is consistently the biggest variable in incident recovery. Technical systems can be designed for resilience. People cannot be patched.

Building a DR plan that actually works

A working disaster recovery plan is not a document. It is a capability. Here is how to build one.

Step 1: Define what matters

Not everything needs the same level of protection. Start by classifying your systems into tiers based on business impact.

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. I have seen organisations classify 80% of their systems as Tier 1, which means nothing is truly prioritised.

Step 2: Map your dependencies

Every system depends on other systems. Your web application needs a database. The database needs storage. Storage needs networking. Networking needs DNS. DNS needs... you get the picture.

Draw these dependency maps explicitly. Include external dependencies - cloud providers, SaaS tools, payment processors, 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 and recovery are different things. Resilience is about preventing failures. Recovery is about what happens when prevention fails. You need both, but most organisations over-invest in resilience and under-invest in recovery.

For each tier, define specific recovery procedures:

• Automated failover for Tier 1 systems. If it requires human intervention to fail over, it is not truly Tier 1 ready.
• 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 everything you can

Manual recovery procedures are unreliable. People make mistakes under pressure. They skip steps. They misread instructions. They type the wrong server name.

Automate your recovery procedures wherever possible:

• Infrastructure as code for rebuilding environments. Terraform, CloudFormation, Pulumi - pick your tool and commit to it.
• Automated backup verification. Do not just check that backups completed. Restore them regularly and verify the data is intact.
• Automated failover testing. If your database cluster claims to support automatic failover, prove it. Regularly. In production.
• Runbook automation. Tools like Rundeck or even well-written shell scripts with dry-run flags are better than Word documents.

Every manual step in your recovery process is a potential point of failure. Reduce them ruthlessly.

Step 5: Test relentlessly

This is where most organisations fail. They write the plan, maybe test it once, declare success, and move on. Testing is not a one-off activity. It is an ongoing programme.

Tabletop exercises (quarterly): 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 (monthly): Test individual recovery procedures. Restore a backup. Fail over a database. Spin up infrastructure from code. Verify each building block works in isolation.

Full DR tests (biannually): Execute a complete recovery scenario. Ideally, this means actually failing over to your backup site and running production workloads from there. This is expensive and disruptive, which is exactly why most organisations skip it. Do it anyway.

Chaos engineering (ongoing): For mature organisations, introduce controlled failures into production. Netflix's Chaos Monkey is the famous example, but you do not need to start there. Simply terminating a random non-critical instance once a week teaches your team and your systems to handle failure gracefully.

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.
• Version control your documentation. Use Git, not SharePoint. Track changes. Review regularly.

Step 7: Plan for communication

Technical recovery is only half the battle. 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? How quickly must you notify regulators under GDPR or NIS2?
• Status page management. If you have a public status page, who updates it? How often? What level of detail is appropriate?

Communication failures during incidents cause more lasting damage than the technical issues themselves. A well-handled outage builds trust. A poorly communicated one destroys it.

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 bug that corrupts data in your primary region will replicate to your secondary region.
• Configuration errors. An IAM policy change that locks you out of your own account works across all regions simultaneously.
• Vendor outages. AWS, Azure, and GCP all have multi-region outages. They are rare but they happen.
• Account-level issues. Billing disputes, compliance holds, or compromised credentials can affect your entire cloud presence.

Your cloud DR strategy should include the ability to operate independently of any single provider, at least for Tier 1 services. 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

The best DR programmes I have seen share common characteristics:

• 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 from backup. Time it. Verify the data. Compare the actual time to your documented RTO.
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. Put it in the calendar. Quarterly tabletops, monthly component tests, biannual full tests. Treat these with the same priority as production deployments.

Disaster recovery planning is not glamorous work. It does not feature in vendor keynotes or industry hype cycles. But when something goes wrong - and it will - the organisations that invested in genuine recovery capability are the ones that survive.

The best time to test your DR plan was six months ago. The second best time is this week.