A shared responsibility model is the provider's statement of which security tasks it performs and which stay with the customer, and most cloud incidents happen in the customer's half. AWS, Microsoft and Google each publish one, the split moves as you go from IaaS to PaaS, SaaS and AI services, and some responsibilities never move at all. This guide explains what the models say in plain terms, compares the three major providers, extends the idea to SaaS and to AI using Microsoft's AI shared responsibility model, and shows how to turn a provider diagram into an owned control set. It is written for security leads, cloud and platform engineers, GRC teams and anyone signing off a new cloud, SaaS or AI service. Detailed cloud and SaaS hardening lives in the guides linked throughout.
Key takeaways
- Some duties never transfer. Microsoft states that for all cloud deployment types you own your data and identities, and Google states that customers always remain responsible for their access policies and data.
- The split moves with the service model. In IaaS the customer patches the guest operating system and configures the network; in SaaS the provider runs almost everything below the application settings, data and accounts.
- Shared means both parties act. Patching, configuration management and training are shared controls: the provider does its layer, you do yours, and neither covers the other.
- AI adds layers, not exceptions. Microsoft splits an AI workload into platform, application and usage layers, and the usage layer still depends on identity and access controls, device protection and data governance that the customer runs.
- Provider tools are not provider responsibility. MFA, network allow lists and metadata protection are offered as settings; if you do not switch them on, the gap is yours, as the Snowflake and Capital One incidents show.
What it is
A shared responsibility model is a division of security and compliance tasks between a cloud service provider (CSP) and its customer. AWS describes it as security "of" the cloud versus security "in" the cloud: AWS is responsible for protecting the infrastructure that runs its services, while customer responsibility is determined by the services the customer selects. Microsoft and Google publish equivalent matrices. The models are governance statements, not contracts: Microsoft notes that its AI model is illustrative guidance and does not change the terms of any agreement, so the contract and the service documentation remain the binding sources.
The service models follow the NIST SP 800-145 definitions. In IaaS you rent compute, storage and network and run your own operating system. In PaaS the provider runs the operating system and runtime and you deploy code or data. In SaaS you consume a finished application. Serverless or function services sit close to SaaS in Google's description.
How it works
The split by service model
The table combines Microsoft's published matrix with the AWS and Google descriptions. "Shared" means both parties have tasks for that layer.
| Layer | On-premises | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| Data | Customer | Customer | Customer | Customer |
| Identities, accounts and access policy | Customer | Customer | Customer | Customer |
| Configuration and settings | Customer | Customer | Customer | Customer |
| Client devices and endpoints | Customer | Customer | Customer | Shared |
| Applications | Customer | Customer | Shared | Shared |
| Network controls | Customer | Customer | Shared | Provider |
| Operating system | Customer | Customer | Provider | Provider |
| Physical hosts, network and datacentre | Customer | Provider | Provider | Provider |
Examples make the table concrete. On Amazon EC2 the customer performs all the security configuration and management tasks for the guest operating system, installed software and security groups. On Amazon S3 or DynamoDB, AWS operates the infrastructure, operating system and platform, and the customer manages data, encryption options, classification and IAM permissions. On Google Cloud, Compute Engine puts the bulk of responsibility on the customer, App Engine, GKE and BigQuery share application-level controls and IAM management, and in Google Workspace Google owns most of the work while the customer manages access and data.
The three providers compared
| Provider | How it frames the model | Control categories it names | What it says the customer always owns |
|---|---|---|---|
| AWS | Security of the cloud (AWS) and security in the cloud (customer) | Inherited controls (physical and environmental), shared controls (patch management, configuration management, awareness and training), customer-specific controls (service and communications protection or zone security) | Responsibility depends on the services selected; data, classification and IAM permissions stay with the customer even on abstracted services |
| Microsoft Azure | Responsibility matrix across on-premises, IaaS, PaaS and SaaS | Rows from physical datacentre up to data, identities and configuration | Data, endpoints, accounts and access management in every deployment type |
| Google Cloud | Shared responsibility extended into "shared fate" | Secure-by-default configurations, infrastructure-as-code blueprints with recommendations enabled, Assured Workloads, Risk Protection Program with insurers | Access policies and data |
Google's shared fate idea is the provider taking a more active part: secure defaults to reduce misconfiguration, blueprints such as the enterprise foundations blueprint, and tools such as Security Command Center and organisation policies. It reduces the effort of the customer's share; it does not move ownership of access policies or data.
SaaS: the thinnest share, still not zero
In SaaS the provider runs the application, but the tenant settings, the user and service accounts, the OAuth integrations, the sharing settings and the data are the customer's. Most SaaS incidents come from these: accounts without MFA, over-broad third-party app consents and public sharing links. See the SaaS Security Guide and the SaaS and OAuth App Governance Guide.
AI: platform, application and usage
Microsoft's AI shared responsibility model splits an AI-enabled workload into three layers, and states that security responsibilities generally sit with the party performing the task, while an AI provider may expose some controls to the customer as configuration options. Microsoft recommends starting with SaaS AI such as Copilot, moving to PaaS services such as Azure OpenAI when needed, and building custom models only with deep expertise.
| AI layer | What it covers | Customer tasks when you build or run it | Customer tasks when you only consume SaaS AI |
|---|---|---|---|
| AI platform | Model, training data, infrastructure, configuration such as weights; input and output safety filtering | Protect model infrastructure, training data and model configuration; run input and output safety filters | Choose and configure the provider's safety settings where exposed |
| AI application | The service users touch: metaprompt, grounding data, plugins, data connectors, orchestration | Build an application safety system that inspects metaprompts and plugin and connector interactions | Govern which connectors, plugins and data sources are enabled, and with which permissions |
| AI usage | How people and agents use AI | Identity and access controls, device protection and monitoring, data protection and governance, administrative controls | The same, plus updated acceptable use policies and user education |
The provider-specific services are covered in the Azure OpenAI and Azure AI Foundry Security Guide, the Amazon Bedrock Security Guide, the Google Vertex AI Security Guide and the Microsoft 365 Copilot Security Deep Dive.
Turning a model into owned controls
- List every service in use: each IaaS, PaaS, SaaS and AI service, including those bought by business units. Discovery from SSO logs, expense data and cloud billing finds most of them.
- Read the provider's model and the service documentation: record for each service which layers are provider, shared and customer, using the CSA Cloud Controls Matrix where it helps, since the CCM indicates which party should implement each of its 197 control objectives.
- Assign a named owner to every customer and shared control: identity, configuration, logging, data protection and incident response, per service. A shared control with no customer owner is an unowned control.
- Collect provider evidence for the inherited part: SOC 2 reports, ISO/IEC 27001 certificates and CSA STAR entries, and read the complementary user entity controls they list, which are the provider telling you what it expects you to do.
- Enforce customer controls as guardrails, not reviews: organisation policies, SCPs and Azure Policy, tested in audit or dry-run mode before enforcement, with a documented exception route to roll back a blocking policy.
- Write the split into contracts: security requirements, notification times and evidence rights, as CSF 2.0 GV.SC-05 expects for supplier agreements.
- Reassess on change: new services, new AI features switched on by default, or a provider changing defaults (as Snowflake did with single-factor sign-ins) all move the line.
Why it matters
The model decides who is accountable when something goes wrong, and regulators and courts look at the customer's half. Two incidents in the NHI Mgmt Group breach database show the pattern.
- Snowflake 2024: attackers used infostealer credentials to log into around 165 customer Snowflake accounts that had no MFA and no network allow lists. Snowflake reported no evidence of a vulnerability, misconfiguration or breach of its platform. The controls existed as options; the customer side did not enable them. See the Snowflake breach.
- Capital One 2019: a misconfigured web application firewall running in AWS let an attacker obtain the credentials of the role it ran under, and that role could read far more S3 data than a firewall needed. AWS offers IMDSv2, which requires session tokens for metadata requests and blocks many forged requests of this kind, but the deployment did not use it. See the Capital One breach.
The NCSC makes the same point in its Cloud Security Principles: the principles help you choose a provider, but you will separately need to consider how you configure your cloud services securely, and Principle 14, secure use of the service, leaves your responsibilities with you.
Where identity fits
Identity is the one layer that is the customer's in every column of every provider's model, and it now includes far more machines than people: IAM roles, service principals, service accounts, access keys, OAuth applications and AI agents acting with delegated permissions. The provider supplies the identity system; who exists in it, what each identity may do and how its credentials are protected is the customer's job. See the Cloud Workload Identity Guide and the Cloud IAM Review Checklist.
Framework mapping
| Responsibility task | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|
| Define and record who does what with each provider | GV.RR Roles, Responsibilities, and Authorities; GV.SC-05 | SA-9 External System Services | A.5.19, A.5.20 supplier relationships and agreements |
| Assess and monitor the provider over the relationship | GV.SC-07 | SR-3 Supply Chain Controls and Processes; CA-7 Continuous Monitoring | A.5.22 monitoring of supplier services |
| Secure use of cloud services | PR.PS Platform Security | SA-9(2) Identification of Functions, Ports, Protocols, and Services | A.5.23 information security for use of cloud services |
| Customer-owned identities and access | PR.AA | AC-2 Account Management; AC-6 Least Privilege | A.5.15 to A.5.18 |
| Customer-side logging and review | DE.CM Continuous Monitoring | AU-6 Audit Record Review, Analysis, and Reporting | A.8.15, A.8.16 |
Measuring it
- Ownership coverage: percentage of customer and shared controls per service with a named owner.
- Guardrail coverage: percentage of accounts, subscriptions and projects under enforced preventive policies.
- MFA and federation coverage: share of human logins to cloud, SaaS and AI services through SSO with MFA, and share of service accounts without static passwords or long-lived keys.
- Provider evidence currency: percentage of critical providers with a current SOC 2 or ISO/IEC 27001 report reviewed, including its user entity controls.
- Misconfiguration dwell time: median time from a posture finding in a customer-owned layer to remediation.
Common misconceptions
- "The provider is certified, so we are compliant": a provider's ISO/IEC 27001 certificate or SOC 2 report covers its own controls. Your obligations for data, identities and configuration are untouched.
- "SaaS means the vendor handles security": tenant settings, accounts, integrations and sharing remain yours, and in Microsoft's matrix client devices and the application are shared even in SaaS.
- "Default settings are secure settings": Google's own shared fate work exists because misconfiguration is common; defaults vary, and logging such as data access events is often off by default.
- "Shared means the provider has it covered": a shared control has two halves. AWS patches its hosts; nobody patches your EC2 guest operating system unless you do.
- "AI is different and the model provider owns the risk": the provider secures what it runs, but the data you ground on, the connectors you enable and who can use the AI are your decisions.
- "One model fits all our providers": AWS, Microsoft and Google draw the lines slightly differently and each service within them differs; record the split per service.
Related concepts
- Third-party risk management: the shared responsibility model is one input to supplier assessment. See the Third-Party Risk Management Guide.
- Complementary user entity controls: the controls a SOC 2 report says the customer must operate. See the SOC 2 Guide.
- CSA CCM and STAR: a control framework that assigns each control to provider or customer. See the Cloud Security Alliance CCM and STAR Guide.
- Cloud misconfiguration and posture management: the practical work in the customer's half. See the Cloud Misconfiguration Guide and the Cloud Security Guide.
- Concentration and exit: what happens when the provider's half fails. See the Cloud Concentration Risk and Exit Strategy Guide.
- Choosing frameworks: see the Cybersecurity Frameworks Compared Guide.
Practitioner checklist
- Maintain an inventory of every IaaS, PaaS, SaaS and AI service in use, including business-bought ones.
- Record the provider, shared and customer split per service, from the provider's model and service documentation.
- Name an owner for every customer and shared control.
- Enforce SSO with MFA for human access and remove static passwords and long-lived keys from service accounts.
- Apply preventive guardrails (SCPs, Azure Policy, organisation policies), tested in audit mode first.
- Review provider SOC 2 or ISO/IEC 27001 evidence each year and implement the user entity controls it lists.
- Write security responsibilities, notification and evidence rights into provider contracts.
- For AI services, govern connectors, plugins and grounding data, and update acceptable use policies.
Standards and references
- AWS: Shared Responsibility Model
- Microsoft Learn: Shared responsibility in the cloud
- Microsoft Learn: Artificial intelligence (AI) shared responsibility model
- Google Cloud: Shared responsibilities and shared fate on Google Cloud
- NCSC: The Cloud Security Principles
- Cloud Security Alliance: Cloud Controls Matrix
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Cloud Security Guide · SaaS Security Guide · AWS Security Guide · Google Cloud Security Guide · Third-Party Risk Management Guide