5 Questions You Need To Answer About Your DR Plan

If you manage your company’s DR processes and plans, you’re already intimately involved in the technical nuances of your technologies and vendors. However, a successful plan requires total company buy-in, including that of your leadership team. When your C-level executives and the Board of Directors ask about your DR plan, they want your answers to provide the confidence that says the business will continue to be successful and secure, no matter what.

It can be easy to stay in the details and nuances, but those don’t always connect to the bigger business concerns. Be fully prepared for a conversation about your current DR plan, and potentially, the gaps that need to be filled by walking through the following five questions. Answering these questions will set the stage for proper buy-in, which leads to adequate budgeting and coverage to empower you with a solution guaranteed to be successful.

1.     What is the economic risk if core applications go down for a day, a week, or even longer?

All applications are not the same. Some applications are revenue generating and some are used for internal support. Each application is important, but not every application is as important from a bottom-line standpoint, in terms of the cost of downtime in minutes, hours and days.

Work with the business unit to determine what the revenue-impact would be for the business when you break it down by day, hour and minute so you can prioritize and force-rank applications in order of priority across business units.

2.     How are our applications currently protected and are they all protected the same way?

Perhaps the biggest shift from legacy disaster recovery solutions to today’s cloud-based DR solutions is the ability to protect specific applications at their best-fit protection level, rather than forcing all into a one-size-fits-all DR solution. Critical applications require a very quick Recovery Time Objective (RTO) and Recovery Point Objective (RPO), which is more costly than longer RTO and RPOs.  These are also the same applications that would result in the biggest negative revenue impact during downtime, as determined in question #1.

Sort your applications into a 4-level tiered structure with Tier 1 applications requiring near instantaneous RTO and RPOs that are best served with a high-availability solution. Tier 2 applications will have less aggressive requirements, for example requiring 30-minute RPO and 4-hour RTO. Tier 3 and Tier 4 applications fall farther down on the prioritization list, as they can withstand a day of downtime or longer, as long as the data is protected within the solution.

3.     What will happen to our key data in the event of a disaster?

Recovery-as-a-Service solves two business needs. It ensures consistent application uptime, but it also is responsible for protecting data within those applications.

Your solution should not only adequately secure your key data, but also provide for accessibility of resources like decryption keys and pass phrases that allow access to encrypted backups.  This will allow your team to access the important data even if the primary application is compromised and should remain a separate part of the DR plan from protecting the primary applications itself.

Higher tier solutions will provide more protection for this type of data. Addressing the protection needs of your data within your application can shift your initial placement of the application in the tiered structure. A higher tier may be more costly, but certain data’s importance will likely justify the extra cost.

4.     Against which types of disasters are we guarding?

Don’t just distinguish between natural and man-made disasters; rather, your team should qualify the level of disaster you’re protecting against. Application disasters exclusively impact the application, while regional disasters are widespread and impact an entire region. If your second DR site is located across town, that site may protect you from certain disasters, but likely will not protect you from regional concerns.

There are five general types of disasters. From smallest-size impact to largest, they are Application Disasters, Infrastructure Disasters, Datacenter Disasters, Metro Disasters and Regional Disasters.  Consider and understand the types of disasters you are guarding against and weight that against the physical distance of where your DR solution is located.

5.     What were the results of our latest full recovery test?

Everything you put down on paper before this question is important, but nothing is as important as the answer to this question. A DR solution that doesn’t work when it’s called upon is a waste of money for the business. Recovery-as-a-Service solutions are easier to test than any solution previously and companies can choose to run full failover and failback tests, or choose to perform sandbox testing. Sandbox testing is faster and less risky than full failover tests, but they may leave gaps between the sandbox and the production environment and could lengthen your RTO.

Twice annual testing is the recommended test schedule for most applications. If your applications change significantly more than twice annually, that testing should be increased to coincide with the updates.  A documented recovery runbook and QA checklist can provide the final bit of confidence and auditable assurance that your DR solution will live up to the promises that you’ve made to the business and leadership.

Don’t let your recovery plan fail due to lack of communication or organization buy-in. In order to facilitate the conversation between all parties, use a chart that outlines a clear matrix of your applications, their risk, recovery and expense to frame a conversation with your leadership team.

However, don’t stop there! Make going through this process with your team at least an annual activity in order to ensure that your DR plan is up-to-date and your valuable infrastructure and applications are adequately protected.

Ben Miller | Bluelock | Product Solutions Director