To borrow from a classic Monty Python sketch, “No one expects the Spanish Inquisition.” Just like no one heads in to work thinking, “Today’s the day disaster is going to strike our network, and I’m going to spend the next 48 hours scrambling to get the company back online before we lose millions of dollars in revenue and half of our biggest customers.”
Disasters aren’t planned, but you can plan for them. Which is why a comprehensive, up-to-date, working disaster recovery plan should be included in every enterprise business continuity plan.
What Is a Disaster Recovery Plan?
A disaster recovery plan is your step-by-step guide for getting your business and operations systems back up and running quickly after a major outage caused by a natural disaster, cyberattack, fire, or technical failure.
Whereas your business continuity plan focuses on how the organization will continue normal-ish day-to-day operations during and after a disaster, your disaster recovery plan is honed in on restoring system functions and preserving data as part of the larger continuity strategy.
Why Do I Need a Disaster Recovery Plan?
Enterprises headquartered in Florida and California—areas prone to natural disasters such as hurricanes and wildfires—understand how important it is to prepare for a worst-case scenario. But even if your corporate backbone is in a low-risk area, you cannot afford to be complacent in your recovery planning and preparation.
Cyberthreats are increasing exponentially, weather patterns are becoming more unpredictable, and you never know when Jim from accounting will forget to turn off the coffee pot on a Friday afternoon and reduce the place to ashes.
Which is why every business needs a disaster recovery plan that will maintain high availability for users, mitigate disruption to operations, protect from data loss, and provide some insurance against a ransomware attack.
What Should I Include in My Disaster Recovery Plan?
Every disaster recovery plan is unique to the organization’s business systems, regulatory requirements, SLAs, and priorities. However, to function effectively during your recovery effort, be sure your disaster recovery plan meets these four competencies.
Business Impact Analysis
Conducting a business impact analysis well in advance of a crisis will help you understand what is at stake in the event your technology systems are disabled for a significant amount of time.
It is important to involve all stakeholders in this process to ensure the analysis accurately reflects the impact on all internal business units as well as external factors such as supply chain dependencies.
Your business impact analysis should identify which applications are essential to the business, then map those applications to the infrastructure required to support them. Once you know which systems and applications are business-critical, you can prioritize order of recovery.
Be sure to include in your analysis an estimate of the cost of downtime and your maximum tolerable downtime, as well as recovery time objectives (RTOs) and recovery point objectives (RPOs).
You will also need to document any legal and regulatory compliance requirements your organization has, because those will factor into your recovery priorities.
Knowing your level of risk in the event of a disaster will help you plan to mitigate those risks.
Start with a map of your IT infrastructure—both in-house and cloud/web-based—and look for weaknesses and dependencies in these infrastructures.
Identify possible types of disasters and rate your level of risk from probable to unlikely. Document a specific recovery response for each type of disaster. For example, we do this if a tornado destroys the building; we do that if we’re hit with a ransomware attack.
Thanks to your business impact analysis, you know what’s at stake. Now you need a plan to protect your assets.
Put together a disaster response team to streamline the recovery process. In addition to their assigned recovery responsibilities, this team will be in charge of communications throughout the crisis and be a point of contact for stakeholders. The disaster response team will also be in charge of emergency response training for staff so everyone is aware of company policies and procedures during a disaster.
From a technology perspective, your disaster recovery plan needs to focus on making sure data and applications are recoverable. One way to do this is to ensure redundancy exists for all business-critical systems. For example, move servers to the cloud so they are geo-independant.
Also, be sure that you back up your systems frequently and that those backups are stored somewhere off-site but easily accessible. Keep in mind that certain strains of ransomware can access and encrypt your backups, so keep them inaccessible directly from the network.
An important but often overlooked management best practice is to write your disaster recovery plan in plain language. You don’t know who will be around to take the lead after a disaster, so skip the IT jargon in case a nontechnical person needs to initiate the recovery effort.
As mentioned above, frequent backups are essential, but your recovery effort will only be as good as the data you restore, so make sure you also test your backups regularly.
A generally recognized rule of thumb is to test a partial restore twice each year and test a full restore once each year, though these should be considered minimum requirements.
Once you have finalized your disaster recovery plan, consider investing in a third-party audit to look for holes in your plan. The money you spend now could save you much more later.
The world is dealing with enough uncertainty right now. Be sure that your organization is prepared to bounce back quickly from the unexpected. Download How to Build a Disaster Recovery Plan to learn more best practices for creating a comprehensive disaster recovery plan.