There’s no going back. The cloud, and especially software as a service (SaaS), has become the default for the way we work. The trend of moving from on-premises to on the web was already moving at a rapid pace before the global pandemic. COVID-19 simply sped up the adoption. Companies that spend decades working in a physical location can now have employees log on from anywhere they can find Wi-Fi.
However, this newfound freedom comes at a cost. This cost is not widely discussed among the DevOps and IT crowd, yet it’s a common risk that’s inherent to most SaaS applications.
Not understanding this risk, and how to mitigate it, means companies could easily lose all the critical data they are entrusting to online software solutions.
The Shared Responsibility Model and SaaS
IT staff and data protection professionals used to have a well-used phrase: There are two types of people in this world — those who have lost data and those who are about to lose data. It’s inevitable that at some point in our personal or professional lives, some kind of data loss will occur.
If you have used Amazon Web Services at least once, you are likely familiar with the shared responsibility model. Here’s the thing though, this model actually governs all of cloud computing. It doesn’t matter if you are using IaaS, Paas or SaaS tools, users share a certain level of responsibility for protecting the data they create.
Here’s the key question to ask: Is the value you are getting from this app worth the level of data access this app has?
I’ve been working in technical operations for over 25 years, since the birth of SaaS. The shared responsibility model was not something that was discussed. And for the most part, it still isn’t. The model essentially works like this: SaaS providers generally guarantee that their infrastructure and network will always be up and running. This means that every time a user logs in, the software will be available to use. They also guarantee that they can restore their service in case of a catastrophic failure, such as a meteor strike on a data center. This is where a SaaS company’s responsibility ends.
You, as the user of a SaaS tool, are responsible for ensuring that only authorized users have access, and any data or metadata that is created is properly backed up. And trust me, your SaaS data can disappear. Cyberattacks, human error and even other software integrations can all wreak havoc with your proprietary information. It’s important to remember that companies just rent access to SaaS infrastructure and access everything through an API. You don’t own anything except the data and the intellectual property you create.
In the slim chance a SaaS operator can restore your data, it will likely be outdated and incomplete. Most SaaS tools have not been built to include data restoration capabilities of your specific data. They can restore the entire platform, but usually not your data. If you are skeptical about this (I know I was), read the terms and conditions of any major SaaS tool. Here is the TOC for GitHub, the largest code repository in the world. It explicitly states that they aren’t on the hook for data loss.
So what is a DevOps or IT team to do? The same things they have done for decades with on-premises or other cloud applications: Put a backup strategy in place.
A Backup and Data Continuity Strategy for SaaS
The first step is already common practice in many organizations: Limit the access people have in various applications. In other words, your customer success manager likely does not need access to GitHub. Restrict access to these platforms using the least-privileged approach based on user qualifications, and ensure everyone has a unique password or phrase for logging in. Don’t forget two-factor authentication (2FA)!
Next, always audit third-party apps connected to your SaaS tool of choice. Often they can overwrite or make changes to existing data. Here’s the key question to ask: Is the value you are getting from this app worth the level of data access this app has? If not, you may want to find an alternative or uninstall it. Compliance standards like SOC2 have a “vendor assessment” component for a reason: Third-party vendors or apps are often the most common form of accidental data loss.
Finally, you need a process for backing up and restoring lost data. There are essentially two ways to do this: Manage the process yourself or use a backup-as-a-service solution. Managing the process yourself looks different based on the type of SaaS you’re using. For Shopify, that could involve exporting an endless amount of images and CSV files. For GitHub, this can involve running backup scripts. And make sure to do this regularly. How helpful is a CSV dump from two months ago on a high-traffic e-commerce store?
Regardless of the SaaS tool, this will involve a significant amount of manual work. The danger here is that teams often think this will be a more cost-effective option. The reality is that the ongoing labor and maintenance tend to add up quickly. Cycles are spent on tasks that are not the core business.
Outsourcing this process is definitely a higher financial cost, but the automation frees up your team’s time. The BaaS provider also manages all the API changes, which can happen often, made by the platform. Just make sure you do your due diligence. Many backup and restoration solutions pop up quickly with very little transparency into how they access and secure your data. Look for a vendor with a strong security program and ideally, an externally audited compliance certificate such as SOC2 or ISO27001.
Whatever path you choose, I hope it’s now self-evident that the convenience of SaaS tools comes at a cost. They make things faster, better and cheaper, but they also have a glaring data-continuity issue that puts your day-to-day operations at risk. Ensuring that only the right people have access and implementing a backup strategy will help ensure your business is always up and running.
InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Rewind.
Amazon Web Services is a sponsor of InApps.
Feature image via Pixabay.
