The Shared Responsibility Model: Who Owns What in Cloud Compliance

The shared responsibility model defines how security and compliance obligations are divided between a cloud service provider and its customers. This division is not uniform — it shifts depending on the service model in use (IaaS, PaaS, or SaaS), the applicable regulatory framework, and contractual terms. Misreading where provider responsibility ends and customer responsibility begins is one of the most documented causes of cloud compliance failures, and understanding the boundary precisely is a prerequisite for any audit-ready cloud program.

• Definition and Scope
• Core Mechanics or Structure
• Causal Relationships or Drivers
• Classification Boundaries
• Tradeoffs and Tensions
• Common Misconceptions
• Checklist or Steps
• Reference Table or Matrix

Definition and Scope

The shared responsibility model is a framework — adopted formally by providers including Amazon Web Services, Microsoft Azure, and Google Cloud Platform — that specifies which party controls which layer of the technology stack and therefore which party is accountable for the controls that protect that layer. The model does not transfer legal liability by itself; regulatory liability under statutes such as HIPAA (45 CFR Parts 160 and 164), PCI DSS, and FedRAMP remains with the regulated entity regardless of where infrastructure physically runs.

The National Institute of Standards and Technology (NIST) defines cloud service models in SP 800-145 as Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). These three models form the structural backbone of every shared responsibility analysis. The scope of the model extends to physical security, network controls, hypervisor integrity, operating system configuration, application logic, identity management, data classification, and audit logging — each of which may sit on either side of the responsibility line depending on the service model.

For organizations building a cloud compliance program, the shared responsibility model is the starting point for control mapping, gap analysis, and vendor assessment.

Core Mechanics or Structure

The model operates on a layered stack principle. At the lowest layer is physical infrastructure: data center buildings, power systems, cooling, and hardware. Providers universally own this layer across all three service models. At the highest layer sits data — its classification, handling, retention, and access controls. Customers universally own this layer across all three service models.

Between those two poles, responsibility shifts:

IaaS (e.g., raw compute, storage, networking): The provider manages physical hardware and the hypervisor. The customer manages the operating system, middleware, runtime, applications, and data. Approximately 60–70% of the control surface falls to the customer in a typical IaaS deployment (a proportion reflected in AWS's published Shared Responsibility Model documentation and echoed in the Cloud Security Alliance's Cloud Controls Matrix).

PaaS (e.g., managed databases, container orchestration): The provider additionally manages the operating system and runtime environment. The customer retains control of application code, data, and identity configuration.

SaaS (e.g., hosted email, CRM): The provider manages the full stack up to the application layer. The customer controls user access, data inputs, configuration settings, and data export/retention decisions.

The FedRAMP Authorization Act formalizes this structure for US federal cloud deployments: agencies must document which controls are inherited from a FedRAMP-authorized provider's System Security Plan (SSP) and which remain customer-implemented or customer-configured.

Causal Relationships or Drivers

Three forces drive the shared responsibility model's structure.

Technical architecture: Virtualization separates hardware from software execution. Once the hypervisor layer is abstracted, a provider cannot practically control what runs inside a customer's virtual machine — and a customer cannot physically access the hardware beneath it. Architecture imposes the division.

Regulatory specificity: Frameworks such as HIPAA require that a covered entity or business associate maintain control over Protected Health Information (PHI) regardless of infrastructure provider. The HHS Office for Civil Rights has clarified that cloud storage providers handling PHI qualify as Business Associates under the HIPAA Privacy Rule, requiring execution of a Business Associate Agreement (BAA) — but the BAA does not transfer the covered entity's compliance obligation. For regulatory context for cloud compliance, the persistence of regulated-entity liability is the dominant driver that makes the model operationally significant.

Contractual risk allocation: Service-level agreements and terms of service define indemnification boundaries. Providers limit liability for breaches occurring in customer-managed layers. A customer who fails to patch a guest operating system on an IaaS instance has no contractual claim against the provider if that unpatched system is compromised — a pattern documented in multiple public breach disclosures involving misconfigured S3 buckets and unencrypted cloud databases.

Classification Boundaries

The model produces four distinct control ownership categories:

1. Provider-owned controls: Physical security, network infrastructure hardening, hypervisor patching, data center compliance certifications (SOC 2 Type II, ISO 27001, FedRAMP authorization).
2. Customer-owned controls: Data classification, encryption key management, identity and access management (IAM) policy configuration, user lifecycle management, audit log review.
3. Shared controls: Patch management (provider patches hypervisor; customer patches OS), incident response (provider detects infrastructure events; customer responds to application-layer events), and awareness training (both parties train their own personnel).
4. Inherited controls: In FedRAMP, controls documented in the provider's SSP that a customer agency may inherit without re-testing, reducing the customer's authorization burden. NIST SP 800-53 Rev 5 catalogues 20 control families; a customer inheriting a FedRAMP-authorized IaaS platform may inherit controls in families such as Physical and Environmental Protection (PE) almost entirely.

Tradeoffs and Tensions

The model creates genuine structural tensions that compliance programs must navigate explicitly.

Visibility asymmetry: Providers control infrastructure logs that customers cannot independently access. If a hypervisor-level event occurs, the customer has no direct forensic access. This creates a dependency on provider transparency — a tension that the Cloud Security Alliance's CCM addresses through controls in the Audit Assurance and Compliance (A&A) domain requiring providers to make audit artifacts available.

Multi-cloud fragmentation: Each provider publishes its own shared responsibility documentation with different terminology and boundary placements. An organization running workloads across 3 or more cloud providers faces non-uniform control matrices, making consolidated compliance posture assessment operationally difficult. This challenge is examined in detail on the IaaS/PaaS compliance controls reference page.

Dynamic service updates: Providers update service capabilities continuously. A feature that was customer-configured in 2021 may become provider-managed by default in a later service version, silently shifting a control that compliance documentation assumed the customer owned. Organizations relying on static control mappings face silent compliance gaps.

Contractual vs. regulatory accountability: A provider's published shared responsibility model is a service document, not a legal instrument. Regulators — including the FTC under Section 5 of the FTC Act and HHS OCR under HIPAA — evaluate the regulated entity's actual control posture, not the provider's responsibility chart.

Common Misconceptions

Misconception 1: Using a compliant provider makes the customer compliant.
Correction: A FedRAMP-authorized, ISO 27001-certified, or SOC 2 Type II-attested provider demonstrates that the provider's controls meet a defined standard. Customer-owned controls — IAM configuration, data encryption settings, access logging — remain unaudited by the provider's certification. The customer must separately demonstrate control over the layers it owns.

Misconception 2: A Business Associate Agreement transfers HIPAA liability to the provider.
Correction: Per HHS guidance, a BAA creates contractual obligations for the Business Associate but does not absolve the covered entity. If a covered entity misconfigures access controls on a HIPAA-compliant cloud storage service, the covered entity remains liable under 45 CFR § 164.306.

Misconception 3: The shared responsibility model is the same across all cloud providers.
Correction: AWS, Azure, and GCP each publish distinct versions with different boundary placements, particularly around managed service offerings. PaaS database responsibility, for example, is defined differently across the three major providers' documentation.

Misconception 4: Provider certifications cover the customer's data.
Correction: A SOC 2 Type II report attests to the provider's own systems and operations. It does not cover the customer's application layer, data governance practices, or access controls. The SOC 2 compliance framework distinguishes explicitly between provider-scope and customer-scope controls.

Checklist or Steps

The following steps describe a standard shared responsibility mapping process as reflected in FedRAMP documentation practices and NIST SP 800-53 Rev 5 control inheritance guidance:

1. Identify the service model — Determine whether each workload runs on IaaS, PaaS, or SaaS. Each model carries a different default responsibility split.
2. Obtain the provider's published responsibility matrix — Retrieve the provider's official shared responsibility documentation. All three major hyperscalers publish this in their compliance portals.
3. Map provider controls to the applicable regulatory framework — Align provider-owned controls against the control families required by the applicable framework (NIST 800-53, CSA CCM, PCI DSS v4.0 requirements).
4. Identify inherited controls — Document which controls the customer inherits from the provider's certification (e.g., FedRAMP inherited controls from the provider's SSP).
5. Identify customer-owned controls — List every control not covered by provider inheritance. This becomes the customer's control implementation scope.
6. Document shared controls — Record controls requiring action from both parties (patch cadence agreements, incident notification timelines).
7. Assess gaps — Compare customer-owned and shared control requirements against current implementation state. This is the input to a cloud compliance gap analysis.
8. Assign ownership and evidence requirements — For each customer-owned control, assign an internal owner and define the evidence artifact required for audit (configuration screenshots, access review logs, key management policies).
9. Establish continuous monitoring — Define how control status will be validated on an ongoing basis, not only at audit time.

Reference Table or Matrix

Shared Responsibility by Service Model and Control Domain

Sources: AWS Shared Responsibility Model (aws.amazon.com/compliance/shared-responsibility-model), Microsoft Azure Shared Responsibility documentation (learn.microsoft.com), NIST SP 800-145, FedRAMP SSP template guidance.

References

• NIST SP 800-145: The NIST Definition of Cloud Computing
• NIST SP 800-53 Rev 5: Security and Privacy Controls for Information Systems and Organizations
• FedRAMP Program Basics
• HHS Office for Civil Rights — HIPAA Security Rule
• Cloud Security Alliance — Cloud Controls Matrix (CCM)
• AWS Shared Responsibility Model
• 45 CFR Part 164 — HIPAA Security and Privacy Standards (eCFR)