Shared responsibility model: who secures what in the cloud

By LearnSome.tech · Published 2026-11-04

TL;DR

The provider protects the infrastructure that runs its cloud services, and your share of the security work is determined by the services you select. In IaaS the bulk of the security responsibilities are yours, and in SaaS the provider owns the bulk of them. For every cloud deployment type, you own your data and identities.

What is the shared responsibility model?

The shared responsibility model describes the security tasks you have in the cloud, and how they differ from the tasks of the cloud provider. AWS describes the model as security of the cloud and security in the cloud. AWS's side covers the hardware, software, networking and facilities that run AWS Cloud services.

Think of renting a flat: the landlord keeps the building standing and the front door lock working, and you decide who gets a key. That is the whole model in miniature, and the rest of this guide is about where the line sits for each kind of service.

Who is responsible for what in IaaS, PaaS and SaaS?

Your responsibilities vary depending on whether the workload runs on SaaS, PaaS, IaaS or in an on-premises data centre. Microsoft details the division of responsibility between you and Microsoft for each area of your stack:

Data: regardless of the type of deployment, you're responsible for your data, including classification, protection and encryption decisions.
Accounts and access: you're responsible for managing user accounts and for implementing and managing access controls, including multifactor authentication.
Applications: in IaaS you're fully responsible for deployed applications, and in PaaS and SaaS Microsoft manages parts of the application stack.
Network controls: in IaaS you configure all network security, in PaaS you configure application-level network controls, and in SaaS Microsoft manages network security.
Operating systems: in PaaS and SaaS, Microsoft manages operating systems, runtime environments and middleware.
Physical layers: Microsoft is responsible for the underlying cloud infrastructure, from data centres and physical hosts to the hypervisor.

Layer	IaaS	PaaS	SaaS
Your data	You	You	You
Accounts and access	You	You	You
Client devices	You	You	Shared
Applications	You	Shared	Shared
Network controls	You	Shared	Provider
Operating system	You	Provider	Provider
Hosts, hypervisor and data centre	Provider	Provider	Provider

Use the table to mark which rows are yours for each service you run, then give every one of those rows a named owner on your team.

What does it look like on a virtual machine (IaaS)?

On a virtual machine you manage the operating system and the software you deploy on it, including updates and security patches. For Amazon EC2, your side also covers controlling network access through your VPC and security groups, and managing the credentials used to connect. Azure's description of IaaS is that you manage virtual machines, operating systems and applications.

Here is a worked example for a small web shop on one virtual machine, written as a responsibility map you can copy for your own services.

# Worked example: a web shop on one virtual machine (IaaS)
service: Amazon EC2 or an Azure virtual machine
provider_runs:
  - the physical server, disks and network cables
  - the hypervisor the machine runs on
you_run:
  - patching the operating system and the web server
    # a flaw announced on a Friday stays open until your team patches it
  - security group or firewall rules
    # an admin port left open to the internet is your finding, not theirs
  - SSH keys and who still holds them
  - the shop's data, its backups and its encryption

What changes on a managed platform (PaaS)?

On a platform service you deploy applications without managing virtual machines or operating systems. Azure App Service, for example, secures and hardens its platform components, and regular updates of its VMs and runtime software address newly discovered vulnerabilities. On Google Kubernetes Engine, Google's responsibilities include hardening and patching the nodes' operating system, while you maintain your application code, container images, data and access policies. Amazon RDS documentation says to use security groups to control what IP addresses or Amazon EC2 instances can connect to your databases.

Here is the same web shop moved onto a platform service, as a responsibility map.

# Worked example: the same web shop on a platform service (PaaS)
service: Azure App Service or Google App Engine
provider_runs:
  - the servers, the operating system and the runtime
    # the Friday web server patch is now the platform's job
  - baseline network security
you_run:
  - the login code and its dependencies
  - secrets and connection strings in the app settings
  - who on the team can deploy or change settings
  - application-level network rules
    # for example, whether the database accepts connections from anywhere
  - the shop's data

What is still yours in SaaS?

In SaaS you remain responsible for your access controls and the data you choose to store in the application. Typical examples include Microsoft 365, Dynamics 365 and other cloud applications. Microsoft can provide some device management capabilities in SaaS, but you're responsible for endpoint protection and compliance.

Here is a worked example of a leaver in a SaaS email and document suite, as a responsibility map.

# Worked example: a sales manager leaves (SaaS email and documents)
service: Microsoft 365 or Google Workspace
provider_runs:
  - the application, its servers, storage and network
  - patches to the application itself
you_run:
  - disabling her account on her last day
  - who can still open the shared folders she owned
  - the old laptop that still has a signed-in session
  - the data your team chose to store in the suite
# If nobody disables the account, the leak is yours,
# however well the provider runs its servers.

What do people get wrong about shared responsibility?

Check your own estate for these mistakes.

Don't read managed as secured for you.
Even in PaaS and SaaS you're responsible for application configuration, code security and access controls.
Don't assume one split fits every service you use.
Your responsibilities vary with the services used, how they fit into your IT environment and the laws and regulations that apply.
Don't treat the provider's patching as covering your servers.
AWS patches flaws within the infrastructure, but customers are responsible for patching their guest OS and applications.
Don't leave incidents to the provider.
Incident management is an often overlooked area where your responsibilities and the provider's aren't easily defined.
Other incidents can result from poorly configured cloud resources or stolen credentials.

What should you check in each provider's documentation?

On AWS, review the security functionality and configuration options of each service in the security chapters of its documentation. For Amazon S3, your responsibility includes managing your data, classifying your assets and managing access to your data. AWS also suggests reviewing third-party audit attestation documents to find inherited controls and the required controls left for you to implement.

Microsoft notes that its article is illustrative guidance and is not intended to modify or contradict the terms of any agreement between you and Microsoft. For Google Kubernetes Engine (GKE), Google's shared responsibility document explains the shared security responsibilities for both Google and Google Cloud customers. The approach Google calls shared fate includes helping you start with a secured landing zone and being clear about recommended security controls.

For each service on your bill, write down who patches the operating system, who sets the network rules, who holds the keys and who leads when something goes wrong. Any row you can't fill from the provider's page is a question for your team, not a gap you can leave.

Free official resources

The AWS Shared Responsibility Model page states that security and compliance is a shared responsibility between AWS and the customer. Microsoft's Azure article on shared responsibility explains which security tasks the cloud provider handles and which tasks you handle. A Google Cloud document describes the differences between the shared responsibility model and shared fate in Google Cloud.

Microsoft Learn has a module that introduces cloud computing and covers cloud concepts, deployment models and understanding shared responsibility in the cloud.

From our labs

In our AWS Cloud Practitioner course, you place security tasks on AWS's side or the customer's side of the shared responsibility model. You then say how the line moves between Amazon EC2, Amazon RDS and AWS Lambda. In a later sprint, you answer security and compliance questions across all four task statements at exam pace.

Start the free lesson: The Night Larder Could Not Buy Servers Fast Enough (AWS Certified Cloud Practitioner (CLF-C02) Exam Prep)

The course: AWS Certified Cloud Practitioner (CLF-C02) Exam Prep

Terms in this guide

Sources

Written by the LearnSome.tech team with AI assistance; every fact checked against the cited source.