Shared Responsibility Model Explained

The shared responsibility model is the foundational framework governing how security obligations are divided between cloud service providers (CSPs) and their customers across cloud computing deployments. This page maps the model's definition, operational mechanics, representative deployment scenarios, and the decision boundaries that determine where provider obligations end and customer obligations begin. The framework has direct implications for regulatory compliance, contractual liability, and enterprise risk management in US cloud environments.

Definition and scope

The shared responsibility model establishes that no single party holds complete security ownership over a cloud environment. Instead, accountability is divided based on the service model — Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or Software as a Service (SaaS) — as defined by the National Institute of Standards and Technology in NIST SP 800-145. The division is not uniform: as the service model abstracts further from physical infrastructure, more operational security responsibility shifts to the CSP and less remains with the customer.

The Cloud Security Alliance (CSA) formalizes this division in the Cloud Controls Matrix (CCM), which maps 197 control objectives across 17 domains to specific party responsibility based on deployment model. Federal regulatory programs extend these distinctions into compliance requirements: FedRAMP requires cloud service providers seeking federal authorization to document a Customer Responsibility Matrix (CRM) identifying which of the 325 controls drawn from NIST SP 800-53 Rev 5 are inherited by the customer, partially inherited, or fully managed by the provider.

The model applies across all three major deployment types — public cloud, private cloud, and hybrid — though the precise boundary configurations differ. Professionals navigating service provider relationships and compliance obligations within this sector can reference the Cloud Defense Providers for categorized provider resources.

How it works

The shared responsibility model operates through a layered accountability structure. Responsibility is allocated across five discrete layers of the cloud stack:

1. Physical infrastructure — Data center facilities, hardware, networking equipment, and power. This layer is exclusively the CSP's responsibility in all public cloud models.
2. Virtualization and hypervisor — The compute abstraction layer separating tenant workloads. CSP-owned in IaaS, PaaS, and SaaS.
3. Operating system — In IaaS, the customer manages the guest OS including patching and hardening. In PaaS and SaaS, the CSP manages the OS.
4. Application layer — In IaaS and PaaS, the customer owns application security, including code, configurations, and dependency management. In SaaS, this shifts to the CSP.
5. Data and identity — Across all three service models, the customer retains responsibility for data classification, access control policies, identity and access management (IAM) configurations, and encryption key management.

This layered structure means that even in a fully managed SaaS environment, the customer cannot delegate data governance. The Department of Health and Human Services (HHS) makes this explicit under HIPAA: covered entities remain accountable for protected health information (PHI) stored in SaaS platforms regardless of CSP security certifications, and business associate agreements (BAAs) do not transfer primary compliance responsibility.

Common scenarios

IaaS deployment (e.g., virtual machines on a public cloud platform): The CSP secures the physical facility, network, and hypervisor. The customer is responsible for operating system patching, firewall rule configuration, application security, IAM policies, and all data handling. A misconfigured security group or unpatched OS is exclusively the customer's failure domain.

PaaS deployment (e.g., managed database or container orchestration service): The CSP extends responsibility upward to include the runtime environment and middleware. The customer retains ownership of application code, database access controls, and stored data. The CSP does not manage application-layer vulnerabilities introduced by the customer's code.

SaaS deployment (e.g., cloud-hosted productivity or CRM platforms): The CSP manages the entire application stack through the interface. The customer controls user provisioning, permission scoping, data export policies, and third-party integrations. Under the SEC's 2023 cybersecurity disclosure rules (17 CFR §229.106), publicly traded companies must disclose material cybersecurity incidents as processing allows of determining materiality — even when the incident originates in a SaaS provider's environment, if customer data is affected.

Hybrid and multi-cloud environments introduce compounded boundary complexity because each CSP relationship carries its own CRM, and on-premises infrastructure adds a third accountability domain. The CSA CCM's domain mapping provides a cross-platform control baseline for normalizing these overlapping obligations.

For a broader orientation to how cloud defense services are structured and categorized, the page describes the reference landscape this domain covers.

Decision boundaries

The shared responsibility model's most consequential application is determining where liability attaches in the event of a breach or compliance failure. Three boundary tests define the division:

• Control plane vs. data plane: CSPs own the control plane (service availability, hardware integrity, platform APIs). Customers own data plane decisions, including what data is stored, how it is encrypted, and who holds access.
• Default configurations vs. customer configurations: A CSP may deliver a secure default state, but any customer-modified configuration — open S3 bucket policies, permissive IAM roles, disabled logging — is within the customer's responsibility domain. NIST SP 800-53 Rev 5 Control CA-3 addresses information system connections and places configuration authorization obligations on the system owner, not the provider.
• Inherited controls vs. customer-implemented controls: FedRAMP CRMs explicitly classify each control as CSP-inherited, shared, or customer-implemented. Controls classified as customer-implemented carry no inheritance credit; the customer must independently satisfy them for audit purposes.

The boundary between PaaS and IaaS is frequently misread. A managed Kubernetes service, for example, abstracts the control plane but may leave node-level OS patching as a customer obligation — a configuration detail that varies by provider and service tier and must be confirmed against the specific provider's CRM documentation.

Professionals working through multi-provider compliance structures can reference the How to Use This Cloud Defense Resource page for guidance on navigating the provider network's service classifications.