Disaster Recovery Plan Template

A disaster recovery (DR) plan is a documented, structured approach for responding to unplanned incidents that threaten your IT infrastructure. Whether it is a ransomware attack, a hardware failure, a natural disaster, or a simple human error, having a plan means the difference between hours of downtime and days of chaos. Use this template as a framework to build your own plan.

Section 1: Plan Overview and Scope

Define what this plan covers and what it does not. Be specific about boundaries.

• Purpose statement: Why this plan exists and what it aims to achieve (e.g., restore critical business operations within defined timeframes following a disruptive event)
• Scope: Which systems, locations, and business functions are covered. If certain departments or satellite offices are excluded, state that explicitly.
• Plan owner: Name and title of the person responsible for maintaining this document
• Last reviewed: Date of last review. Plans should be reviewed at least annually or after any major infrastructure change.
• Distribution list: Who has access to this plan and where copies are stored (including offline copies)

Section 2: Recovery Team Roles and Responsibilities

During a disaster, people need to know exactly what they are responsible for. Ambiguity causes delays.

• DR Coordinator: Leads the overall recovery effort, makes go/no-go decisions, communicates with executive leadership
• IT Recovery Lead: Manages the technical recovery process, directs the IT team, and reports status to the DR Coordinator
• Communications Lead: Handles all internal and external communications, including employee updates, customer notifications, and media inquiries
• Department Leads: Each business unit should have a designated contact who can verify that their systems and data are recovered correctly
• Vendor Liaison: Manages communication with third-party vendors, MSPs, and cloud providers during the incident

For each role, document: the primary person, a backup person, phone numbers, personal email addresses (not company email, which may be unavailable during a disaster), and any special access credentials they need.

Section 3: Emergency Contact List

Maintain a current contact list that is accessible even when your primary systems are down.

• All DR team members (primary and backup) with personal cell phones and personal email
• Executive leadership team
• IT managed service provider (MSP) emergency line
• Internet service provider support number and account ID
• Cloud provider support contacts and account numbers
• Insurance company and policy number
• Legal counsel
• Key customers or partners who need to be notified
• Building management and facilities

Print this list and keep physical copies in at least two locations. Store a digital copy in a personal cloud account accessible from any device.

Section 4: System and Data Inventory

List every critical system with the information needed to recover it.

For each system, document:

• System name and description
• Business function it supports
• Priority tier (critical, important, or deferrable)
• Recovery Time Objective (RTO): how quickly it must be restored
• Recovery Point Objective (RPO): how much data loss is acceptable
• Backup method and location
• Dependencies (other systems, databases, network services)
• Vendor and support contact information
• Recovery procedure reference (which runbook to follow)

Section 5: Recovery Procedures

This is the core of the plan. For each priority tier, document step-by-step recovery procedures.

1. Tier 1 - Critical Systems (recover within RTO): These are systems that must be restored first. Examples: email, EHR/EMR, core line-of-business applications, Active Directory, VPN.
   • Step-by-step restore procedures from backup
   • Verification steps to confirm the system is working correctly
   • Fallback procedures if the primary restore method fails
2. Tier 2 - Important Systems (recover within 24-48 hours): Examples: file shares, secondary applications, reporting systems.
   • Same documentation structure as Tier 1
3. Tier 3 - Deferrable Systems (recover within one week): Examples: development environments, archived data, non-essential internal tools.
   • Same documentation structure as Tier 1

Section 6: Communication Plan

Communication during a disaster needs to be planned in advance. Panicked, inconsistent messaging makes a bad situation worse.

• Internal communications: How will you notify employees? If email is down, what is the backup channel? (Group text, phone tree, messaging app, physical meeting point)
• Customer communications: Pre-draft template messages for common scenarios. Include who approves customer-facing communications.
• Regulatory notifications: If you handle PHI or other regulated data, document the breach notification requirements and timelines (HIPAA requires notification within 60 days of discovery).
• Status update cadence: Define how often updates will be provided during an active incident (e.g., every two hours to leadership, every four hours to all staff).

Section 7: Testing Schedule

A plan that has never been tested is a plan that will not work. Schedule regular testing and document the results.

• Tabletop exercise (quarterly): Walk through a disaster scenario verbally with the DR team. Identify gaps in the plan without touching any systems.
• Backup restore test (monthly): Select a random system and perform a full restore to verify that backups are working and complete.
• Partial failover test (semi-annually): Fail over a non-critical system to its backup environment and run it there for a defined period.
• Full DR test (annually): Simulate a complete disaster and execute the plan from start to finish. Document everything: what worked, what failed, and how long each step took.

After each test, update the plan to address any issues discovered.