Security 101 08-03-2016

Key Elements of a Disaster Recovery Plan

Mark Santamaria

In preparing for cybercriminals to attack with new variations of malware, it can be easy to forget that natural disasters can cause crippling data loss or server damage. Research by Eastern Kentucky University revealed that natural disasters cost the global economy $2.5 trillion since 2000, affecting SMBs in particular. After experiencing a disaster, one in four SMBs did not reopen, likely due to extreme damage or the loss of business and data, which can cost on average $3,000 a day.

A DRP (disaster recovery plan) is crucial in preparing businesses, large and small, to successfully work around an elemental disaster.

How a DRP Differs from an Incident Response Plan

A DRP takes into account any natural or manmade disaster. It encompasses anything from hurricanes to earthquakes to electrical fires to power outages. This is different than an incident response plan, which addresses and is created in preparation for security breaches, attacks, or another threat from cybercriminals.

Important Elements of a DRP

What one business may need to include in their DPR will differ from another based on business model, customer type, vertical, physical location, etc. For example, the differences in the business processes of each of these companies dictate that different plans because they have different distribution systems. Additionally, a business headquartered along the Gulf Coast would have to prepare for a hurricane while a business located in California would have to take potential earthquake damage into account instead. Further, server damage due to power outages could have different impacts based on the company; Amazon would take a greater hit than a local plumbing company if servers went down.

There is no cookie-cutter plan that will fit every business. With that in mind, there are a few key elements that every business should consider when developing a DRP.

Business Impact Assessment

Before developing a DRP, an organization should conduct a business impact assessment (BIA) first. A BIA is an evaluation that determines a businesses’ critical systems and which of those systems have priority over others when assigning them a recovery point objective (RPO) and recovery time objective (RTO).

An RPO helps determine what is an acceptable amount of data that a business can risk losing because the data hasn’t been backed-up. An RTO is a calculation of how long it will take a system to become functional after a disaster.

Off-Site Storage Location

Any back-up servers, hardware, and other materials that are vital in the disaster recovery process will need to be stored in a site away from the main office. If an organization’s main office is located along the San Andreas fault line and is hit by an earthquake, then the storage site should be located far away enough to not be affected by the same earthquake. The director of the Southern California Earthquake Center predicts that even San Diego, which is over 400 miles away would feel the effects of an earthquake in San Andreas.

Communications Plan

The DRP should include a list of employees and service providers who are necessary in expediting the recovery process as well as establish the roles and responsibilities for each person in the organization in the event of a disaster.

Clear and Direct Instruction

A DRP that is hundreds of pages long is going to be difficult to implement as opposed to one that is concise and easy to carry out. To help with concision, include a checklist of required tasks for each recovery scenario.

Speed is crucial in minimizing the damage of a disaster. With an organized and carefully constructed DRP, businesses can minimize the damage of a disaster, or more quickly get up and running again after a disaster strikes.

UP NEXT
PKI

3 Surprising Uses of PKI in Big Companies and How to Ensure They Are all Secure

5 Min

Featured Stories

12-04-2024

How artificial intelligence is reshaping digital trust

How to spot a fraudulent website

11-27-2024

6 actionable ways to secure the IIoT at every stage