# Shared Responsibility Model Deep Dive
The Shared Responsibility Model is a contractual and operational framework that defines which security controls a cloud service provider (CSP) manages and which controls the customer must manage. It exists because cloud computing fundamentally separates infrastructure ownership from infrastructure use. When a business moves workloads to AWS, Azure, or Google Cloud, it does not own the physical hardware, the hypervisor layer, or the network fabric connecting data centers. The provider owns and secures those layers. The customer owns the data, the identities accessing that data, and the configurations governing how services behave.
Without a clear boundary, both parties may assume the other has covered a control, leaving gaps that attackers exploit. The model solves the attribution problem in cloud security: every security control has an explicit owner, and that ownership is non-negotiable regardless of what a customer believes the provider handles.
The model is distinct from a Service Level Agreement (SLA), which governs availability, uptime, and performance commitments. The Shared Responsibility Model governs security ownership. A provider can meet its SLA while a customer simultaneously suffers a breach because the customer misconfigured an S3 bucket access policy, which falls entirely within the customer's domain.
The model is also distinct from compliance frameworks such as SOC 2 or ISO 27001. A CSP may hold a SOC 2 Type II certification, but that certification covers only the provider's scope of controls. The customer must independently satisfy compliance requirements for controls within their scope, which typically includes data encryption at rest, access management, and incident response procedures.
---
The Shared Responsibility Model operates as a layered boundary that shifts position depending on which cloud service model is in use. Understanding the mechanics requires examining each layer of the cloud stack and assigning clear ownership at each layer.
The Cloud Stack and Ownership Assignment
A cloud deployment can be visualized as a vertical stack with physical infrastructure at the bottom and application data at the top. The stack, from bottom to top, includes: physical facilities and hardware, hypervisors and virtualization, host operating systems, guest operating systems, network controls (virtual networks, firewalls, routing), application runtimes, application code, data, and identity management.
In Infrastructure as a Service (IaaS) deployments, the provider owns and secures the physical layer through the hypervisor. The customer owns and secures every layer above that: the guest OS, network controls such as security groups and network access control lists (NACLs), the application, encryption key management, and identity and access management (IAM) policies. This means a customer running Amazon EC2 instances must patch the Linux or Windows operating system running on those instances. AWS patches the underlying host, but if the customer's guest OS has an unpatched vulnerability and the instance is internet-accessible, the breach is the customer's responsibility.
In Platform as a Service (PaaS) deployments such as AWS RDS or Azure App Service, the provider extends its ownership up the stack to include the guest OS and the database engine or runtime platform. The customer retains ownership of the data stored in the database, the encryption keys used to protect that data (if Customer Managed Keys are configured), the IAM roles and database credentials governing access, and application-level logic. A developer deploying an application on Azure App Service does not need to patch the underlying OS, but they must correctly configure authentication settings, restrict API access, and ensure secrets are stored in Azure Key Vault rather than application environment variables.
In Software as a Service (SaaS) deployments such as Microsoft 365 or Salesforce, the provider owns and manages the entire stack through the application layer. The customer is responsible for data classification and governance (deciding what data goes into the system and how it is labeled), identity and access configuration (who has administrative rights, how multi-factor authentication is enforced, how conditional access policies are set), and third-party integration security (which OAuth applications are permitted to connect to the SaaS platform).
The S3 Misconfiguration Pattern
Consider a common incident scenario. A development team creates an AWS S3 bucket to store financial reports. The team enables server-side encryption using the AWS-managed key (SSE-S3), which means AWS manages the encryption infrastructure. The team then sets the bucket's access control to allow public read access, intending to share reports with external auditors via a temporary link. They do not realize the public access block setting at the account level has been disabled by a previous administrator.
AWS has fulfilled its responsibility: the storage infrastructure is operational, the hypervisors are secure, and the encryption mechanism functions correctly. The breach occurs entirely within the customer's responsibility boundary. The bucket policy (customer-configured), the account-level public access block setting (customer-configured), and the data classification process (customer responsibility) all failed simultaneously. An automated scanner finds the bucket within hours, and the financial reports are exposed.
Preventing this requires the customer to: enable the S3 account-level public access block, enforce bucket policy conditions that deny public access, require Server Side Encryption with Customer Managed Keys (SSE-KMS) for sensitive data, enable AWS CloudTrail and S3 access logging (both off by default), and configure AWS Config rules to alert on any publicly accessible bucket.
Every one of those controls is a customer responsibility. None of them are activated by default by the provider.
Multi-Service Complexity
The complexity multiplies when organizations deploy multiple cloud services. AWS Lambda shifts application runtime management to AWS but leaves function code, dependency management, and IAM execution roles with the customer. Amazon EKS manages the Kubernetes control plane but leaves worker node security, pod security policies, and network policies with the customer. Each service has its own responsibility boundary documented in provider security guides.
The challenge intensifies with cross-service integrations. When Lambda functions access RDS databases, the Lambda execution role (customer), the database access credentials (customer), the VPC configuration connecting Lambda to RDS (customer), and the database encryption settings (customer) all represent customer-side controls that must work together correctly. Provider-side controls include the underlying compute infrastructure, the managed database engine, and the network fabric, but these cannot compensate for customer misconfigurations.
---
Misunderstanding the Shared Responsibility Model is one of the most consistently documented root causes of cloud security incidents. The assumption that a provider's security certification means the customer's environment is secure is operationally dangerous and factually incorrect.
Business and Security Impact
When customers do not understand their responsibility boundary, they make predictable errors: they deploy services without enabling logging (assuming the provider logs everything), they do not configure encryption key management (assuming the provider handles encryption end to end), and they grant excessive IAM permissions (assuming network-layer controls are sufficient). Each of these failures represents a control gap in the customer's security posture that cannot be compensated by any provider-side control.
The financial impact is direct. Regulatory penalties under GDPR for failing to implement appropriate technical measures apply to the data controller, which is the customer, not the provider. A cloud provider's ISO 27001 certification does not satisfy the customer's independent obligation to protect personal data within their own tenant. In 2023, the average cost of a data breach involving cloud misconfigurations reached $4.9 million according to IBM's Cost of a Data Breach Report.
Real-World Consequences
The 2019 Capital One breach demonstrates the consequences of Shared Responsibility Model failures. A former AWS employee exploited a misconfigured Web Application Firewall (WAF) running on Capital One's AWS infrastructure. The misconfiguration allowed the attacker to perform a Server-Side Request Forgery (SSRF) attack against the EC2 Instance Metadata Service (IMDS), which returned temporary IAM credentials. Those credentials were used to access over 100 million customer records stored in S3 buckets.
AWS infrastructure functioned exactly as designed. The WAF misconfiguration, the IAM role with excessive permissions attached to the WAF instance, and the absence of IMDSv2 enforcement were all Capital One's responsibility. The breach cost Capital One approximately $80 million in regulatory penalties and an estimated $300 million in remediation costs.
More recently, the 2021 Verkada breach involved compromised administrative credentials that provided access to security camera feeds across thousands of organizations. Verkada's cloud infrastructure was secure, but customer account security, including password policies and multi-factor authentication enforcement, remained each customer's responsibility.
Common Misconceptions
The most persistent misconception is that provider compliance certifications cover the customer's environment. They do not. A second misconception is that enabling a service activates its security features by default. In most IaaS and PaaS deployments, logging, monitoring, encryption, and access restrictions must be explicitly configured by the customer. A third misconception is that responsibility transfers entirely with managed services. Using a managed Kubernetes service such as GKE or EKS means the provider manages the control plane, but the customer still manages node security, pod security policies, network policies, and workload identity configurations.
---
CDA approaches the Shared Responsibility Model through the Planetary Defense Model (PDM), treating the customer's boundary as a sovereign perimeter that must be actively governed, not passively assumed. Within the SPH (Security Posture and Hygiene) and RGA (Risk Governance and Accountability) domains, the Shared Responsibility Model is a foundational operational document, not background reading.
Under the Autonomous Posture Command (APC) methodology, CDA operationalizes the Shared Responsibility Model by continuously mapping each deployed cloud service to its corresponding responsibility matrix and evaluating whether the customer's controls are implemented, configured, and monitored. The APC methodology's core principle, "Your posture adapts. Your hygiene never sleeps," reflects the operational reality that responsibility boundaries must be re-evaluated each time a new service is deployed, a service model changes, or a provider updates its documentation.
CDA's approach differs from conventional cloud security programs in three specific ways. First, CDA maintains a living service-to-responsibility map for every deployed service across all active cloud tenants. When a development team deploys a new PaaS service, the responsibility map is updated automatically through integration with infrastructure-as-code pipelines. Security controls required within the customer boundary are validated against the map before deployment is approved.
Second, CDA treats encryption key management as a non-negotiable customer responsibility regardless of service model. All sensitive data classifications require Customer Managed Keys (CMK), with key policies audited quarterly and rotation enforced at 12-month intervals. This ensures that encryption ownership remains within customer control independent of provider personnel access.
Third, within the RGA domain, CDA assigns a named accountability owner to each customer-side control category: a data owner for data classification and encryption, an identity owner for IAM policy governance, and a platform owner for OS patching and configuration management in IaaS deployments. These assignments are documented, reviewed during risk governance meetings, and tied to security incident response runbooks so that when a control failure occurs, the responsible party is immediately identifiable.
This operational specificity reflects CDA's position that the Shared Responsibility Model only functions as a security control when both parties actively govern their scope. Passive assumption of coverage is a governance failure that creates exploitable gaps in the customer's security posture.
---
---
---