Have you Adjusted your DR Plans for the Cloud?


Many companies struggle to develop and update their disaster recovery plans. In the process, they overlook the amount of IT they have moved to the cloud. What if the cloud fails?

Businessperson stopping falling dominos with their hand.
Image: Gajus/Adobe Stock

Currently, 94% of companies use cloud services, and by 2025, it is estimated that 100 zettabytes of data will be stored in the cloud. Yet only 54% of companies have a disaster recovery plan in place. Even for organizations with DR plans, DR is decidedly aimed toward the continuation of internal assets and systems.

SEE: Hiring Kit: Cloud Engineer (TechRepublic Premium)

Protecting internal IT is critical, but what about the IT that companies have in the cloud?

How to update your DR plans for cloud-based IT

Review your DR plans

Is your DR plan updated? Do you regularly test the plan to make sure it works? Does your DR plan cover all of your IT assets that are cloud-based? What about your internal systems? Are these properly covered in your plan? These are a few of the questions that organizations should ask themselves. They are questions that are likely to lead to other questions.

What you want to end up with is a gap analysis that informs you where the holes in your DR plan are and what you need to do in order to address them. In most cases, organizations will see that they haven’t kept up with updates to their DR plans that account for all of the IT assets that they have in the cloud.

Assess your risks

Next, review your IT infrastructure. What are the types of business interruptions that the organization is most likely to face? Is your company in an area where an earthquake could threaten a local data center? Do you have security risks that your own systems or your vendors’ systems present?

When you identify your key vulnerabilities and develop approaches that mitigate them, you strengthen your DR capabilities at their weakest points. Some of these points will be in the cloud.

Meet with your cloud providers

Few cloud providers will assume liability if something goes wrong in the cloud. What most cloud providers agree to do is to make a “best effort” for recoveries. Nevertheless, there are several steps you can take to assure that you have a cloud provider that is well positioned for a DR recovery if one is needed.

Cloud providers with robust DR capabilities have data centers in multiple regions of the country and/or in the world. In this way, if there is an earthquake on the west coast that impacts a cloud data center, and your data and systems are replicated at another data center in the Midwest, you can cutover to the Midwest data center and keep running.

The vendor must also have data communications between data centers that are robust enough to make the cutover — and it has to have personnel at each data center who are capable of supporting your systems.

The best way to check on these capabilities is during your negotiations with the cloud provider before you sign a contract. Once you have confirmed that the vendor has the DR capability to support your systems, you can create SLAs as an addendum to your contract that state what you expect in terms of DR recovery time.

You should also negotiate with your vendor for annual reviews and updates of your cloud DR plans and for an annual test of DR and failover with the vendor to assure that your cloud DR plan with the vendor actually works.

Update and test your plans on a regular basis

DR plan reviews and testing for cloud-based applications and data should ideally occur on an annual basis. Realistically, this might not always be practicable. As an alternative, some companies opt to test select portions of their plans on a quarterly basis, since commandeering the resources and personnel for a full annual test of every system and data repository might be difficult.

In this way, you might not be able to stress test every system for DR recovery in the cloud each year, but you will be able to gauge the DR readiness of your own IT internally and in the cloud.