Shared Responsibility Model

Overview

The shared responsibility model is the axis on which every control in this guide turns. It partitions security obligations between two parties. The cloud service provider (CSP) owns the security of the cloud: the physical facilities, the hypervisor, the host operating system, the storage substrate, and the global network. The customer 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 model is the starting point rather than a footnote because 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. Together they establish what attackers want and which half of the partition each attack targets.

The IaaS/PaaS/SaaS responsibility gradient

The usual 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). Most misconfigurations cluster in the "Shared" category, 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 facilitiesCSPCSPCSP
Host hypervisorCSPCSPCSP
Guest OSCustomerCSPCSP
Runtime / middlewareCustomerCSPCSP
ApplicationCustomerCustomerCSP
DataCustomerCustomerCustomer
Identity & accessCustomerCustomerCustomer
Configuration & hardeningCustomerSharedShared

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 control. Every provider page in this guide assumes 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 treats the boundary as the working assumption behind every recommendation.

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.

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.

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. The General network principles page revisits that partition shift 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 are hierarchical containers within a tenancy that carry their own IAM policies, and they are the segmentation primitive across which the customer's half of the partition is enforced.

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 often enough 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.

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.

Sources