Cloud Shared Responsibility Model: Who Secures What

The cloud shared responsibility model is the principle that, when an organization uses the cloud, the cloud provider and the customer each secure different parts of the service. The dividing line is not fixed. It moves with the type of service you use. AWS, Microsoft Azure and Google Cloud each explain the principle in their documentation. This article summarizes who is responsible for what, and what an organization should do about its own share.

Security of the cloud and security in the cloud

AWS says it protects the infrastructure that runs all of its services: the hardware, software, networking and facilities. For the customer's side, AWS says responsibility depends on the services the customer selects. The CSA (Cloud Security Alliance, a body that publishes cloud security guidance) uses the same pair of terms: the provider secures the cloud, and the customer secures what is within the cloud.

• Cloud provider: secures the hardware, networking and facilities behind the service
• Customer: secures what it places and configures on that service, such as data, access permissions and software it installs itself

Three service types: IaaS, PaaS and SaaS

The dividing line moves with the type of service. Microsoft describes the three types as follows:

• IaaS (infrastructure as a service): the customer manages virtual machines, operating systems and applications. An example is Azure Virtual Machines
• PaaS (platform as a service): the customer deploys applications without managing virtual machines or operating systems. Examples are Azure App Service and Azure Functions
• SaaS (software as a service): the customer uses ready-made applications. An example is Microsoft 365

Compared with your own datacenter, where the organization owns every layer, Microsoft explains that moving to the cloud transfers some responsibilities to the provider. Going from IaaS to PaaS to SaaS, the provider takes on more and the customer's workload shrinks, but it never reaches zero.

What the customer always keeps

Microsoft states that, whatever the service type, the customer still owns these four things:

• Data: classify data, protect it, and make the encryption decisions
• Endpoints: protect the devices used to reach cloud services, such as phones, laptops and desktops
• Accounts: create, manage and remove user access
• Access management: set role-based permissions, use MFA (multi-factor authentication), and define conditional access policies (rules on who may sign in under which conditions)

What changes with the service type

In Microsoft's responsibility table, the parts that differ by service type are:

• Operating system: the customer's in IaaS; Microsoft's in PaaS and SaaS
• Network controls: the customer's in IaaS, shared in PaaS, Microsoft's in SaaS
• Applications: the customer's in IaaS, shared in PaaS and SaaS
• Client devices: the customer's in IaaS and PaaS, shared in SaaS
• Physical hosts, physical network and datacenter: Microsoft's in all three cloud types

AWS and Google Cloud describe it the same way. AWS gives Amazon EC2 (a virtual machine service) as an example where the customer performs all the security configuration and management, including updates and patches to the guest operating system. For services where AWS operates the infrastructure layer, operating system and platform, such as Amazon S3 (file storage), the customer still manages data, encryption and permissions in IAM (AWS's identity and permissions system). Google Cloud says that in IaaS the customer handles most security tasks, in PaaS Google handles more, and in SaaS Google handles most of them. Both agree that the provider always remains responsible for the underlying network and infrastructure, and the customer always remains responsible for its access policies and data. So look at the line for each service, not just at the provider's name.

Shared parts, and who owns each control

AWS groups controls into three kinds: those the customer fully inherits from AWS (for example physical and environmental controls), shared controls, and controls that belong only to the customer depending on its application. AWS gives these examples of shared controls:

• Patch management: AWS patches the infrastructure; the customer patches its guest operating systems and applications
• Configuration management: AWS configures its infrastructure devices; the customer configures its own operating systems, databases and applications
• Awareness and training: AWS trains its employees; the customer trains its own

In the CCM (Cloud Controls Matrix, the CSA's catalog of cloud security controls), the CSA sorts control ownership into four kinds:

• Provider-owned: the provider alone implements it
• Customer-owned: the customer alone implements it
• Shared but independent: both parties have a role, and each implements its part without relying on the other
• Shared but dependent: implementation hands off from one party to the other

The CSA stresses that the shared area is often the least clear, and that the line depends on the service type, the specific control and the contract terms, so roles should be agreed at the start. Microsoft's document likewise says its table is illustrative guidance, not a legal conclusion, and does not modify any agreement with Microsoft. Read the provider's contract and documentation alongside it.

Google Cloud proposes an extension called shared fate, arguing that the shared responsibility model stops short of helping customers achieve better security outcomes. Google therefore offers secure starting blueprints and extra governance tools. The NSA (the US National Security Agency) published a sheet in March 2024 on upholding the model, warning that customers often wrongly assume the provider handles things that are in fact the customer's job (we could not read the full document; this relies on secondary summaries).

How to apply it in your organization

These steps work with any provider:

• List your cloud services: identify which services the organization uses and whether each is IaaS, PaaS or SaaS
• Read the documentation and contract: see how the provider divides responsibility for that service
• Build a control-ownership table: name who is responsible for every control, including the shared ones (the same idea the CSA applies to the CCM)
• Check the customer-side configuration: keep reviewing permissions, encryption and internet exposure
• Review when you adopt a new service: the line changes with the service selected, so look again each time

Continuous checking of configuration is the job of CSPM; see What Is CSPM? Finding Cloud Misconfigurations. For SaaS services, see SaaS Security and SSPM. For the principle of trusting no access automatically, see What Is Zero Trust, and Where Should You Start?.

Common mistakes

• Assuming the provider secures everything once you move to the cloud: data, accounts and permissions always stay with the customer
• Using one dividing line for every service: IaaS, PaaS and SaaS split the work differently, even within one provider
• Not reading the documentation and contract for the services in use: the real line is in each service's documentation
• Not checking the customer-side configuration: for example access to storage and user accounts
• Leaving shared controls with no owner: each side may assume the other is doing it
• Overlooking endpoints and user accounts: Microsoft states that the customer is always responsible at least in part for these

Start today

• Pick your three most important cloud services: note whether each is IaaS, PaaS or SaaS
• Open each provider's shared responsibility page: note which parts are yours
• Assign owners: give every service someone responsible for data, accounts and configuration
• Check MFA on cloud administrator accounts: this is always the customer's side
• Set a review cycle: revisit the ownership table each time a new service is adopted

To see how well your organization covers its own share in the cloud, try the self-assessment.

References and further reading

• AWS Shared Responsibility Model: security of and in the cloud; inherited, shared and customer-specific controls
• Microsoft: Shared responsibility in the cloud: the IaaS, PaaS and SaaS responsibility table
• Google Cloud: Shared responsibility and shared fate: the split by service type, and the shared fate idea
• CSA: Implementing the Shared Security Responsibility Model in the Cloud: the four kinds of control ownership
• CSA Cloud Controls Matrix: a control catalog that defines provider and customer roles
• NSA: Uphold the Cloud Shared Responsibility Model (PDF, March 2024): the NSA information sheet