Cloud shared responsibility model
The provider secures the hardware, the facilities and the platform underneath managed services. You secure identity, data, configuration and everything you deploy. The line moves with the service, and a questionnaire will ask you to draw it.
Under the shared responsibility model, the cloud provider is responsible for the physical data centre, the hardware, the network backbone and the hypervisor. You are responsible for who can access your account, how resources are configured, how data is classified and encrypted, and the code you run. Between those, the split depends on the service: the more managed the service, the more the provider takes on.
How the line moves by service type
| Layer | Virtual machines (EC2, Azure VMs, Compute Engine) | Managed databases and containers | Serverless and SaaS-like services |
|---|---|---|---|
| Physical facility and hardware | Provider | Provider | Provider |
| Hypervisor and host OS | Provider | Provider | Provider |
| Guest operating system and patching | You | Provider | Provider |
| Runtime and platform patching | You | Mostly provider | Provider |
| Network rules | You | You | You, where exposed |
| Application code and dependencies | You | You | You |
| Identity and access | You | You | You |
| Data classification and encryption choices | You | You | You |
Three rows never move: identity, data and your own code. That is why auditors spend their cloud time on access, encryption and change management, whichever services you use.
How each provider describes it
- AWS
- "Security of the cloud" for AWS, "security in the cloud" for you. AWS publishes the split per service in each service's security documentation.
- Microsoft Azure
- A responsibility matrix across on-premises, IaaS, PaaS and SaaS columns. Identity, data, accounts and devices are always the customer's.
- Google Cloud
- Calls it shared fate: the same division of duties, with Google adding secure defaults, blueprints and a stated intent to help customers configure correctly.
How it appears in an audit
In a SOC 2, the provider is a subservice organization. Your system description names it, your auditor relies on the provider's own SOC 2 report for its layers, and the provider's report lists complementary user entity controls that it assumes you perform. In ISO 27001:2022, control 5.23 (information security for use of cloud services) asks you to define exactly this split and manage it. Both reduce to the same question: can you show which controls you inherit and which you run?
Write your own matrix
A one-page table listing each control area, who owns it, and the evidence for each, answers most questionnaire questions about cloud security in one attachment. It also becomes the ISO 27001 cloud services record and a section of your SOC 2 system description.
Answering the questionnaire question
Security questionnaires ask some version of "describe how responsibility for security is divided between you and your hosting provider". A good answer names the provider and region, says the provider's SOC 2 and ISO reports cover physical and platform security, and lists what you run: identity with MFA, encryption, logging, backups, vulnerability management and change control. The questionnaire guide has model answers.
Where the gaps usually are
- Managed does not mean configured. A managed database is patched by the provider, but public network access, backup retention and encryption keys are still settings you chose.
- Default settings are yours. If a default is weak and you left it, that is your control failing, not the provider's.
- Your SaaS tools have their own split. GitHub, Datadog and your identity provider are separate subservice organizations with separate reports.
What is the shared responsibility model in simple terms?
The cloud provider secures the infrastructure your services run on, and you secure how you use it: accounts, access, configuration, data and code. The exact line depends on whether you use virtual machines, managed services or serverless.
Does the provider's SOC 2 report cover my application?
No. It covers the provider's own controls over its infrastructure and services. Your auditor uses it to avoid re-testing the data centre, then tests your configuration and processes separately.
Is patching the operating system my job on managed Kubernetes?
Partly. EKS, AKS and GKE patch the control plane. Worker node images and upgrades are shared, depending on whether you use managed node groups, auto-upgrade or serverless nodes. The container images you run are always yours. Kubernetes compliance covers the detail.
Need someone to draw the line for your estate?
Firms in the network write the responsibility matrix and the controls behind it.
Get matched