It disaster recovery policy example

A disaster recovery plan (DRP) is a detailed document that outlines how an organization will respond effectively to an unplanned incident and resume business operations.

DRPs help ensure that businesses are prepared to face many different types of disasters, including power outages, ransomware and malware attacks, natural disasters and much more.

A strong DRP quickly and effectively helps restore connectivity and repair data loss after a disaster. Companies worldwide were set to spend USD 219 billion in 2023 alone on cybersecurity, a 12% increase from the previous year, according to a report by the International Data Corporation (link resides outside ibm.com).

What is a business continuity plan?

Like a DRP, a business continuity plan (BCP) is part of the disaster recovery process that helps businesses restore normal operations after a disaster happened. BCPs typically take a broader look at threats and resolution options than DRPs, focusing on what a company will need to restore basic business functions after an incident.

What is an incident response plan?

Incident response plans (IRPs) are a kind of DRP that focuses exclusively on cybersecurity and threats to information systems. An IRP clearly outlines an organization’s emergency response from the moment that they detect a threat through to its mitigation and resolution. An IRP seeks to address the specific damage done by a cyberattack, and focuses exclusively on preparedness for threats to technology, IT infrastructure, business operations and reputation.

Connect and integrate your systems to prepare your infrastructure for AI.

Register for the guide on app modernization

DRPs play a critical role in the development of an overall security plan that helps ensure stakeholders, clients and investors that a business operates responsibly. Enterprises that don’t take the necessary steps to ensure preparedness face various risks, including costly data loss, operational downtime, financial penalties and reputational damage.

Here are some of the benefits that businesses who invest in creating a strong DRP can enjoy:

Shorter downtimes

Many of today’s top businesses rely heavily on technology for normal operations. When an unplanned incident disrupts business as usual, it can cost millions. The high-profile nature of cyberattacks and the frequently analyzed length of their downtimes can also result in customers and investors losing confidence. Strong, vigorously tested DRPs help companies get back up and running swiftly and smoothly after an unplanned incident.

Reduced recovery costs

Recovering from an incident can be expensive. According to IBM’s recent Cost of Data Breach Report, the average cost of a breach in 2023 was USD 4.45 million, a 15% increase over the previous three years. Enterprises with strong DRPs in place can significantly reduce the costs of business recovery and other fallout from an unplanned incident. The same report found that, on average, organizations that use security AI and automation extensively save USD 1.76 million compared with organizations that don’t.

Lower cyber insurance

Because of the scale and frequency of cyberattacks, many enterprises rely on cyber insurance to protect them from dangerous security breaches. Many insurers won’t insure an enterprise that hasn't established a strong DRP. DRPs can help reduce your business' overall risk profile with insurers and help keep premiums low.

Fewer fines in heavily regulated sectors

Businesses that operate in heavily regulated sectors, such as healthcare and personal finance, face heavy fines and penalties for data breaches. Shortening response and recovery lifecycles is critical in these sectors as the amount of a financial penalty is often tied to the duration and severity of a breach. Enterprises with robust DRPs can recover more quickly and wholly from an unplanned incident and face fewer fines as a result.

The most effective DRPs are developed alongside strong BCPs and IRPs that provide crucial support when an incident occurs. Let’s look at a few key terms that are essential in understanding how DRPs work and what to consider when building your own:

Failover or failback

Failover is a widely used process where IT operations are moved to a secondary system when a primary one fails due to a power outage, cyberattack or other threat. Failback is the process of switching back to the original system after it has been restored. For example, a business might failover from its data center onto a secondary site where a redundant system takes effect instantly. If run properly, failover or failback can create a seamless experience where a user or customer isn’t even aware they are being moved to a secondary system.

Recovery time objective (RTO)

RTO refers to the amount of time that it takes to restore business operations after an unplanned incident. Establishing a reasonable RTO is one of the first things businesses need do when they’re creating their DRP.

Recovery point objective (RPO)

Your business’s RPO is the amount of data that it can afford to lose in a disaster and still recover. Some enterprises constantly copy data to a remote data center to ensure continuity if there is a massive breach. Others set a tolerable RPO of a few minutes—or hours—so they know they can recover from whatever they've lost during that time.

Disaster-recovery-as-a-service (DRaaS)

DRaaS has been gaining popularity of late due to a growing awareness around the importance of data security. Companies that take a DRaaS approach to creating their DRPs are outsourcing their disaster recovery to a third party. This third-party hosts and manages the necessary infrastructure for recovery, then creates and manages response plans and ensures a swift resumption of business-critical operations. According to a recent report by Global Market Insights (link resides outside ibm.com), the market size for DRaaS was USD 11.5 billion in 2022 and was set to grow by 22% in 2023.

With the prevalence and rising sophistication of cybercrime, most organizations are focusing their DRP efforts on their IT infrastructure, including critical data backup procedures (both on and offsite) and data protection. Here are a few examples of IT disaster recovery plans that have been tailored to fit a specific threat or business need:

A data center DRP focuses on the overall security of a data center facility and its ability to get back up and running after an unplanned incident. Some common threats to data storage include overstretched personnel that can result in human error, cyberattacks, power outages and difficulty following compliance requirements. Data center DRPs create operational risk assessments that analyze key components, such as physical environment, connectivity, power sources and security. Since data centers face a wide range of potential threats, their IT DRPs tend to be broader in scope than others.

Network DRPs rely on a clear set of steps to help an organization recover from an interruption of network services, including internet access, cellular data, local area networks and wide area networks. Considering how vital networked services are to business operations, an effective network DRP must clearly outline the steps, roles and responsibilities necessary to restore services quickly and effectively after a network compromise.

A virtualized DRP can dramatically enhance the effectiveness and speed of a recovery effort. Virtualized DRPs rely on virtual machine (VM) instances that can be ready to operate within a couple of minutes. Virtual machines are representations, or emulations, of physical computers that provide critical application recovery through high availability, or the ability of a system to operate continuously without failing.

Given the prevalence of cloud computing in many enterprise workloads, having a tailored DRP for the restoration of cloud services is becoming more common. Cloud DRPs outline a series of steps that ensure cloud data is backed up and apps and systems that rely on the cloud are restored smoothly.

The development of a DRP starts with an analysis of business processes, risk analysis and a few clearly defined recovery objectives. While there is no reliable, one-size-fits-all template, there are several steps you can take—regardless of company size or industry—to ensure you have a process in place to face various incidents.

A business impact analysis (BIA) is a careful assessment of each threat that a company might face and what its ramifications might be. A strong BIA examines how a potential threat might impact things such as daily operations, communication channels and worker safety. Some examples of potential considerations for a BIA include loss of revenue, cost of downtime, cost of reputational repair (public relations), loss of customers and investors (short and long term) and any incurred penalties from compliance violations.

Different industries and types of businesses face different threats, so risk analysis is critical to determining how you respond to each one. You can assess each risk separately by considering both its likelihood and potential impact. There are two widely used methods for determining risk: qualitative and quantitative risk analysis. Qualitative analysis is based on perceived risk, while quantitative analysis is performed by using verifiable data.

To recover from a cyber incident, it’s important to have a complete picture of the assets your enterprise owns. Doing regular inventory helps identify hardware, software, IT infrastructure, data and other assets that are critical to business operations. You can use labels such as "Critical", "Important" and "Unimportant" as a starting point to divide your assets into three overarching categories, then assign them more specific labels as needed:

• Critical: Only label assets as critical if your enterprise needs them for your normal business operations.
• Important: Give this label to assets that you use at least once a day and would have an impact on business operations (but not shut them down entirely) if they are disrupted.
• Unimportant: These are assets your business uses infrequently that are not essential for normal business operations.

The roles and responsibilities section of your DRP is arguably the most important. Without it, no one knows what to do when an unplanned incident occurs. While actual roles and responsibilities vary greatly depending on the type of business you conduct, here are some typical roles and responsibilities contained in most DRPs:

• Incident reporting: You should assign an individual (or individuals) in each department whose sole responsibility is communicating with the management team, stakeholders and all relevant authorities when disruptive events occur.
• DRP management: You should appoint a DRP supervisor to ensure that team members are performing their assigned tasks, and that the DRP is running smoothly.
• Asset protection: You should give someone the job of securing and protecting your most critical assets when a disaster strikes and reporting back on their status to management and stakeholders.
• Third-party communication: You should make it the responsibility of one person to coordinate with any third-party vendors you’ve hired as part of your DRP. This person should give constant updates on how the DRP is going to any relevant stakeholders.

To ensure that your DRP unfolds seamlessly during an actual incident, you need to practice it regularly and update it according to any meaningful changes you make to your business. For example, if your company acquires a new asset after your DRP has been formed, you’ll need to incorporate it into your plan to ensure it's protected going forward.

Testing and refinement can be simplified into three steps:

1. Create an accurate simulation: Try to create an environment as close to the actual scenario your company will face without putting anyone at physical risk.
2. Identify problems: Use the testing process to identify faults and inconsistencies with your plan, then address them in the next iteration of your DRP.
3. Test your backup and restore capabilities: Seeing how you’ll respond to an incident is vital, but it’s just as important to test the procedures you’ve put in place for restoring your critical systems when the incident is over. Test how you’ll turn networks back on, recover any lost data and resume normal business operations.