Shared Responsibility: What the Provider Manages and What the Customer Retains

Moving to cloud transfers some work, not every responsibility

One of the most consequential cloud mistakes is assuming that the provider is “responsible for all security.” Shared responsibility means provider and customer duties differ according to the service being consumed. Across cloud models, the provider operates the physical infrastructure that delivers the service to different degrees, while the customer retains responsibilities related to its data, identities, configurations and use. As we move from IaaS to PaaS to SaaS, the provider manages more technical layers, but the customer does not become a party with no responsibilities.

IaaS: the provider protects the foundation; you operate the guest and what you put above it

Consider a virtual machine running on IaaS. The provider operates the data center, physical server and underlying infrastructure that supplies the VM. The guest operating system installed by the customer, the customer application, accounts and data require customer management according to the service. If a known vulnerability exists in the guest OS and the customer fails to apply a required update, the issue does not automatically become the provider’s responsibility merely because the physical machine belongs to the provider. Responsibility follows the layer each party manages. A team should therefore turn the service model into an operating list: who patches, who monitors, who reviews access and who tests recovery?

PaaS: the operating system moves to the provider, but code and data responsibilities remain

With PaaS, the application team generally does not operate the underlying OS as it would with IaaS, yet the team remains responsible for the application code it deploys, application configuration, data and access within its control. If the team writes code that lets an unauthorized user read data, the provider will not remove that design defect simply because it manages the operating system. The practical approach is to separate platform responsibilities from application responsibilities and assign controls to each. Lower server-operating burden is valuable, but it is not the same as eliminating responsibility for secure application design.

SaaS: the application is managed, but your accounts, data and decisions are still yours

In SaaS, the provider operates the core application and its supporting layers, but an important risk can still come from a simple customer setting: an account for a former employee remains active, a file is shared more broadly than intended, or an administrative role is granted to a user who does not need it. Those are customer-controlled choices. The review question must therefore go beyond “is the provider secure?” Ask whether the organization configured the service safely, reviews permissions, has a process for creating, changing and disabling accounts, and knows what kinds of data are permitted in the service.

To make the concept operational, create a small cloud responsibility matrix for every important service. Put layers or tasks in rows, then identify provider, customer, or a shared activity that requires coordination. Add the accountable team inside the organization and the evidence needed to verify the control. Do not copy a generic matrix and assume it matches every product; current service documentation is the authority for a specific offering. This course stays provider-neutral, so examples teach the questions to ask rather than asking you to memorize a vendor interface.

Summary: shared responsibility is a boundary map, not a slogan. In IaaS the customer operates more layers; PaaS shifts the OS and platform further to the provider; SaaS shifts the core application and its operating stack to the provider. Customer data, identities, permissions, available configuration and appropriate use still require customer decisions and controls. The most useful operating question is: “Who manages this layer, and what evidence shows that the control we rely on is actually implemented?”