Shared Responsibility Model

What it is

The shared responsibility model defines which security and compliance obligations belong to the cloud provider ("security of the cloud") and which belong to the customer ("security in the cloud"). The boundary shifts depending on the service abstraction level: with IaaS (EC2, Compute Engine, Azure VMs), the provider secures physical hardware, the hypervisor, and the host OS; the customer is responsible for the guest OS, runtime, application, data, and network controls. With PaaS (Lambda, App Engine, Azure App Service), the customer's responsibility shrinks further — the provider manages the OS and runtime patches; the customer is responsible for application code, configuration, and data. With SaaS (Salesforce, Google Workspace), the provider manages nearly everything; the customer is responsible for user access management, data governance, and appropriate usage.

This model is not just a conceptual framework — it has direct compliance implications. When auditors ask whether your data is encrypted at rest, the answer depends on which layer of encryption is in scope and who configured it. AWS encrypts the underlying storage infrastructure, but encrypting EBS volumes with a customer-managed KMS key (CMK) is the customer's responsibility. Similarly, AWS guarantees the physical security of its data centres (SOC 2 Type II report available), but a misconfigured S3 bucket policy that makes customer data public is entirely the customer's failure — one that has caused numerous high-profile data breaches.

Why it exists

The model emerged from the practical need to define accountability in a multi-tenant environment. Cloud providers cannot control what customers deploy, configure, or store on their platforms; conversely, customers cannot physically inspect the data centres or patch the hypervisors they share. The formal articulation of this division allows both parties to produce accurate compliance evidence: the provider's SOC 2, ISO 27001, and PCI-DSS certifications attest to their layer; the customer must produce equivalent evidence for their layer. Without the model, organisations either over-trust providers ("we're in AWS, so we're secure") or under-leverage them ("we need to manage our own hardware security modules").

From a practical architecture perspective, the model tells you where to invest security engineering effort. Using RDS instead of self-managed PostgreSQL on EC2 transfers OS patching, database engine upgrades, automated backups, and storage encryption responsibility to AWS — freeing your team to focus on query-level access controls and application-layer encryption of sensitive fields. Every step up the abstraction ladder (IaaS → PaaS → serverless → SaaS) transfers more operational and security responsibility to the provider but also reduces the customer's control over the underlying implementation.

When to use

• When choosing between IaaS and PaaS for a workload — use the model to explicitly map which security controls your team will own at each abstraction level.
• During security assessments and compliance audits to define the evidence boundary: what does the cloud provider's certification cover, and what must your team demonstrate independently?
• When evaluating a SaaS vendor — determine what security controls the vendor's shared responsibility model leaves to you (user provisioning, data classification, API token management).
• When scoping penetration tests — the model defines what infrastructure is in-scope for customer-authorised testing and what requires provider approval (you cannot pen-test the AWS hypervisor).
• When writing security architecture documentation that must map controls to owner (provider vs. customer) for a compliance framework.

When not to use

• As a shield for inaction: "That's AWS's responsibility" is not a valid response when the customer control layer (S3 bucket policy, security group) is the actual misconfiguration. Audit findings trace to the customer regardless of provider guarantees at lower layers.
• As a substitute for contractual review: The shared responsibility model is a conceptual framework; specific obligations are defined in the cloud provider's Terms of Service and Data Processing Agreements, which must be reviewed for regulated data.
• Assuming SaaS means zero customer responsibility: Even Salesforce or Google Workspace deployments require customer-managed SSO configuration, data retention policies, and access reviews.

Typical architecture

Responsibility Boundary by Service Model

Layer            IaaS (EC2)   PaaS (Lambda)  SaaS (Salesforce)
────────────     ──────────   ─────────────  ─────────────────
Physical infra   Provider     Provider       Provider
Hypervisor       Provider     Provider       Provider
Host OS          Provider     Provider       Provider
Guest OS         Customer     Provider       Provider
Runtime          Customer     Provider       Provider
Middleware       Customer     Provider       Provider
Application      Customer     Customer       Provider*
Data             Customer     Customer       Customer
IAM/Access       Customer     Customer       Customer
Network configs  Customer     Shared         Customer

* SaaS: provider manages the app; customer manages configuration

Common Customer-Owned Controls (all service models):
  ✓ IAM user/role/policy configuration
  ✓ Multi-factor authentication enforcement
  ✓ Data classification and encryption key management
  ✓ Security group / firewall rules (IaaS/PaaS)
  ✓ Application-level access controls
  ✓ Monitoring and incident response
  ✓ Data backup and recovery testing

Pros and cons

Implementation notes

For each service in your architecture, document the responsibility boundary explicitly in a RACI-style table. For AWS, refer to the specific service's documentation for its shared responsibility model — EKS, for example, manages the Kubernetes control plane patches but the customer owns node group OS updates (for managed node groups, AWS handles AMI rotation if you opt in; for self-managed nodes, you own it entirely). For ECS Fargate, AWS owns the container instance OS; for ECS on EC2, you own the ECS-optimised AMI updates. These distinctions matter for vulnerability management programs.

For compliance programs (PCI-DSS, HIPAA, SOC 2), download the AWS Artifact compliance reports that map AWS controls to the applicable framework. Use these as evidence for infrastructure-layer controls in your audit package. For your customer-layer controls, implement AWS Config rules with automatic remediation for the most critical customer responsibilities: s3-bucket-public-read-prohibited, encrypted-volumes, iam-root-access-key-check, mfa-enabled-for-iam-console-access. AWS Security Hub consolidates these findings across accounts with NIST, CIS, and PCI-DSS standards mapped to specific Config rules.

Common failure modes

• S3 public access misconfiguration: The most common cloud breach vector — customer assumes S3 encryption means data is private, but bucket policy allows public read; AWS handles encryption at rest, customer owns access policy.
• RDS encryption not enabled at creation: Encryption at rest on RDS cannot be enabled after creation; a database provisioned without encryption requires snapshot + restore to add it — many teams discover this during their first compliance audit.
• EKS node group AMI not updated: Teams assume EKS means "managed Kubernetes" and stop patching nodes; EKS manages the control plane but self-managed node groups require customer AMI rotation.
• IAM credential over-permission: Provider secures the IAM service; customer is responsible for granting least-privilege roles. Overly permissive IAM policies are entirely customer-owned failures.
• Assuming SaaS DLP is the vendor's problem: A Google Workspace deployment that allows users to share confidential files externally has a customer-configured access policy problem, not a Google security failure.

Decision checklist

• For each cloud service you use, have you documented which security controls are provider-managed vs customer-managed?
• Are your encryption-at-rest configurations using customer-managed KMS keys for regulated data, not just provider-managed default encryption?
• Have you reviewed your provider's shared responsibility model documentation for every managed service (EKS, RDS, Lambda) you operate?
• Is MFA enforced for all IAM users and root account access, which is always the customer's responsibility?
• Does your compliance evidence package include both provider attestations and your independent evidence for customer-layer controls?
• Is S3 Block Public Access enabled at the account level to prevent accidental public exposure of customer-owned data?

Example use cases

• HIPAA-compliant healthcare app on AWS: Executes a BAA with AWS to cover provider-managed layers (EC2, RDS, S3 physical security), then independently implements application-level encryption of PHI fields, CloudTrail audit logging, and VPC network isolation — all customer-owned controls not covered by the BAA alone.
• PCI-DSS compliance audit: Uses AWS Artifact to download AWS PCI-DSS Responsibility Summary document; maps each of the 300+ PCI requirements to either AWS-owned (physical security, network infrastructure) or customer-owned (application code, cardholder data access controls) and produces evidence only for customer-owned requirements.
• SaaS data breach post-mortem: A Slack misconfiguration allowed all channels to be visible to all workspace members including contractors; the incident is entirely the customer's access policy failure — Slack's platform security is not implicated, demonstrating the model's boundary in SaaS.

Related patterns

• Cloud Landing Zones — landing zones automate the customer-layer security baseline (Config rules, GuardDuty) that the shared responsibility model assigns to customers.
• Security Architecture — application-level security controls that are always customer responsibility regardless of service model.
• Managed Services Strategy — the decision to use managed vs self-hosted services directly changes which layers of the model the customer owns.

Further reading

• AWS Shared Responsibility Model
• Shared Responsibility in the Cloud — Microsoft Azure
• Shared Responsibility Model — Google Cloud Architecture Framework