No matter what latest disaster is going on in the world, we expect businesses these days to stay up, active, and accessible at all costs. To better your odds of continued operation no matter what, you may have already put together some kind of disaster recovery (DR) plan. However, if you’re like most businesses today and make extensive use of SaaS applications for providing your products and services, then your DR should include steps specifically for recovering the critical data that these SaaS services store.
To ensure that you’ve got a solid plan to recover your SaaS data, this article takes you through a detailed checklist for testing your disaster recovery plan for SaaS data.
Why do you need a Disaster Recovery Plan for SaaS data?
When you build your own software, you handle everything—data privacy, security, reliability, all of it. However, most companies can’t afford to build their own software, and most companies simply shouldn’t anyway. Building software requires a level of product and technology expertise that may not be the core expertise of the business.
Therefore, SaaS products are a great option for many companies who need technical solutions. The caveat is that dependence on a SaaS application means dependence on the SaaS app’s DR plan.
To ensure business continuity for yourself, you need a SaaS data backup solution.
Although some SaaS products might offer backup and restore solutions to some extent, most of them will lack the fine-grained recovery controls that give you access to incremental point-in-time and partial backup and recovery options. Many could be better at providing full data visibility via detailed audit logs. Some just might not guarantee that your data is safe with them at all.
It’s essential to have a disaster recovery plan for each of the SaaS products you rely on (think tickets in Jira or repos in GitHub or Bitbucket) And if you don’t have a plan, the next section should still give you insight into creating and testing a DR plan specifically for SaaS data. Let’s dive in.
How do you test a Disaster Recovery Plan?
To effectively test your DR plan, you have to understand which functions of your business you’re trying to secure, the different types of disasters you’re guarding against, and the various cost and accountability considerations of executing such a plan. The following checklist should help you focus your efforts in each of those areas.
Organize a tabletop test of your DR plan
First, put every idea and method on the table in front of everyone to be discussed and scrutinized. This tabletop test gives every stakeholder an opportunity to discuss how to proceed with disaster recovery. It’s important to involve people from all the business functions you cover in your DR plan, but keep in mind that not all business functions are critical for bare minimum business operations. It’s possible that not all teams will be represented in this meeting.
Be sure to discuss internal and external dependencies that might hinder or prevent the DR plan from being fully effective or even happening at all. Resolving these dependencies before putting the plan in place is critical.
This meeting lays the foundation of the disaster recovery plan, so ensure that it’s documented thoroughly. Relevant stakeholders and participants should sign off on the documentation to avoid confusion.
Create accountability lists
An accountability list, much like an escalation matrix, puts names to responsibilities. This identifies who is on call if this or that disaster disrupts your business. These are the people responsible for executing different phases of the DR plan.
An accountability list should be clearly delineated in your DR plan so that even newer team members are aware of who’s going to be doing what in an emergency.
Scope the types of disasters
There are more ways things can go wrong than there are for things to go right. Still, you can’t plan for everything; you have to decide which disasters are most likely. Let’s look at a few of the more common types of disasters that can affect SaaS data recovery.
Malware attacks
Any software is prone to malicious attack from bad actors, and SaaS providers are no different. While SaaS providers might have their own preparations for handling such attacks, there are usually limited guarantees around the safety of your data in their systems. A malware attack, like the one that happened in late 2022 at LastPass, can not only corrupt part of your data, but it can also erase all of it from your system or download it and sell it.
Data center outages
Data center outages are more common than you might think. That’s because most outages are resolved within minutes and don’t impact business drastically. However, you should still be prepared for extended outages due to loss of power, security breaches, or natural disasters.
You can mitigate their impact by ensuring that your applications and data are at least in more than one place. Continuous data replication, hot standbys, and multi-region deployments are some of the common strategies. You can also design your application so that an outage only degrades the user experience gracefully. Edge computing and content distribution networks (CDNs) can help you there.
Third-party provider outages
As a user of a SaaS product, you might not be fully privy to every attack on your third-party provider, but you can be sure they’ll have their share of outages, too. So before you commit to a third-party provider, it’s important to assess how they might handle a disaster that affects their clients (aka, you).
- Make sure your vendor provides a health check or a product-wide status page for all components and services. Think GitHub Status or Twitter API Status pages.
- Look for transparency about any attacks the product has suffered. For regulated SaaS products, such as those that deal with finance or newsgathering for example, it could be mandatory for them to publish the incident with a report within a certain timeline. Even for unregulated SaaS products, you should look for third parties that promise a certain level of transparency with their customers by publishing every incident.
- Look for SaaS platforms that have reputable certifications, such as SOC 2, PCI-DSS, HIPAA, and GDPR, and app-marketplace awards (such as G2, Atlassian-featured apps, and so on).
Understand the cost of downtime and lost or corrupted data
Downtime in your business can result in severe losses, not just financially but also in terms of professional reputation. This is why businesses do and should put serious effort toward preventing data loss and corruption due to disasters, manmade or otherwise.
When a SaaS product is tightly integrated into your processes and workflows, it can have tremendous influence over your users’ experience with your product. Atlassian’s fourteen-day outage in April 2022 is one such example, which ended up affecting over 50,000 users. The downtime resulted in the revocation of access to critical SaaS products like Jira, Confluence, and Opsgenie. It also resulted in the loss of data.
By Atlassian’s own calculation, the average cost of downtime to customers is $5,600, but the actual cost does vary from business to business. While SaaS products do have disaster recovery plans of their own, those plans cover the platform as a whole, and typically aren’t set up to restore data on individual accounts (known as the Shared Responsibility Model). Businesses should definitely have their own plans to tackle the downtime of critical SaaS software in order to minimize, or hopefully prevent, data loss.
Of course, preparing for such an event will incur costs on multiple levels, so be sure to carefully consider what failsafes you want to invest in and to what extent. A couple good places to start include:
- Building resilience into your applications with backup systems if one vendor goes down.
- Designing your applications to degrade gracefully and keep critical operations up, even when part of the app isn’t functional.
Conclusion
A solid disaster recovery plan is a great first step to safeguarding against data loss or corruption from a SaaS provider. At a glance, your checklist for testing your DR plan should look something like this:
- Understand why you need a disaster recovery plan.
- Confirm with relevant stakeholders what business functions you want to protect and secure.
- Decide on the internal and external tooling required to carry out a disaster recovery plan taking into consideration the security and privacy of your SaaS data.
- Create clear and relevant accountability lists that illustrate who’s on call for what and in what situations.
- Scope the types of disasters you’re planning for, because you can’t plan for everything.
- Document the plan, make it easily accessible, and have the proper stakeholders sign off on it.
Interested in a downloadable version of this checklist? You’re in luck.
Rewind is an on-demand backup and restoration solution that helps you continuously back up data and recover it quickly when someone commits a mistake or a disaster strikes. Rewind deals with a wide variety of SaaS products, so it’s familiar with the challenges of transferring data from one place to another. Rest assured that your data is safe; Rewind complies with several security regulations including SOC 2, SOC 3, and CCPA.
How many GitHub users are in your organization?
How many Bitbucket users are in your organization?
James Ciesielski">
