No, magic backup people aren't protecting your SaaS data
Are your SaaS-based applications protected? Organizations that rely on the SaaS vendor for backup and recovery face a tough road ahead. Don't skimp on internal backup measures.
The disconnect between IT leaders and SaaS vendors is real and could end up costing your organization a lot of money.
According to "Data Protection for SaaS," a recent research report by TechTarget's Enterprise Strategy Group, about 33% of IT leaders using SaaS rely on the vendor to protect their SaaS-resident application data. Another 45% believe they are partially responsible for protecting their organization's data and rely both on the SaaS provider and a third-party data protection tool or service.
Most organizations today use SaaS to consume what was once an application in the data center, or even on an application in the public cloud. Using a "ready-made" service that is still configurable and managed by a third party has many advantages.
SaaS and mission-critical data
As a matter of fact, the same research shows that 66% of respondents prioritize and use SaaS applications when possible instead of developing their own. According to vendors and friends in the industry, there is a general agreement (not covered in the above research) that most organizations use dozens of SaaS applications, if not hundreds for larger enterprises, to cover their many functional needs.
Many of these SaaS applications are critical to the business. I would argue all data in the business should be protected, but let's agree for the sake of the argument that there is a pecking order and that some applications are more equal than others. If a SaaS application falls in the mission-critical bucket, then it means certain stringent requirements apply for service levels in general and backup and recovery in particular.
Our research shows most of you agree that some well-known SaaS applications are critical, such as Microsoft 365, Microsoft Dynamics, Salesforce, ServiceNow, Google Workspace, Workday and Zendesk to name a few we ran research on. There are, of course, many more.
Let's start with a few observations that should not shock anyone:
If there is private data or personally identifiable information in an application, it's critical for compliance reasons.
It's "your" data. Your organization decided to consume the functional application as a service, but it's your organization's data.
This means you are responsible for the data and for ensuring it is adequately backed up and recoverable.
Where does the responsibility for SaaS data really lie?
Let me break the news to the 33% of IT professionals I mentioned at the top of this blog: The SaaS vendors are not responsible for your data, they will not back it up for you and there are no magical backup people doing it for you. That's what I call the big SaaS data protection disconnect.
SaaS vendors are not responsible for your data, they will not back it up for you and there are no magical backup people doing it for you.
SaaS vendors will protect themselves and apply best practices to backups and make their service as available and recoverable as possible, but it's their business they are protecting. If you delete data by mistake and don't realize until it is not recoverable, it's on you.
Our research shows it's easy to lose SaaS data. Among the most common reasons the respondents cited are, in order: SaaS provider outage or unavailability, malicious deletion from cyber attack, accidental deletion, account closure, insufficient or deficient backup mechanism, current backup vendor not supporting the specific SaaS application(s), misunderstanding of retention/deletion policies, malicious deletion by employee, and schemas misconfiguration or bad schema update.
Shared responsibility requires sharing the backup load
With such a list in mind, let's talk about the 45% who claim they leverage the shared responsibility model and use a third-party backup tool or service.
First, using a third-party backup option is the right answer as long as you internally protect all of your mission-critical SaaS applications. Most backup vendors today do not support more than a few SaaS applications, and you may need to use multiple vendors. Also, there are many SaaS applications that do not have any vendor officially claiming support for them. Second, backup vendors have fallen behind in providing fixes for these issues. Luckily, that's an opportunity that many are starting to seize.
The idea of a shared responsibility model is not new; it's fundamentally a contract with more or less negotiation room. It might be perfectly fine if you truly understand the service-level agreements (SLAs). Most IT professionals told us that they do, but I don't buy it. You can see from the data loss list above how many of these causes are purely service-related.
Let's take account closure for example: Why do you think a third-party vendor is going to keep your data after you close your account? It costs money to manage and store data! Another area of confusion and disconnect around SLAs is service availability. IT professionals tend to confuse or conflate service availability with high availability and backup.
The good news is IT professionals are prioritizing efforts to improve their SaaS data protection capabilities. Protecting SaaS applications is a top IT priority for more than four in ten organizations, and another 45% report it is in their top five priorities. Building a resilient SaaS data protection infrastructure that includes the right vendors for all mission-critical data and applications will take time, but it is in motion. As an IT professional it is a topic you can't ignore.
