According to the biennial 2025 Global Assessment Report on Disaster Risk Reduction, the global cost of disasters has grown significantly in the past decades, now exceeding $2.3 trillion annually.

Part of this ballooning cost is the financial losses caused by company downtime that results from a disaster. According to New Relic's 2026 Observability Forecast, high-impact business outages cost organizations an average of $1.85 million per hour, and more than a quarter of organizations experience one weekly or more often.

With disasters becoming more frequent and costly, having a documented disaster recovery plan is key to improving operational resilience so your organization can recover any lost data or capability as quickly as possible to minimize the cost of downtime when a disaster occurs.

A disaster recovery plan (DRP) turns that risk into a sequence your team can follow under pressure: who declares a disaster, which systems come back first, and exactly how each one is restored. Below, we walk through the nine steps to create a DRP, the procedures your team follows once the plan is activated, what an IT disaster recovery plan needs to include, and worked examples of each in action, plus a free template to get started.

What is a disaster recovery plan?

A disaster recovery plan (DRP) is a contingency planning document that outlines the instructions or procedures an organization will follow to recover and restore its critical systems, operations, and data to normal or new-normal conditions after a disaster.

A disaster is a sudden event that disrupts the continuity of product or service delivery or any mission essential functions over a period of hours or days. Common examples of disaster events are:

• Cyber attacks
• Natural disasters
• Power outages
• Hardware and system failures
• Human errors

When any of these events occurs, a disaster recovery team typically assesses the severity of the event to determine whether the recovery plan should be activated. If it is a disaster event, then the team follows the predefined steps in the DRP to restore operations. A section later in the post details common examples of when a disaster recovery plan is invoked.

Before we walk through how to create a DRP, let's differentiate between two key contingency planning documents that are often confused.

Disaster recovery plan vs business continuity plan

A disaster recovery plan and business continuity plan both take a proactive approach to minimize the impact of a disaster before it occurs and may even be combined into a single document as a result.

However, the key difference is that a disaster recovery plan focuses on limiting abnormal or inefficient system function by restoring it as quickly as possible after a disaster, whereas a business continuity plan focuses on limiting operational downtime by maintaining operations during a disaster.

In other words, a disaster recovery strategy helps to ensure an organization returns to full functionality after a disaster occurs. A business continuity plan helps an organization keep operating at some capacity during a disaster.

That's why organizations need to have both documents in place, or need to incorporate disaster recovery strategies as part of their overall business continuity plan. If you're building both, Secureframe's free business continuity plan template pairs with the disaster recovery plan template below.

What’s the purpose of a disaster recovery plan?

Ultimately, the purpose of disaster recovery planning is to minimize the impact of a disaster and ensure business continuity. A well-designed disaster recovery plan can help by accomplishing the following four core objectives:

1. Minimize downtime and recovery costs

A DRP provides structured, repeatable steps to restore systems and services quickly, reducing the financial and operational impact of outages. This is increasingly important as disaster events become more common and recovery remains expensive, particularly for critical infrastructure industries like healthcare.

According to New Relic's 2026 Observability Forecast, high-impact outages cost businesses an average of $1.85 million per hour, or more than $30,000 per minute, and annualized outage losses reach $73.5 million.

According to IBM's Cost of a Data Breach Report 2026, the costs associated with one of the most common disaster scenarios, a data breach, reached a record high: the global average cost of a breach climbed 12% to $4.99 million. Organizations lost $1.54 million on average in lost business, spent an additional $1.36 million on post-breach response efforts, and paid $450,000 in notification costs alone.

Recovery also takes time. Only 42% of breached organizations had fully recovered, fewer than one in 20 recovered in under 50 days, and 19% needed more than 150 days.

A well-tested DRP helps organizations recover faster, avoid prolonged disruptions, and limit the cascading financial and reputational damage that often accompanies extended downtime.

2. Prevent data loss

A disaster recovery plan documents backup strategies, data replication schedules, failover processes, and recovery procedures that ensure essential data can be restored accurately after a disaster. This is vital as data recoverability continues to decline.

According to the 2025 State of SaaS Backup and Recovery Report, 87% of IT professionals experienced SaaS data loss in the past twelve months, and only 14% feel confident they can recover critical SaaS data within minutes. A third of organizations require days or even weeks to recover lost SaaS data.

The chances of data recovery are even worse for some disaster events, like a ransomware attack. According to Veeam's Data Trust and Resilience Report 2026, only 28% of organizations hit by ransomware in the past year fully recovered their affected data, and 44% recovered less than 75% of it.

A DRP dramatically improves your organization's odds of avoiding catastrophic data loss.

3. Provide peace of mind for employees and external stakeholders

A comprehensive DRP reduces stress, confusion, and decision paralysis when systems fail. Clear roles and responsibilities ensure teams know exactly what to do, which can help improve morale and job security. In fact, 82% of leaders surveyed in The State of Resilience 2025 said their teams worry about being fired for unplanned downtime or outages due to disasters.

A documented DRP can provide increased assurance not only to employees but also to vendors, customers, partners, and board members.

4. Avoid regulatory fines and compliance risk

Many security and risk management frameworks such as HIPAA, DORA, SOC 2, ISO 27001, and CMMC have explicit requirements about having disaster recovery processes in place and formalized in a DRP (or similar plan like a business continuity plan, incident response plan, or other type of contingency plan).

Without this type of plan in place, organizations may face increased breach costs, audit failures, and potentially significant regulatory penalties. Nearly half (44%) of technology executives say they are losing sleep over fines tied to downtime and outages. This concern spikes even higher among EMEA leaders to 85%, reflecting the growing pressure from DORA and NIS2 to improve resilience.

A disaster recovery plan is therefore not only a resilience tool, but a regulatory and financial safeguard.

Now that we understand its importance, let's walk through how to create a disaster recovery plan, step by step.

Disaster recovery plan steps: How to create a DRP

To create a disaster recovery plan, you must define the plan's scope and owner, inventory your systems and their dependencies, assess risks, run a business impact analysis to set recovery time and recovery point objectives, choose recovery strategies, write step-by-step recovery procedures, assign roles and communication paths, then train, test, and maintain the plan.

These nine steps broadly follow the seven-step contingency planning process in NIST SP 800-34 Rev 1, adapted for organizations outside the federal government.

Creating and maintaining a DRP requires collaboration and coordination among key stakeholders across an organization. The table below summarizes each step, what question it should answer, and what it should produce. The sections that follow explain how to complete each step in more detail.

1. Define objectives, scope, and ownership

Start by writing down what the plan is meant to achieve and what it covers. Typical objectives include:

• protecting employees' lives and company assets
• making a financial and operational assessment
• securing data
• restoring critical operations within agreed timeframes

The scope statement should name the locations, business units, systems, and third-party services the plan covers, and just as importantly, what it does not cover.

Typically, assets used by employees and contractors acting on behalf of the company or accessing its applications, infrastructure, systems, or data fall within the scope of the disaster recovery plan. In that case, employees and contractors should be required to review and accept the plan during onboarding and regularly after that, typically annually, so that acceptance is documented for audits.

This step is also where you assign ownership. Name a plan owner who is accountable for keeping the plan current, and a disaster recovery coordinator (with a backup) who has the authority to declare a disaster and activate the plan. Plans without a clearly named decision-maker tend to stall in the first hour of an incident while people debate whether the situation is serious enough.

2. Inventory systems and map dependencies

You can't recover what you haven't documented. Build or update a hardware and software inventory covering applications, servers, databases, cloud services, network components, endpoints, and SaaS tools, along with each one's business owner and technical owner.

Then map dependencies. A customer-facing application may depend on a database, an identity provider, DNS, a payment processor, and a secrets manager, and it can't come back until those do. Dependency mapping is what keeps recovery from stalling when a team restores its application on schedule only to find that authentication is still down. Include third-party dependencies too, and note which vendors would need to be contacted during a disaster.

3. Assess risks

Next, identify the risks and vulnerabilities that could disrupt your operations, both internal and external to the organization, and estimate the likelihood and impact of each. For most organizations, the realistic list includes ransomware and other cyber attacks, cloud provider or region outages, power and network failures, hardware failures, human error, and natural disasters relevant to your locations. Findings from your vulnerability management program can help show which systems are most exposed.

Pay close attention to concentration risk: how much of your operation depends on a single cloud region, a single data center, a single SaaS vendor, or a single person who knows how a system works. This should include evaluating your reliance on external vendors and suppliers for critical services and assessing their own disaster recovery capabilities to ensure they align with your requirements.

Record each disaster scenario in your risk register so it is tracked and reviewed alongside your other risks, and document how each will be addressed in your risk treatment plan. If you already run a formal cybersecurity risk assessment, these scenarios can usually be folded into it.

4. Conduct a business impact analysis

A business impact analysis (BIA) determines which business functions, processes, systems, and data are essential to your operations and what the consequences of a disruption would be. For each system in your inventory, work with its business owner to estimate the financial, operational, legal, and reputational impact of it being unavailable for an hour, a day, and a week.

The BIA produces two targets for every system:

• Recovery time objective (RTO) is the maximum acceptable time between a disruption and the system being restored.
• Recovery point objective (RPO) is the maximum acceptable amount of data loss, measured in time. For example, an RPO of 15 minutes means you must be able to restore data to a point no more than 15 minutes before the disruption.

Group systems with similar targets into recovery tiers. Tiering keeps the plan manageable and tells your team the order in which systems should be restored when everything is down at once. The IT disaster recovery plan section below includes an example tiering table.

5. Choose recovery strategies

Once you know your targets, choose the strategies that will meet them. This usually means deciding, for each tier:

• How data is backed up: Define frequency, retention, where copies are stored, and whether at least one copy is offline or immutable. This should line up with your data retention policy, so you aren't keeping regulated data longer than required or deleting backups you may need to restore from.
• How systems are restored: May include rebuilding from backups, failing over to a standby environment, or running active in more than one location.
• Where people will work: Determine an alternate worksite, remote work, or a reciprocal arrangement with another facility.
• Which preventive controls reduce the chance of needing the plan at all: Redundant power, network failover, monitoring, and access controls are common examples.

Tighter RTOs and RPOs require more costly recovery measures. A system with a four-hour RTO and a 15-minute RPO will typically need continuous replication and a standby environment, while a system with a three-day RTO may only need reliable nightly backups. Match the investment to the tier rather than applying the most expensive strategy everywhere, and get leadership to sign off on the tradeoffs so the targets in the plan reflect what the business has actually funded.

6. Write out recovery procedures

This is the core of the plan. Procedures explain the “how” of restoring a damaged system, with step-by-step guidance for actually executing the recovery strategies above that’s unique to the system’s security impact level, recovery requirements, and system priorities identified in the BIA.

Be specific. "Restore the database" is not a procedure. "Restore the most recent verified snapshot to the recovery environment, run integrity checks, then update the application's connection string" is. Include exact commands, file paths, console locations, and links to infrastructure-as-code templates where they exist.

The plan should also define activation criteria, or the conditions under which the DR coordinator declares a disaster, such as a Tier 1 system being unavailable longer than a set threshold or a confirmed ransomware infection.

You may also want to outline emergency procedures, such as evacuation plans and coordination with emergency services, for actions taken during and immediately after a disaster.

The table below provides an illustrative example of a disruptive incident and what recovery procedures an organization may take to restore their system. The disaster recovery procedures section below walks through what happens after a disaster is declared in more detail.

7. Define roles, communication, and escalation

List the members of the recovery team, their roles, and at least one alternate for each. Common roles include the DR coordinator, technical recovery leads for infrastructure, applications, and data, a communications lead, a security lead who coordinates with your incident response plan, and a business liaison who decides priorities when systems compete for attention.

Then document how the team will communicate if normal channels are unavailable. If your email and chat run on the same identity provider that just went down, you'll need an out-of-band option such as a phone tree, a secondary messaging tool, or personal contact details kept in an offline copy of the plan. Prepare message templates in advance for employees, customers, vendors, regulators, and, where relevant, law enforcement, so the communications lead isn't drafting from scratch mid-incident.

8. Train, test, and exercise

Recovery is only as effective as the people executing the plan. Provide ongoing training so everyone named in the plan understands their responsibilities, using workshops, role-based drills, or internal walk-throughs.

Then validate the plan through progressively more realistic exercises: tabletop exercises to walk through scenarios, backup restoration tests to prove data can come back within the RPO, and technical recovery or failover drills to prove systems can come back within the RTO. Record the results of every test, including how long each recovery took compared with its target, and track the gaps as action items. The testing and validation section later in this post covers each method in more detail.

9. Review and maintain the plan

Review the plan on a fixed schedule, at least annually, and also whenever something changes that would make it inaccurate: a new critical system, a cloud migration, a vendor change, a reorganization, a change in regulatory requirements, or lessons learned from a test or a real incident. Ensure that contact information, system configurations, and other relevant details are up to date.

Keep a version history and store current copies somewhere you can reach during a disaster, including at least one copy that doesn't depend on your primary systems.

Disaster recovery plan template

Creating a disaster recovery plan from scratch can be overwhelming, especially because a complete DRP must include many interdependent components, as discussed above.

Using a template with foundational sections helps simplify the process and ensure:

• You don't miss critical elements such as alternate facilities, escalation protocols, or dependency mapping.
• You write clearer, more complete documentation because each section includes prompts for what information to include.
• You can build a DRP faster, especially for teams that have never documented disaster recovery procedures before.
• Your plan stays consistent with standardized language, formatting, and structure across departments or business units.

Use this template to kick off your disaster recovery planning and customize it based on your organization's unique risk appetite, recovery strategies, and operational priorities.

Disaster recovery procedures: What happens when the plan is activated?

Disaster recovery procedures are the ordered actions your team takes from the moment a disruption is detected until normal operations resume. Most plans organize them into three phases, which NIST SP 800-34 Rev 1 calls activation and notification, recovery, and reconstitution, followed by a review of what happened.

Activation and notification procedures

1. Detect and assess the event.
Disruptions are usually detected through monitoring alerts, help desk reports, or a vendor notification. Speed matters here: for high-impact outages, organizations take an average of 41 minutes to detect the problem and 54 minutes to resolve it, according to New Relic's 2026 Observability Forecast. The first responder confirms what is affected, gathers initial facts, and alerts the DR coordinator. If the event may be a security incident, the security lead is brought in at this point, since the incident response plan and the DRP will run in parallel.

2. Declare a disaster and activate the plan.
The DR coordinator compares the situation against the plan's activation criteria and decides whether to activate the plan. Recording the time of the declaration matters: it starts the clock against your RTOs and is often requested later by auditors, insurers, and customers.

3. Notify and assemble the recovery team.
The team is contacted through the call tree, using out-of-band channels if primary communication is down. Initial notifications go to leadership, affected employees, and key vendors using the prepared templates. Customer and regulatory notifications follow once the scope is clearer and according to any contractual or legal deadlines.

Recovery procedures

4. Contain the damage and protect what's left.
Before restoring anything, stop the disruption from spreading. For a cyber attack, that may mean isolating affected systems, disabling compromised accounts, and preserving evidence. For a facility event, it may mean moving staff to the alternate worksite. Restoring into an environment that is still compromised or unstable is one of the most common ways recovery fails.

5. Recover systems in priority order.
Restore systems by tier, starting with the foundational services everything else depends on (identity, DNS, networking, and security tooling), then Tier 1 systems, and so on. Each technical lead works from the relevant procedures and reports progress to the DR coordinator, who tracks status against each system's RTO and reprioritizes if needed.

6. Validate restored systems and data.
Confirm each system works before declaring it recovered: run integrity checks on restored data, confirm the restore point meets the RPO, run application health checks, and have the business owner verify that critical workflows function. Note any data that was lost or needs to be re-entered.

Reconstitution procedures

7. Return to normal operations.
Once systems are stable, move from emergency operations back to normal. This may include failing back from a standby environment to the primary one, moving staff back from an alternate site, replacing temporary hardware, and confirming that backups and monitoring are running again on the restored systems. The DR coordinator formally declares the end of the disaster and notifies everyone who was told it began.

8. Close out with an after-action review.
Within a few weeks, hold a review with the recovery team to document what happened, how actual recovery times compared with targets, what worked, and what didn't. Turn the findings into action items with owners, and update the plan, procedures, and risk register accordingly.

Disaster recovery procedures examples

The examples below show how a disaster recovery plan may play out in four common scenarios at fictitious companies, with detailed activation, notification, recovery, and reconstitution procedures and illustrated timelines.

1. Ransomware attack

A 300-person professional services firm discovers that file servers and several virtual machines in its data center have been encrypted by ransomware. Its DRP and incident response plan are activated together.

1. Activation: The security lead confirms ransomware within 30 minutes of the first help desk tickets. The DR coordinator declares a disaster, and the team switches to a pre-arranged secondary messaging tool because email runs on the affected infrastructure.
2. Containment: Affected systems are isolated from the network, compromised accounts are disabled, and forensic images are preserved for investigators and the firm's cyber insurer.
3. Recovery: Once the security team confirms a clean recovery environment, the team rebuilds the domain controllers and identity services first, then restores file servers from offline backups taken before the earliest sign of compromise.
4. Validation and return: Business owners verify client files, and the firm documents which data created after the restore point must be recreated.

What made the difference was an offline backup copy that the attackers couldn't reach and a pre-arranged communication channel that didn't depend on the compromised environment.

2. Cloud region outage

A software company runs its customer-facing application in a single cloud region, with a warm standby environment in a second region. The primary region experiences a multi-hour outage.

1. Activation: Monitoring alerts the on-call engineer, who confirms with the provider's status page that the outage is regional. Once the Tier 1 application has been unavailable past its activation threshold, the DR coordinator declares a disaster.
2. Recovery: Engineers scale up the standby environment, promote the replicated database in the second region, and switch DNS to direct traffic there.
3. Validation: Smoke tests confirm login and core transactions work, and the team confirms the data loss falls within the 15-minute RPO.
4. Return: When the primary region recovers, the team schedules a controlled failback during a low-traffic window rather than switching back immediately.

The failover only worked within the RTO because the team had rehearsed it in a failover drill two months earlier and fixed a DNS configuration issue that the drill uncovered.

3. Accidental deletion of production data

An engineer runs a cleanup script against the production database instead of the staging database, deleting several customer tables.

1. Activation: The application team detects errors within minutes. The database lead confirms the cause and the DR coordinator activates the recovery plan.
2. Containment: The application is put into maintenance mode to stop further writes, and the engineer's elevated access is paused while the cause is reviewed.
3. Recovery: The team performs a point-in-time restore to a moment just before the script ran, then validates the restored tables.
4. Return and review: The after-action review leads to separate credentials for production and staging and a required peer review for scripts run against production.

Because the database used point-in-time recovery rather than nightly snapshots alone, the company lost only the few minutes of data created after the script ran. Our guide to preventing human error covers more controls that reduce the chance of incidents like this one.

4. Office loss from a regional power outage

A storm knocks out power to a manufacturer's headquarters for several days. Its production systems are hosted in the cloud, but its on-site network equipment, a local file server, and its staff's workspace are all affected.

1. Activation: Facilities confirms the utility's restoration estimate, and the DR coordinator activates the plan's alternate worksite procedures.
2. Communication: Employees receive instructions through the call tree and text messages, since the office phone system is down.
3. Recovery: Staff work remotely using company laptops, and the IT team restores the local file server's data to cloud storage from its most recent off-site backup. Teams that can't work remotely relocate to a pre-arranged alternate site.
4. Return: When power returns, IT inspects on-site equipment before bringing it back online and confirms backups have resumed.

The manufacturer's recovery was fast because its plan had already identified which roles needed physical workspace and which could work remotely.

If your organization doesn't yet have a documented incident response process to run alongside your recovery procedures, our incident response plan template is a good place to start.

Types of disaster recovery plans

A disaster recovery plan can be tailored to a specific system, environment, type of disruption, or security framework. While all DRPs share the same goal—restoring critical operations after a disaster—the structure and recovery procedures differ depending on what needs to be recovered and how quickly.

Below are the most common types of disaster recovery plans and what each one focuses on.

IT disaster recovery plan

An IT disaster recovery plan focuses on restoring an organization’s technology environment, including applications, servers, operating systems, and databases. It outlines the technical steps required to recover mission-critical IT services, identify system dependencies, and return applications to normal performance levels. 

This type of plan is essential for organizations whose operations rely heavily on digital systems or SaaS applications. Read how to write an IT disaster recovery plan below for the elements it should include.

Data center disaster recovery plan

A data center DRP provides detailed procedures for recovering physical and virtual infrastructure housed in an on-premises or co-located data center. It typically includes steps for equipment replacement, facility access, environmental controls, hardware configurations, and powering up systems in an alternate location. 

This plan is most relevant for organizations operating their own data centers or hybrid environments.

Backup disaster recovery plan

A backup DRP is centered on ensuring that critical data can be recovered quickly and accurately after loss or corruption. It covers backup retention schedules, storage locations, restoration tools, verification procedures, and chain-of-custody requirements for sensitive or regulated data. 

This type of plan is essential as data loss remains one of the most costly and common outcomes of cyber attacks, hardware failures, and human error.

Network disaster recovery plan

A network disaster recovery plan outlines how to restore connectivity across the organization’s network infrastructure, including routers, switches, firewalls, VPNs, and cloud networking components. The plan identifies critical communication paths, acceptable failover configurations, and procedures for re-establishing internal and external access. 

Because network outages can halt all business operations, this plan is crucial for minimizing downtime.

Cloud disaster recovery plan

A cloud DRP focuses on restoring systems, data, and services hosted in cloud environments such as AWS, Google Cloud, Azure, or a private cloud. It includes strategies such as replication across regions, failover orchestration, DRaaS (disaster recovery as a service), and cloud-native backup tools. 

As organizations move more workloads to the cloud, cloud-specific DRPs help ensure redundancy, availability, and rapid recovery.

NIST disaster recovery plan

A NIST disaster recovery plan may be based on the guidance provided in NIST SP 800-34 Revision 1, which identifies the DRP as one of eight types of information system contingency plans. NIST defines a DRP as “an information system-focused plan designed to restore operability of the target system, application, or computer facility infrastructure at an alternate site after an emergency.”

This type of plan is especially relevant for federal agencies and contractors that may experience a major disruption usually causing physical damage to the original data center and requiring relocation to restore information systems.

Ransomware disaster recovery plan

A ransomware DRP outlines the actions needed to detect, contain, eradicate, and recover from a ransomware attack. It includes procedures for isolating infected systems, identifying clean backups, restoring encrypted data, communicating with internal and external stakeholders, and preserving forensic evidence. 

This type has become increasingly important as ransomware remains one of the most prevalent cybersecurity threats and damaging disaster events.

How to write an IT disaster recovery plan

An IT disaster recovery plan documents how an organization restores its technology environment, including applications, infrastructure, data, identity, and cloud services, after a disruption. Beyond the general steps above, an IT DRP needs a recovery order based on technical dependencies, a backup design that survives the disaster itself, a recovery strategy matched to each system's targets, and procedures detailed enough for someone to actually execute the strategy.

Tier your systems by recovery priority

Use the results of your BIA and dependency mapping to assign every system to a recovery tier. Many organizations add a "Tier 0" for foundational services that the business rarely thinks about but that every other system depends on.

These targets are illustrative. Yours should come from your own BIA and reflect what leadership has agreed to fund.

Recover identity and access first

During a disaster, your identity provider is often the single point of failure that blocks everything else: engineers can't reach consoles, and employees can't reach email. Document how you'll regain administrative access if your identity provider, single sign-on, or multi-factor authentication service is unavailable or compromised.

Common measures include a small number of tightly controlled break-glass accounts, credentials stored in an offline vault in line with your password policy, and a documented procedure for rotating those credentials immediately after use.

Design backups that survive the disaster

Backups only help if they're intact when you need them. Ransomware operators routinely look for backups to delete or encrypt, which is why CISA's #StopRansomware Guide recommends maintaining offline, encrypted backups of critical data and regularly testing that they can be restored. A common approach is to keep multiple copies of data on different storage, with at least one off-site and at least one that is offline or immutable.

Document backup frequency and retention for each tier, where each copy lives, who can delete backups (as few people as possible), and how often restores are tested. Don't assume SaaS providers back up your data for you: many only guarantee the availability of their platform, not the recovery of your records, so check each provider's terms and add third-party backups where needed.

For defense contractors, backups containing Controlled Unclassified Information (CUI) are in scope for CMMC, and NIST SP 800-171 requirement 3.8.9 requires protecting the confidentiality of backup CUI at storage locations.

Match a recovery strategy to each tier

Cloud environments offer a range of recovery strategies with different speed and cost profiles. AWS's disaster recovery guidance describes four, and the same model applies broadly across cloud providers:

Even with replication, keep point-in-time backups. Replication faithfully copies deletions and corrupted or encrypted data to the second location, so active/active alone won't protect you from ransomware or human error. Our guide to cloud data security covers related controls for protecting data in these environments.

Write detailed procedures that anyone can follow

The person who knows a system best may be unavailable during a disaster. Write out detailed enough procedures so that a competent engineer unfamiliar with the system could follow it: exact commands, paths, console locations, required permissions, expected outputs, and what to do if a step fails. Where you can, define infrastructure in code and maintain preconfigured "golden images" for critical servers, both of which CISA recommends to speed up rebuilds and reduce manual error.

Plan for a compromised environment

Recovering from a cyber attack is different from recovering from a power outage, because the environment itself may be untrustworthy. Your IT DRP should explain how recovery coordinates with your incident response process: how systems are isolated, how evidence is preserved, how the security team confirms an environment is clean before anything is restored into it, and how you'll identify a restore point that predates the compromise.

CISA also advises checking for precursor "dropper" malware before rebuilding from backups, so restored systems aren't reinfected. Defense contractors should also account for the incident reporting obligations in their contracts; our guide to CMMC incident response requirements covers them in detail.

Account for third-party and SaaS dependencies

List every vendor your critical systems depend on, along with its support contacts, contractual uptime and recovery commitments, and how you'd export your data or switch providers if it suffered a prolonged outage or a supply chain attack.

Ask critical vendors for evidence of their own disaster recovery testing as part of your third-party risk management program, and make sure their recovery targets are compatible with yours. Our vendor risk management checklist can help structure those reviews.

Keep the plan reachable during an outage

A DRP stored only in the wiki that just went offline is no help. Keep current copies in at least two places that don't share a failure point, such as a secondary cloud account and printed or offline copies held by the DR coordinator and alternates.

Our free disaster recovery plan template includes sections for scope, recovery objectives, recovery procedures, roles, and communication, so your team can start from a complete structure rather than a blank page.

Disaster recovery plan elements in a sample IT DRP

Just as no two businesses are the same, no two disaster recovery plans are. However, they do typically include some common elements. These elements are detailed below, with sample sections from NWF Health’s Information Technology Disaster Recovery Plan to show a potential format and wording for each element. 

Data backup and recovery procedures

A section of a DRP should be dedicated to data backup and recovery. This should list backup methods, frequency of backups, the storage locations, and the procedures for data restoration.

For example, NWF Health’s DRP includes a “Server Recovery Plan” section that details backup schedules, responsibilities of their third-party support vendor DIS as well as internal folks, and restoration steps.

Redundant systems and infrastructure

Another section may explain how the organization implements redundant systems and infrastructure to ensure high availability and minimize downtime if a disaster occurs. This may involve duplicating critical servers, network equipment, power supplies, and storage devices using clustering, load balancing, failover mechanisms, virtualization technologies, or other measures. 

In NWF Health’s sample, hardware redundancy is addressed through documented hardware replacement and notification procedures, for example.

Alternate worksite

A DRP may identify alternative worksites or recovery locations where the organization can operate if the primary site becomes inaccessible. This section should also define procedures and infrastructure needed to quickly transition operations to the identified alternate sites.

NWF Health includes a “Facility Plan” section that details the requirements for a functional alternate facility.

Communication and notification procedures

Another part of DRP may define communication protocols and notification procedures to ensure communication during and after a disaster. Protocols and procedures typically include:

• notifying employees, customers, vendors, and stakeholders about the disaster
• providing updates on recovery progress
• maintaining contact information for key personnel and emergency services

NWF Health’s DRP includes a section on expected communications during emergency maintenance, for example.

Recovery objectives

A DRP may set acceptable time frames for recovering systems and data in terms of recovery time objectives (RTO) and recovery point objectives (RPO). These objectives should be based on the criticality of systems and shape recovery strategies accordingly. 

• RTO: The maximum amount of downtime allowed
• RPO: The maximum loss of data accepted (measured in time)

NWF Health’s plan includes a table that lists the RTO and RPO of every major IT service or application that may be affected by a disaster, including the data centre facility, storage services, 

Disaster recovery plan examples

Below you can find examples of disaster recovery strategies and procedures from disaster recovery plans created and maintained by universities and other organizations. This should help you in brainstorming and documenting your own recovery strategies and plans for different services, environments, and types of disasters. 

1. Southern Oregon University

Type: IT disaster recovery plan

Southern Oregon University maintains a comprehensive IT DRP because its faculty, staff, and students rely heavily on technology services. The plan covers a wide range of IT assets including the university’s data center, network infrastructure, enterprise applications, desktop hardware, client systems, classrooms, and labs.

Some of the IT disaster recovery processes and procedures outlined in the plan are:

• Secure facility as necessary to prevent personnel injury and further damage to IT systems.
• Coordinate hardware and software replacement with vendors
• Verify operational ability of all equipment on-site in the affected area (servers, network equipment, ancillary equipment, etc.). If equipment is not operational, initiate actions to repair or replace as needed.
• If the data center is not operational or recoverable, contact personnel responsible for the alternate data center and take necessary steps to ready the facility.
• Retrieve most recent on-site or off-site back-up media for previous three back-ups. Prepare back-up media for transfer to primary or secondary datacenter, as determined during the initial assessment.

This example provides a strong model for organizations that need to document detailed IT recovery procedures across complex on-premises environments and diverse user groups.

2. AllCode’s AWS disaster recovery plan

Type: Cloud disaster recovery plan

AllCode, a cloud development and DevOps consulting firm, operates primarily on AWS and maintains a disaster recovery plan tailored specifically for cloud-based environments. Their plan provides a strong example of how organizations can leverage AWS-native tools and architectures to achieve resilience, reduce downtime, and enable rapid failover.

Key components include:

• Multi-Region redundancy: Workloads and data are replicated across multiple AWS Regions and Availability Zones to ensure systems can fail over if the primary region becomes unavailable.
• Automated infrastructure provisioning: Using AWS CloudFormation and Terraform, AllCode can rebuild infrastructure quickly and consistently in a recovery Region.
• Automated backups: AWS Backup, EBS snapshots, and RDS automated backups ensure data is captured at regular intervals and stored in multiple locations for resilience.
• Pilot light environments: Critical core services run continuously at low capacity in a secondary Region, allowing the organization to scale up rapidly if the primary Region fails.
• Failover routing: Amazon Route 53 is configured with health checks and DNS failover to redirect traffic to the recovery environment during disasters.
• DR testing and validation: The team performs routine failover tests using isolated test accounts and Regions to verify that infrastructure, data, and applications can be restored within the required RTO and RPO targets.

This example provides a useful blueprint for organizations running workloads in AWS or any major cloud platform.

3. University of Iowa

Type: Data center disaster recovery plan

The University of Iowa maintains a detailed data center DRP covering the steps required to recover or relocate operations if its primary data center is impacted by a natural disaster, equipment failure, or other major disruption.

Examples of the data center recovery procedures include:

• Have large tarps or plastic sheeting available in the data center ready to cover sensitive electronic equipment in case the building is damaged due to natural disasters like tornadoes, floods, and earthquakes.
• If replacement equipment is required, make every attempt to replicate the current system configuration.
• If data is lost, then request that the IT department recover it from an off-site backup or cloud deep archive storage.

This example serves as a practical reference for any organization that operates its own data center and must plan for physical infrastructure damage, environmental risks, and hardware-specific recovery steps.

When is the disaster recovery plan invoked?

A disaster recovery plan (DRP) is invoked when an event severely impacts an organization's ability to function for an extended period of time. Disaster events include:

Cyber attacks

Distributed denial-of-service (DDoS), ransomware, social engineering, and other types of cyber attacks can compromise sensitive data, disrupt services, and result in system downtime. In response, organizations may need to isolate affected systems, restore backups, and reinforce security measures.

Ransomware remains one of the most common reasons a DRP is activated. IBM's Cost of a Data Breach Report 2026 found that 39% of breached organizations were hit by ransomware, up from 24% in 2023.

Example: The 2023 ransomware attack on MGM caused a nine-day outage across hotel, gaming, and reservation systems and resulted in over $100 million in losses in Q3 of that year alone.

Natural disasters

Earthquakes, floods, hurricanes, or fires can physically damage data centers, offices, and communication networks, preventing normal business operations. Recovery may involve relocating to alternative sites, restoring backups, and ensuring employee safety.

Example: In 2024, Hurricane Milton flooded hundreds of thousands of buildings, left millions without power, and caused widespread network outages across Florida. It was ranked as the most expensive single climate disaster event, causing $60 billion in damages and killing 25.

Power outages

Extended power failures can disrupt servers, networking equipment, and cloud services, leading to downtime and potential data corruption. To recover from an outage, an organization may need to deploy backup generators, use uninterruptible power supplies (UPS), and ensure failover data centers are available.

Example: In April 2025, a power outage affected tens of millions of people across almost all of Spain and Portugal and led to major disruptions to transport services, payment processing, and sporting events.

Hardware and system failures

Critical server crashes, storage failures, or database corruption can interrupt applications and prevent users from accessing critical services. Recovery typically involves hardware replacement, system restoration from backups, or redundancy measures to prevent recurrence.

Example: The 2024 CrowdStrike flawed update caused a global IT outage that resulted in flight delays, hospital closures, and an estimated financial loss of $5.4 billion for the Fortune 500. It is considered the biggest global software failure to date.

Human errors

According to Cockroach Labs, 31% of companies have experienced an unplanned service outage due to human error in the past year.

Accidental data deletion, misconfigurations, or insider threats are all examples of human error that can lead to outages and security breaches. In response, an organization may need to restore data from backups, implement stricter access controls, and provide employee training to prevent future incidents.

Changes are a related and largely controllable source of disruption. New Relic's 2026 Observability Forecast found that software deployments and environment changes together account for 60% of high-impact outage causes, which is why a documented change management policy belongs alongside your DRP.

Example: In October 2025, a DNS error in AWS's Northern Virginia region disrupted more than 100 AWS services and temporarily brought down major platforms like Reddit, Snapchat, and Venmo.

Which security frameworks require a disaster recovery plan?

Below are specific requirements from some of the most common regulatory and security frameworks that can be met, at least partially, by having a disaster recovery plan or documented disaster recovery procedures in another plan, like an incident response plan.

It’s important to understand that organizations will have to put additional controls in place to fully meet the requirements below, but a DRP can provide some essential coverage for each framework.

Disaster recovery plan best practices

While every organization's disaster recovery plan will look different depending on its systems, data, and regulatory landscape, several best practices consistently appear across authoritative guidance from HHS, Google Cloud, AWS, and NIST.

Incorporating these practices can significantly strengthen your organization's resilience and reduce recovery time after a disaster.

1. Align with framework and regulatory requirements

If your organization must comply with a regulatory or cybersecurity framework, ensure your DRP meets all applicable requirements.

For example, HIPAA's Disaster Recovery Plan specification (§164.308(a)(7)(ii)(B)) requires covered entities to establish procedures to restore any loss of electronic protected health information (ePHI). HHS explains that a general disaster plan may meet this requirement, but entities must ensure that it allows them to recover ePHI specifically, or update language and procedures accordingly.

A framework-aligned DRP not only strengthens resilience but reduces compliance risk, violations and fines, and audit exceptions.

2. Make all tasks specific and actionable

Ambiguous steps slow down recovery and increase the risk of errors during high-pressure incidents.

Instead of vague instructions like "Run the restore script," Google Cloud recommends defining exact commands, file paths, tools, and responsible roles like "Open a shell and run /home/example/restore.sh."

Clear instructions like this ensure consistent execution and reduce human error.

3. Maintain accurate asset inventories and dependencies

NIST SP 800-34 Rev 1 recommends maintaining a current list of all people, processes, technology assets, and data required to resume mission/business processes as quickly as possible. Documenting these resources is essential to realistic recovery efforts, ensuring priority levels are set and recovery activities are sequenced and completed in a timely manner.

4. Select an appropriate cloud recovery strategy

AWS outlines four primary cloud disaster recovery strategies. It's essential that you understand, select, and regularly test the option that enables you to meet your RTO and RPO requirements without overspending.

• Backup and restore: Lowest cost, longest recovery time
• Pilot light: Minimal core infrastructure kept running for faster scale-up
• Warm standby: A scaled-down production environment running continuously
• Multi-site active/active: Near-zero recovery time, highest cost

5. Establish a schedule to test and validate your disaster recovery plan

Testing your disaster recovery plan is essential to ensure it works as expected when a real disruption occurs. A well-designed testing cycle helps validate your recovery procedures, uncover gaps, and confirm that your RTO and RPO targets can be met.

Here are the most common methods for testing a DRP:

• Tabletop exercises: Team members walk through simulated disaster scenarios in a conference-room setting to validate roles, decision points, communication flows, and recovery steps.
• Backup restoration tests: Verify that backups can be restored fully, accurately, and within the required recovery time. This includes testing off-site, cloud, and immutable backups.
• Technical recovery drills: Rehearse specific recovery actions such as failover, system rebuilds, environment provisioning, and application restarts.
• Full failover simulations: Switch operations to your secondary data center or cloud region to ensure all systems, networks, and dependencies work end-to-end in the recovery environment.
• Cloud resilience tests: Perform region-failover tests, automated provisioning checks, and health-check validations (AWS Route 53, Google Cloud Observability, Azure Traffic Manager).
• After-action reviews: Document lessons learned, update recovery procedures, assign remediation tasks, and incorporate improvements into the next DRP version.

Confidence is not the same as proven recovery. In Veeam's Data Trust and Resilience Report 2026, 90% of security leaders said they were very or extremely confident they could recover from a cyber incident within their RTOs. Yet among organizations hit by ransomware, only 28% fully recovered their data, and just 57% said they track restore and recovery testing as a readiness metric.

Cockroach Labs' State of AI Infrastructure 2026 report found a similar gap: only 36% of senior technology leaders described their organizations as proactive, running regular failover tests and resilience drills for AI-related disruptions, while 41% said they do some testing but gaps remain. Without proper testing, organizations don't know if their disaster recovery plans will work when needed. Our roundup of disaster recovery statistics shows how wide that preparedness gap runs.

Regular testing, at least annually and after major technology changes, ensures your plan remains accurate, actionable, and effective and provides peace of mind that you'll be ready when a disaster strikes.

How Secureframe can help improve disaster recovery and operational resilience

Secureframe's compliance automation platform and expert guidance help organizations build, maintain, and continuously validate a disaster recovery plan that meets modern regulatory requirements and withstands real-world operational disruptions.

Beyond simplifying documentation, Secureframe provides the automation, monitoring, and expertise needed to proactively reduce risk and recover quickly when disaster strikes.

Key features of our compliance management system include:

• Automated control testing for DR requirements: Secureframe automatically tests disaster recovery-related controls across 50+ frameworks through integrations with your existing tech stack. This ensures continuous compliance without the manual burden of tracking and validating recovery requirements.
• Policy templates developed by compliance experts: Secureframe provides auditor-vetted policies and procedures, including disaster recovery and business continuity templates, to eliminate the guesswork of documentation. You can publish policies, assign owners, track acceptance, and manage periodic reviews all within the platform.
• Compliance expertise from former auditors: Secureframe's in-house compliance experts and former security and compliance auditors offer guidance at every stage, from initial plan development to testing, updating, and aligning with framework requirements, so your DRP reflects best practices and strengthens cyber resilience.
• Continuous monitoring: Secureframe enables ongoing adherence to regulatory and cybersecurity requirements by automatically monitoring controls, scheduling regular reviews, and surfacing issues before they escalate into disruptions.
• AI-powered risk assessment: Comply AI automatically identifies, scores, and recommends treatment for risks, including those tied to disaster recovery, while generating justifications, residual risk, and documentation instantly.
• Integrated risk management: Secureframe's risk library includes NIST-aligned risk scenarios across IT, fraud, legal, privacy, and finance, making it easy to add, categorize, and track risks. You can then link risks to controls, track history, and align risk treatment plans with compliance requirements to strengthen your organization's overall security posture.

Together, these capabilities help organizations prevent disasters where possible, minimize their impact when they occur, and maintain operational resilience year-round.

Request a demo to learn how Secureframe can help strengthen your disaster recovery and resilience strategy.

This post was originally published in July 2023 and has been updated for accuracy and comprehensiveness.