AWS Shared Responsibility Model and SaaS: Explained

May 10, 2025 — 6 min read

Origins of the Shared Responsibility Model

In the early days of IT, businesses managed everything in-house—from servers and firewalls to storage, security, and backups. If something went wrong, the responsibility clearly fell on the company, since they controlled the entire infrastructure.

That all changed when AWS launched in 2006 and ushered in the era of cloud computing. Suddenly, you could rent infrastructure and scale instantly, eliminating the need to invest in costly hardware upfront. This shift gave rise to Infrastructure as a Service (IaaS), where providers like AWS deliver the foundational building blocks—compute, networking, and storage—on demand.

As businesses grew more comfortable with IaaS, new layers of abstraction emerged. Platform as a Service (PaaS) simplified development by managing the underlying infrastructure, operating systems, and runtime environments—allowing teams to focus purely on code. Eventually, Software as a Service (SaaS) took things a step further by delivering fully managed applications over the web, like Salesforce, Slack, or Google Workspace, removing the need for customers to manage any backend at all.

This evolution enabled faster innovation and reduced operational overhead—but it also introduced new questions around security and accountability. The Shared Responsibility Model was introduced by AWS to define where the cloud provider’s job ends and yours begins, clarifying who is responsible for what in this new, layered environment.

image

How does the Shared Responsibility Model work?

At the IaaS and PaaS levels, cloud providers handle the infrastructure—things like servers, networking, and in the case of PaaS, the operating system and runtime environment. Customers are responsible for everything built on top: configuring services securely, writing secure application code, managing user access, and protecting their data. While these models reduce the need to manage hardware or system updates, misconfigurations and poor access control can still leave you exposed.

With SaaS, the provider manages nearly everything: the infrastructure, the app itself, and all backend operations. You simply use the software. But your responsibilities don’t go away—they shift. You're still accountable for how your organization uses the service. That includes configuring settings, managing user permissions, enabling MFA, and protecting the data you put into the system. If sensitive data is mishandled, shared inappropriately, or exposed due to weak account controls, it’s still your responsibility, even if the SaaS platform is secure. In regulated industries, this often means ensuring compliance on your end, even when the provider offers compliant infrastructure.

Why does the Shared Responsibility Model matter?

SaaS adoption has skyrocketed, increasing the volume of high-value data in the cloud. Who ensures its protection? The business does. Under the shared responsibility model, vendors provide the service, but organizations must back up their own data. Many SaaS providers even recommend using a third-party backup solution.

One example of how a SaaS provider explains the Shared Responsibility Model to its users can be found in Slack’s Terms of Service:

NEITHER SLACK, NOR ANY OF ITS OFFICERS, DIRECTORS, EMPLOYEES, LICENSORS, OR AFFILIATES SHALL BE LIABLE TO YOU OR ANY THIRD-PARTY FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, PUNITIVE, OR EXEMPLARY DAMAGES ARISING FROM OR RELATING TO YOUR PARTICIPATION IN SLACK COMMUNITY FORUM, INCLUDING, WITHOUT LIMITATION, LOST REVENUE, DAMAGES FOR LOSS OF PROFITS, GOODWILL, USE, DATA, OR OTHER INTANGIBLE LOSSES HOWEVER CAUSED, WHETHER IN CONTRACT, TORT OR UNDER ANY OTHER THEORY OF LIABILITY, AND WHETHER OR NOT THE PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Another example can be found in the warranty disclaimer in Microsoft’s Terms of Service:

We strive to keep the Services up and running; however, all online services suffer occasional disruptions and outages, and Microsoft is not liable for any disruption or loss you may suffer as a result. In the event of an outage, you may not be able to retrieve Your Content or Data that you’ve stored. We recommend that you regularly backup Your Content and Data that you store on the Services or store using Third-Party Apps and Services.

SaaS providers make it clear: they are not responsible for backing up and protecting your data. In order to guard against data loss, you need external backup for the files and data you store on any SaaS applications.

The risks to your SaaS data

Storing data in the cloud doesn't make it immune to loss. In fact, the most common threat to SaaS data isn't a technical failure—it's human error. Accidental deletions of files, folders, or records by employees happen all the time, and even with built-in undo features, recovery isn’t always guaranteed. There's also the less frequent but very real risk posed by former employees who retain access to business apps. If offboarding isn’t handled carefully, someone with leftover credentials could intentionally tamper with or delete critical data.

Even the SaaS platforms themselves can be a source of risk. Providers may suspend accounts or remove content if they believe you’ve violated their terms of service, sometimes with little warning or recourse. And then there’s the ecosystem around your SaaS tools—many apps connect to others via APIs and integrations. While convenient, this interconnectedness can open the door to vulnerabilities. If a third-party integration is compromised, your data could be exposed or altered. Add to this the growing threat of ransomware, phishing, and other cyberattacks, and it's clear that relying solely on your SaaS provider for data protection isn't enough. The Shared Responsibility Model doesn't extend to any of these scenarios—meaning it's up to you to ensure your data is backed up and recoverable when things go wrong.

How to protect your SaaS data

Now that you’re aware of the potential issues and risks, here are a few crucial steps you can take to ensure the safety of your data:

  1. Complete a data audit. Know exactly what information you're storing in each SaaS application, and review the terms of service to understand what the provider is—and isn’t—responsible for.
  2. Implement the “least-privilege access control”. Configure accounts so that team members only have access to the specific tools and data required for their roles. Strengthen security by enforcing unique passwords and enabling multi-factor authentication.
  3. Backup and store your data remotely. The best way to do this is to choose a third-party backup provider who will automate daily or hourly backups, encrypt and isolate your data, and retain encrypted copies on remote servers. If the worst happens and your SaaS data is lost or corrupted, having third-party backup that is capable of granular restoration will limit the damage and disruption caused to your business.

Seroscale can backup and protect Slack. To get a free 14-day trial, sign up today.