Cloud Disaster Recovery: Four Common Mistakes Organizations Should Avoid


When organizations create a cloud disaster recovery plan, they can make certain mistakes and fall into a few traps. In this article, Richard Marcus, head of information security at AuditBoard, discusses a few mistakes companies can often make and ways to avoid them.

RansomwareOpens a new window attacks occur every 11 seconds; wildfires and hurricanes shut down infrastructure — these are just a few of the disasters that can take down your IT operations. Moving applications and data to the cloud seems like the right step, but it alone is not enough. Verizon’s “2021 Data Breach Investigations ReportOpens a new window ” found 5,258 confirmed breaches, a third more than in 2020, with attacks on cloud applications making up 39% of all breaches. 

You cannot transfer the risk of data loss entirely onto the third-party service provider. In the end, you are still responsibleOpens a new window for maintaining strong IT and recovery controls and validating the adequacy of any cloud vendors. Despite the well-established need for solid backup and recovery controls, some organizations still slip into complacent patterns and neglect these critical controls. This article addresses the four most common cloud disaster recovery plan mistakes and ways your organization can prevent them. 

1. Not Having a Backup Plan

“Moving to the cloud” is too often looked at as full risk mitigation in disaster recovery planning (DRP). For example, many of the business line functions in an organization are moving to software hosted in Amazon Web Services (AWS). They may mistakenly think this covers the DRP completely. But AWS clearly describes multiple options for DRPOpens a new window ranging from high availability with a recovery time objective (RTO) of less than five minutes to a simple backup and recovery option with an RTO of about an hour. These DRP models each come with different costs and efforts to implement. The more investment you make in your DRP, the more you can lower your potential for data loss and downtime. 

In a self-managed environment, the RTO could be much higher. For instance, the City of Baltimore was downOpens a new window for over two weeks during a ransom attack costing the city $18 million. A cloud network with a high availability backup location could have reduced the losses and RTO from weeks to minutes. It is important that organizations implement a formal backup plan that works best for their specific environment.

See More: Cloud Technology – A Key Enabler of Communication Service Providers Transformation

2. Not Having a Backup of the Backup

Know where your backups are stored. And when dealing with cloud services, your due diligence should include inquiry into the company’s backup storage procedures. If your backups are kept in the same physical location as the production servers, a fire could destroy everything at once. If your critical SaaS applications are backed up by the same vendor that offers the service, a catastrophic incident with that vendor could render those backups useless. If backups from your cloud environments are accessible from the same environment, using the same credentials, any attacker that compromises your production data could easily delete your backups. Even keeping a single backup in a different region is a risk if a disaster impacts that location. The best practice is referred to as “n+2” redundancy, where you keep two backups, each in a different regionOpens a new window , using additional logical segregation such as different accounts, credentials, or vendors to minimize the likelihood of simultaneous disasters impacting these separate environments. 

3. Not Backing up the Right Applications

One of the most challenging aspects of a DRP is ensuring the completeness of the applications in scope. A modern company may have hundreds of critical applications running at once. Understanding the scope, criticality, and usage of the applications is a daunting challenge, and the risk of missing a mission-critical applicationOpens a new window in the DRP is high. A complete inventory of the applications in use should be created to mitigate the risk, and new applications should be onboarded through an official process that includes documentation in the inventory and inclusion in the DRP with an appropriate backup schedule.

A business impact assessment (BIA) can be performed to identify mission-critical applications that would impact key business processes in the event of downtime or data loss. Another approach to identifying applications that belong in your DRP is to conduct a business continuity exercise, where you run participants through continuity scenarios and ask them to assess impacts on their critical business processes and gaps in their recovery capabilities. 

See More: VDI and DaaS: Security’s Best Kept Secret

4. Not Testing the Backup and Recovery Process

Even a perfect backup plan can fail if it is never tested. Backup files failOpens a new window due to corrupt data, lack of access or connectivity, or lack of storage capacity, and these issues can lead to a total loss. If there is a defect that gets into the backup data at some point, this can persist in every subsequent backup. Testing the entire process from backup through recovery regularly uncovers these problems before the disaster occurs. Many cloud services offer recovery simulation as a service, but regularly restoring from backup as a part of normal operations or performing manual DRP testing on a regular basis is considered best practice. 

Designing Your Cloud Disaster Recovery Plan

Disasters are unpredictable events, but the disaster planning mistakes discussed in this article are all avoidable. When designing your cloud DRPOpens a new window , budget enough for the recovery scenario that meets the business needs, and do not make assumptions about covered services. The details of the backup process and recovery testing should be explicitly described in your contract. Finally, build an inclusive disaster recovery plan that covers all critical applications and highlights clear roles and responsibilities for you and the cloud vendor. As we have learned in the last few years, the risk environment is changing rapidly with new and evolving disaster scenarios worldwide. We cannot afford avoidable mistakes.

Did you find this article helpful? Tell us what you think on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We’d be thrilled to hear from you.