IT Disaster Recovery Plan Guide

An IT disaster recovery plan describes how an organisation restores the systems and data it depends on after a serious disruption: a cloud region outage, a ransomware attack, a corrupted database, a failed deployment or a physical disaster. Almost every security and resilience framework expects one, but each describes it in its own vocabulary. ISO talks about ICT readiness and business continuity, NIST about contingency planning, SOC 2 about availability, HIPAA about contingency plans, DORA about ICT business continuity, and Indian regulators about DR drills.

Underneath, the expectations are remarkably consistent. This guide explains the core concepts of RTO, RPO and MTD, how to design backups and failover that survive modern threats, how to test recovery, and what major frameworks and regulators specifically require, so you can build one plan that satisfies them all.

What is IT disaster recovery?

Disaster recovery (DR) is the part of business continuity that deals with restoring technology. Business continuity asks how the organisation keeps delivering critical services during disruption; disaster recovery asks how the systems and data behind those services are brought back. A DR plan contains the recovery objectives, strategies, procedures, roles and test arrangements for that technology.

DR is not the same as high availability. High availability keeps a system running through component failures, for example by running across availability zones. DR deals with larger or different events, such as losing a whole region, an account compromise or data corruption that replicates everywhere. A good design uses both.

Key concepts: MTD, RTO, RPO and WRT

Term	Meaning	Example
Maximum tolerable downtime (MTD)	How long a business process can be disrupted before unacceptable harm	Online checkout can be down for 8 hours
Recovery time objective (RTO)	How long a system can be unavailable	Checkout system restored within 4 hours
Recovery point objective (RPO)	How much data loss is acceptable, measured in time	No more than 15 minutes of orders lost
Work recovery time (WRT)	Time after restoration to verify data and resume work	2 hours to reconcile orders and payments

RTO plus WRT must fit within the MTD. RPO drives backup and replication frequency. These terms come from NIST SP 800-34 and are widely used; ISO 22301 uses related concepts such as the maximum tolerable period of disruption and the minimum business continuity objective.

Step 1: business impact analysis

Every framework starts with understanding impact. A business impact analysis (BIA) identifies critical processes, the systems they depend on, the impact of disruption over time, and acceptable downtime and data loss. Without it, recovery targets are guesses. The BIA should involve business owners, not only IT, and be updated when products, customers or contracts change. Contractual SLAs and regulatory requirements, such as a regulator's two-hour RTO, set minimums that the BIA must respect.

Step 2: map dependencies

Systems rarely recover alone. Map each critical service's dependencies: databases, storage, identity providers, DNS, certificates, secrets, message queues, third-party APIs, payment gateways and support tools. Recovery order follows dependencies; restoring an application before its identity provider achieves nothing. Supplier dependencies need contractual recovery commitments or alternatives.

Step 3: design backups that survive

Frequency matched to RPO: continuous replication or point-in-time recovery for low RPOs, scheduled backups for higher ones.
The 3-2-1 principle: at least three copies, on two different types of storage, with one off-site. Many teams now add one immutable or offline copy and verify zero errors on restore.
Immutability: backups that cannot be altered or deleted for a retention period, even by administrators, to resist ransomware.
Separation: backups in a separate account, subscription or tenant with separate credentials.
Encryption: at rest and in transit, with keys recoverable independently of the primary environment.
Coverage: databases, file storage, configuration, infrastructure code, secrets and identity configuration, not just application data.
Retention: long enough to restore from before an undetected compromise or corruption.

Step 4: choose recovery strategies

Strategy	Typical RTO	Cost	When to use
Backup and restore	Hours to days	Low	Non-critical systems, long RTO
Pilot light	Hours	Low to medium	Core data replicated, compute started on demand
Warm standby	Minutes to hours	Medium	Scaled-down copy running in another region
Active-active	Near zero	High	Critical services with very low RTO and RPO

Infrastructure as code makes every strategy faster and more reliable, because environments can be rebuilt consistently. The choice should be driven by the BIA and cost, not by habit.

Step 5: plan for ransomware and corruption

Ransomware and destructive attacks are now the most likely reason to invoke DR. They differ from physical disasters: the attacker may have administrator credentials, may have been inside for weeks, and may target backups first. Plans should include isolating affected systems, identifying a clean restore point, rebuilding from known-good images and code rather than restoring compromised servers, rotating credentials, and validating integrity before returning to service. Replication alone does not protect against corruption or encryption, since it copies the damage.

Step 6: write recovery procedures

A DR plan needs actionable runbooks: activation criteria and who decides, notification lists, step-by-step recovery for each system in dependency order, validation checks, communication templates, and how to return to normal operations. Automate steps where possible and keep manual fallbacks. Store plans where they are reachable when primary systems, email and chat are down.

Roles and communication during a disaster

Technology recovery fails surprisingly often for human reasons: nobody is sure who can declare a disaster, the person with the credentials is on leave, or customers hear about the outage from social media first. A DR plan should name an incident commander who can activate the plan, technical leads for each recovery area, a communications lead for customers, staff and regulators, and alternates for each role. It should include contact details that do not depend on company email or chat, pre-approved message templates, and the regulatory and contractual notification deadlines that may apply, such as six-hour incident reporting in India or customer notice clauses in SLAs. Practising these roles in tabletop exercises is as important as testing the technology.

Step 7: test, learn and improve

Restore tests: regularly restore backups and verify data, not just job success.
Tabletop exercises: walk through scenarios with decision makers.
Component tests: fail over a database or service.
Full failover drills: run production from the DR environment for a period.
Cyber scenarios: rehearse ransomware recovery with clean rebuilds.

Record actual recovery times against RTO and RPO, document issues and fix them before the next test. Vary scenarios from test to test, so the team does not only rehearse the easiest case.

What major frameworks and regulators expect

Framework or rule	DR expectations
ISO 22301	BIA, risk assessment, continuity strategies and solutions, plans, exercising and testing, and evaluation within a certified management system.
ISO/IEC 27001:2022	Controls for information security during disruption (5.29), ICT readiness for business continuity (5.30), information backup (8.13) and redundancy of facilities (8.14).
ISO/IEC 27031	Guidance on ICT recovery objectives, strategies, plans and testing.
NIST SP 800-34 and SP 800-53 CP controls	Seven-step contingency planning, BIA, backups (CP-9), recovery and reconstitution (CP-10), alternate sites and plan testing (CP-4).
SOC 2	Availability criteria covering environmental protections, backups and recovery infrastructure, and testing of recovery plan procedures.
HIPAA Security Rule	Contingency plan standard with data backup, disaster recovery and emergency mode operation plans required, and testing and criticality analysis as addressable specifications.
PCI DSS	Incident response plan covering business recovery and continuity procedures, and backup of critical data.
DORA	ICT business continuity policy, response and recovery plans, backup policies and restoration methods, and at least annual testing for financial entities in the EU.
RBI 2026 directions	ITSC-approved RTO and near-zero RPO for critical systems; DR drills at least half-yearly that switch to the DR site.
SEBI CSCRF	Declare a disaster within 30 minutes of critical system disruption; RTO of two hours and RPO of 15 minutes for critical operations.

Is disaster recovery mandatory?

No single law applies everywhere, but DR is effectively mandatory for organisations covered by HIPAA, DORA, RBI or SEBI rules, those certified to ISO 22301 or ISO/IEC 27001, those with SOC 2 availability commitments, and those with contractual uptime and recovery obligations. For everyone else, it is a basic expectation of customers and insurers.

Cloud and SaaS considerations

Shared responsibility: the cloud provider protects its infrastructure; you are responsible for your data, configuration and recovery design.
Regions and accounts: plan for losing a region and for losing access to an account through compromise.
Data residency: DR copies must respect localisation rules, such as keeping Indian payment data and SEBI-regulated data in India.
SaaS dependencies: export data from critical SaaS tools and know how you would operate if they failed.
Customer commitments: SaaS providers should publish RTO and RPO they can evidence through tests.

Measuring DR readiness

A few metrics show whether a DR programme is real. Track the percentage of critical systems with a tested recovery in the last six or twelve months, actual recovery times in tests against RTO, actual data loss against RPO, backup success and restore test success rates, replication lag, time since the plan was last reviewed, and the number of open findings from the last test. Reporting these to leadership turns DR from a document into an operational capability with clear owners.

Disaster recovery for small teams

Small companies and startups cannot run active-active systems everywhere, and they do not need to. A practical baseline is managed database backups with point-in-time recovery, a copy of backups in a separate account, infrastructure defined as code, a short runbook for restoring into a new region, and a restore test every quarter. Add a simple BIA conversation with the founders to agree which systems matter most, and a one-page communication plan. This modest setup answers most customer security questionnaires and forms the foundation for ISO, SOC 2 or regulatory requirements later.

Documentation you will need

BIA with MTD, RTO and RPO per service.
Dependency maps and supplier commitments.
Backup policy, schedules and retention.
Recovery strategy decisions.
DR plan and runbooks.
Test plans, results, actual recovery times and remediation.
Management review records.

Common mistakes

Backups never restored.
RTOs nobody can meet because they were never tested.
Backups in the same account as production, reachable by attackers.
Forgetting configuration, secrets and identity in backups.
DR copies outside required jurisdictions.
Plans stored only on systems that fail in the disaster.

Best practices, tools and technologies

Manage infrastructure as code and test rebuilding environments from scratch.
Use managed backup services with immutability and cross-account copies.
Monitor replication lag and backup success against RPO.
Automate failover where RTO demands it, with human approval for activation.
Run game days at least twice a year for critical services.
Track recovery metrics as key risk indicators for leadership.

We set up multi-region backups, infrastructure as code and failover runbooks, then run recovery drills and record results, through our maintenance and support and migration and modernisation services.

Real-world example

An Indian SaaS company serving banks and healthcare clients in India, the EU and the US builds one DR programme. Its BIA sets a two-hour RTO and 15-minute RPO for its core platform, matching the strictest client requirement. It runs active replication to a second Indian region for Indian data and a second EU region for EU data, keeps immutable backups in separate accounts, rebuilds environments from code, and runs half-yearly failover drills and quarterly restore tests. One set of evidence supports its ISO/IEC 27001 and ISO 22301 audits, its SOC 2 availability criteria, and its clients' RBI and DORA vendor assessments.

Next steps

Run or refresh the BIA.
Map dependencies and suppliers.
Protect backups with immutability and separation.
Write runbooks and automate where possible.
Test, record results and improve.

Frequently asked questions

What is the difference between RTO and RPO?

RTO is how quickly a system must be restored; RPO is how much data, measured in time, you can afford to lose.

What is the difference between disaster recovery and business continuity?

Business continuity keeps critical activities going; disaster recovery restores the technology they depend on.

How often should DR be tested?

At least annually for most systems; some regulators, such as RBI for critical systems, require half-yearly drills, and restore tests should be more frequent.

Is replication enough for disaster recovery?

No. Replication copies corruption and encryption too; you also need protected, point-in-time backups.

What is the 3-2-1 backup rule?

Keep at least three copies of data on two types of storage with one copy off-site, ideally plus an immutable copy.

Does SOC 2 require disaster recovery?

The availability criteria cover backups, recovery infrastructure and testing; they apply if availability is in scope.

Does HIPAA require a disaster recovery plan?

Yes. The contingency plan standard requires data backup, disaster recovery and emergency mode operation plans.

What RTO does SEBI require?

Two hours for critical operations, with a 15-minute RPO, under the CSCRF.

Can DR copies be stored in another country?

Only where rules allow; Indian payment data and some regulated data must remain in India.

How do I recover from ransomware?

Isolate systems, find a clean restore point, rebuild from known-good images and code, rotate credentials, and validate before returning to service.

Who should set RTO and RPO?

Business owners, informed by the BIA, contracts and regulations, with IT confirming feasibility and cost.

Is high availability the same as disaster recovery?

No. High availability keeps systems running through component failures; disaster recovery restores them after larger events such as region loss, compromise or corruption.

What should a DR plan contain?

Recovery objectives, roles, activation criteria, contact lists, step-by-step runbooks in dependency order, validation checks, communication templates and test arrangements.