Shared responsibility in cloud security

In cloud computing, providers and customers divide security tasks. The shared responsibility model describes which security tasks providers handle for the infrastructure and services they operate, and which tasks customers handle for the data, access, settings, and workloads they control.

The split depends on the service. Customers manage more with a virtual machine than with hosted software, and fully managed services still leave customers with security decisions.

How service type shifts responsibility

Cloud services are often grouped as infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS). These categories show how much of the underlying technology the provider operates. They offer a useful starting point, but the exact responsibilities depend on the specific product and its configuration.

With IaaS, the provider operates physical facilities and servers, along with the core infrastructure. The customer typically manages the virtual machine’s operating system and installed software, as well as network settings. For example, AWS says customers using its EC2 virtual machines handle guest operating system patches and installed applications, as well as security group settings.

With PaaS, the provider manages more of the underlying platform. The customer still manages its data and user access. It also manages the application code and settings that control how the service is used. With SaaS, the provider operates most of the application stack, but customers still need to manage their accounts and permissions, as well as the data they store.

Check the provider’s responsibility documentation for each service instead of relying on the IaaS, PaaS, or SaaS label alone. A managed database and a virtual machine from the same provider place different tasks in the customer’s hands.

What customers still control

Some responsibilities remain with customers across service types. These commonly include deciding who can access data, assigning permissions, configuring available security settings, and protecting the devices people use to connect. Microsoft and AWS guidance includes these duties in the customer’s role and notes that the exact division depends on the service.

Consider a company storing customer records in a cloud database. The provider may operate the database infrastructure, but the customer still needs to decide who can read or change the records and classify the information. The customer also needs to configure available protections. If a user account has excessive access, the provider’s management of the underlying infrastructure does not correct that customer-side choice.

Customers also need to review the code and connections they bring to a cloud service. A provider can secure its platform, but it does not automatically make customer-written code safe or ensure that an outside service receives only the data it needs.

Where responsibilities overlap

A responsibility matrix shows who owns each security control, or safeguard, but some security work requires cooperation. During an incident, the provider may have information about its infrastructure, while the customer knows which data and business services were affected. The two parties need a clear way to share relevant information and coordinate their response.

Compliance also involves both sides. A provider may operate security controls and offer audit evidence. The customer must determine which requirements apply, check whether the service and its location meet them, and configure the service to match. A responsibility chart can help organize this work, but it does not settle legal obligations. Microsoft describes its own matrix as governance guidance, not a replacement for contract terms or legal advice.

Providers also promote approaches that go beyond assigning control owners. Google Cloud’s “shared fate” framing, for example, emphasizes secure defaults and guidance. It also emphasizes closer collaboration. Those features can help customers make safer choices, but customers still need to understand which settings they control and who must act when something is misconfigured.

Assign owners before launch

For each cloud service, record the customer’s responsibilities and name the role that will handle them. A useful review starts with the exact service and its provider documentation. It checks the data and access settings, along with any customer-managed components in use. It should also state how the customer and provider will coordinate during a security incident.

Keep that record current when the service changes. Adding a new cloud product, changing how users access it, or connecting it to another service can shift which controls matter and who can act on them. If a provider’s documentation or contract leaves an important task unclear, resolve that question before relying on the service for sensitive data.

The U.S. Government Accountability Office’s March 2025 report identified clear security ownership as a leading practice. Sixteen of 18 selected companies said they used the practice and considered it very or extremely important. The small, selected sample cannot show how common ownership problems are across all cloud customers, but it illustrates why organizations document the division rather than assume it is understood.

What the model cannot prove

A shared responsibility model describes operational duties. It does not, by itself, show who caused a breach or decide whether a provider or customer met a legal obligation. An incident involving a misconfigured setting, for example, still requires investigation into who controlled that setting, what the provider promised, and how the parties used the service.

Cloud security surveys also need careful interpretation. Surveys cover different groups, time periods, and definitions, so their breach figures cannot be combined into one overall rate. A reported configuration problem does not by itself show which party owned the failed safeguard.