Shared Responsibility Model

Overview

The shared responsibility model is the editorial axis on which every control in this guide turns. It partitions security obligations between the cloud service provider (CSP) — which owns the security of the cloud, meaning the physical facilities, the hypervisor, the host operating system, the storage substrate, and the global network — and the customer, who owns security in the cloud, meaning everything they configure, deploy, identify, and store. The boundary between those two halves is not fixed: it shifts every time a workload moves up the IaaS → PaaS → SaaS abstraction ladder, and provider-specific terminology (compartments, projects, subscriptions, accounts) hides the fact that the underlying partition follows the same five-layer logic across all four hyperscalers.

The reason the model is the starting point — rather than a footnote — is that misunderstandings of the boundary are the single most common documented root cause of cloud breach. The Cloud Security Alliance Top Threats to Cloud Computing 2024 (accessed 2026-05) report places "misconfiguration and inadequate change control" and "identity and access management failures" in its top three, both of which are customer-side obligations that survey respondents frequently attribute, incorrectly, to the provider. The cloud definition published in NIST SP 800-145 — The NIST Definition of Cloud Computing (accessed 2026-05) formally distinguishes the three service models referenced throughout this page (IaaS, PaaS, SaaS), and remains the citation of record for the abstraction layering used below. Before reading any provider-specific domain page, work through the cloud threat model: adversary classes and attack chains alongside this page — the two together establish what attackers want and which half of the partition each attack targets.

The IaaS/PaaS/SaaS responsibility gradient

The classical depiction of the shared responsibility model is a three-column gradient table, with one column per service model and one row per logical layer of the stack. Reading the table from top to bottom traces the physical-to-conceptual progression of a deployed workload; reading it from left to right traces the increase in CSP-managed responsibility as the customer rents more of the platform. The cells classify each intersection as CSP (provider-owned), Customer (customer-owned), or Shared (provider supplies the primitive; customer configures it). The "Shared" category is where the majority of misconfigurations cluster, because the provider has supplied a mechanism — encryption-at-rest defaults, identity federation, network ACLs — but the customer must opt in to a hardened configuration. Default-deny is rarely the default.

Layer	IaaS	PaaS	SaaS
Physical facilities	CSP	CSP	CSP
Host hypervisor	CSP	CSP	CSP
Guest OS	Customer	CSP	CSP
Runtime / middleware	Customer	CSP	CSP
Application	Customer	Customer	CSP
Data	Customer	Customer	Customer
Identity & access	Customer	Customer	Customer
Configuration & hardening	Customer	Shared	Shared

Figure 1 — The canonical shared-responsibility pyramid. Three stacked trapezoids (IaaS, PaaS, SaaS) with the CSP-owned half shaded above and the customer-owned half shaded below. The dividing horizontal line rises as the service model moves from IaaS to SaaS: under IaaS, the boundary sits just above the hypervisor; under PaaS, above the runtime; under SaaS, above the application. The two layers that never cross the boundary — data and identity — are drawn as a separate vertical column on the right, owned by the customer at every service model.

Two layers refuse to move with the service model, and the table calls them out explicitly: data and identity. Whether the customer rents a bare virtual machine or a fully managed mailbox, the contents of records inside the service, and the principal directory that authorises access to them, are customer obligations. That asymmetry is why the General IAM principles page treats identity as the cloud's primary attack surface, and why the General data protection principles page treats classification — not encryption mechanics — as the first-class control. Every subsequent provider page in this guide tables-stakes that data and identity remain customer-owned even when the rest of the stack is managed.

AWS shared responsibility

Amazon Web Services frames the partition as "security of the cloud versus security in the cloud" in AWS Shared Responsibility Model (accessed 2026-05). AWS owns the hardware, the virtualization layer, and the managed services' control planes; the customer owns guest OS patching on EC2, all IAM policies including the root user, every S3 bucket policy, and the data-classification decision behind which encryption key to use. The AWS Well-Architected Framework — Security Pillar (accessed 2026-05) extends this into eight design principles and adopts the boundary as the working assumption behind every recommendation.

Figure 2 — AWS shared responsibility strip. Two horizontal bands: the upper band labelled "AWS responsibility — security of the cloud" enumerates Regions, Availability Zones, edge locations, compute hardware, storage hardware, networking hardware, and the hypervisor; the lower band labelled "Customer responsibility — security in the cloud" enumerates customer data, platform/applications/IAM, OS network and firewall configuration, client-side data encryption, server-side encryption with customer-managed keys, and network traffic protection. The bands meet at the hypervisor boundary.

The AWS-specific nuance worth marking is the managed services in the middle: RDS, ElastiCache, Lambda, and Fargate sit on a sliding boundary where AWS patches the OS and engine but the customer still owns the parameter group, IAM authentication policy, and the data inside. The Well-Architected guidance is explicit that "AWS managing the infrastructure" never implies "AWS managing your identity, access controls, or data" — a distinction repeatedly missed in audit findings.

Azure shared responsibility

Microsoft's canonical statement of the partition is Microsoft Learn — Shared responsibility in the cloud (accessed 2026-05), which presents a seven-row matrix (information and data; devices; accounts and identities; identity and directory infrastructure; applications; network controls; OS; physical hosts/network/datacenter) with cells coloured by service model. The Microsoft Cloud Security Benchmark (accessed 2026-05) (MCSB v1) then operationalises the partition into prescriptive baselines that map to NIST SP 800-53 rev5 and CIS controls.

Figure 3 — Azure shared responsibility strip. Four columns (On-premises, IaaS, PaaS, SaaS) over seven rows; cells coloured blue for Microsoft, grey for customer, blue-grey for shared. The rightmost SaaS column shows Microsoft owning everything below "applications", while "information and data", "devices", and "accounts and identities" remain customer-owned across all three cloud columns.

The Azure-specific nuance is the dual identity plane: a tenant subscribes to Entra ID (formerly Azure AD) for identity and to Azure Resource Manager for resource control, and the same principal can carry roles in both planes. Misconfigurations frequently arise when a Global Administrator role in Entra is assumed to control subscription-level resources without the paired Owner assignment — or vice versa — which the MCSB identity baseline calls out explicitly.

GCP shared responsibility

Google Cloud extends the partition with the concept of shared fate — a commitment that Google supplies opinionated secure defaults, blueprints, and Assured Workloads guardrails, rather than leaving the customer to derive a hardened baseline from first principles. The model is documented in Google Cloud Architecture Framework — Shared responsibilities and shared fate on Google Cloud (accessed 2026-05). Like AWS and Azure, Google places the data and identity layers on the customer side at every service model.

Figure 4 — GCP shared responsibility strip with shared-fate overlay. The upper region labelled "Google responsibility" covers hardware, boot, storage encryption, network, and the container runtime substrate; the lower region "Customer responsibility" covers content, access policies, deployment, web app security, identity, operations, access & auth, usage, and network security. A diagonal "Shared fate" band crosses the boundary depicting Google-supplied secure defaults, blueprints, and Assured Workloads guardrails that reduce the customer's configuration burden.

The GCP-specific nuance is the project-as-isolation-boundary: unlike AWS accounts or Azure subscriptions, a GCP project carries its own billing identity, its own IAM policy, and its own API enablement state. Cross-project access is explicit and granted via IAM rather than network reachability, which moves a meaningful chunk of segmentation work from network controls to identity policy — a partition shift that the General network principles page revisits when it covers zero-trust pillars.

OCI shared responsibility

Oracle Cloud Infrastructure documents its partition under OCI Documentation — Security Overview and Shared Security Model (accessed 2026-05), which divides obligations between Oracle (data centre, hardware, virtualization, OCI services control plane) and the customer (workloads, identities, data, configurations within the tenancy). OCI's compartments — hierarchical containers within a tenancy that carry their own IAM policies — are the segmentation primitive across which the customer's half of the partition is enforced.

Figure 5 — OCI shared responsibility strip. Two stacked panels: "Oracle responsibility" listing physical security, network infrastructure, virtualization, OCI services, and hypervisor patching; "Customer responsibility" listing workloads, guest OS, identities & access (IAM), data classification & encryption, network configuration (VCNs, security lists, NSGs), and configuration of OCI security services (Cloud Guard, Data Safe, Vault). Compartments are illustrated as nested boxes crossing the customer half.

The OCI-specific nuance is the Identity Domain abstraction: tenancies can host multiple Identity Domains, each with its own users, groups, applications, and MFA policies. Customers migrating from legacy IDCS deployments frequently inherit domain-level policy gaps that the OCI Security Best Practices (accessed 2026-05) checklist flags as the first hardening pass.

Common misunderstandings

Three misunderstandings recur with sufficient frequency that every general-section reader should recognise them by sight. Each is captured below as a misconfiguration callout: the pattern identifies the false belief, names the obligation the customer actually holds, and cites the primary source that documents the partition.

Common misunderstanding

"The provider backs up my SaaS data." No major SaaS provider commits to point-in-time recovery of customer-deleted records beyond a brief operational retention window (commonly 14 – 93 days). The CSA Top Threats to Cloud Computing 2024 (accessed 2026-05) report lists "data loss" as a top concern precisely because customers conflate provider durability (multi-AZ replication against hardware failure) with logical backup (recovery from accidental deletion, ransomware encryption, or insider destruction). The customer obligation is third-party backup, export, or retention-policy configuration — see the General data protection principles page for the immutable-backup pattern (see data protection principles).

Cross-cutting implications

The shared responsibility model is not a one-time orientation; it is the recurring lens through which every subsequent General-page control is framed. Six cross-cutting consequences carry into the domain principle pages and are worth previewing here.

Identity is wholly customer-owned at every service model, which is why the General IAM principles page treats least privilege, MFA, and federation as first-class obligations rather than provider-supplied features. Network segmentation is also customer-owned at the configuration layer, so the General network principles page treats default-deny egress and private connectivity as design obligations rather than defaults. Data classification — the choice of which key, which retention policy, and which DLP rule applies — is permanent customer territory, expanded in the General data protection principles page. Logging configuration and SIEM routing are customer responsibilities even when the log substrate is provider-managed, which the General logging and detection principles page treats as the foundation for every detection control. Workload hardening — image baselines, supply-chain provenance, runtime security — is squarely customer-owned at IaaS and remains a configuration obligation at PaaS, as the General workloads principles page documents. Finally, the partition shapes incident response: when the control plane is customer-owned but the data plane is provider-managed, evidence acquisition and credential isolation procedures diverge from on-premise IR practice, which the General incident response principles page captures in its containment patterns. The conceptual companion to this page is the cloud threat model; the compliance crosswalk for the partition is documented in the compliance frameworks page; and the editorial process is described in the methodology page.