Continue your mission
The Shared Responsibility Model defines how security obligations are divided between cloud providers and customers, shifting based on service model (IaaS/PaaS/SaaS) from customer-managed to provider-managed across the technology stack.
# Shared Responsibility Model
The Shared Responsibility Model is a foundational cloud security framework that formally divides security obligations between a cloud service provider (CSP) and the customer consuming that provider's services. It exists because cloud computing eliminated the traditional perimeter where a single organization controlled every layer of the technology stack. Without a clear delineation, critical security functions go unowned, creating gaps that threat actors readily exploit. The model solves a specific operational problem: when two parties share an infrastructure, ambiguity about who secures what layer produces predictable failures. By making responsibility explicit and contractual, the model forces both the provider and the customer to acknowledge their respective obligations before a breach, not after.
---
The Shared Responsibility Model is a contractual and operational framework that partitions security duties across the cloud technology stack based on the service delivery model in use. The provider is responsible for security "of" the cloud, meaning the physical data centers, hardware, hypervisors, network fabric, and the foundational infrastructure that customers never directly touch. The customer is responsible for security "in" the cloud, meaning the data they store, the identities they manage, the applications they deploy, and the configurations they apply.
This model is not the same as a Service Level Agreement (SLA). An SLA governs availability, uptime, and performance guarantees. The Shared Responsibility Model governs security accountability. Conflating the two is a common and dangerous mistake: an SLA does not protect customer data if the customer misconfigures an S3 bucket.
The model also differs across service tiers. In Infrastructure as a Service (IaaS), the customer manages the operating system, network controls, middleware, and application layer. The provider manages physical infrastructure and virtualization. In Platform as a Service (PaaS), the provider absorbs responsibility for the OS and runtime environment, while the customer retains ownership of application code, data, and access management. In Software as a Service (SaaS), the provider manages nearly the entire stack; the customer's residual obligations are typically limited to user access provisioning, data classification, and client-side configuration.
What the model does not cover is equally important. It does not address third-party integrations, supply chain risk, or the security of code that a customer brings to the platform. It does not guarantee that a customer understands their responsibilities. And it does not function as a compliance certification. A workload can operate inside a FedRAMP-authorized cloud environment and still be grossly non-compliant because the customer failed to execute their portion of the control set.
---
The model operates as a layered stack where responsibility is assigned to one of two parties at each level: the provider or the customer. That assignment is fixed at the bottom and the top of the stack, and variable in the middle depending on the service model selected.
The fixed layers include physical security, hardware maintenance, network infrastructure, and hypervisor management on the provider side. These are non-negotiable regardless of whether the workload runs on IaaS, PaaS, or SaaS. On the customer side, the fixed layers include the data itself, the identities with access to that data, and any client-side encryption the customer chooses to apply. No cloud provider, regardless of marketing language, takes ownership of a customer's data governance or access control policies.
The variable layers sit between these fixed points: the operating system, the runtime environment, the middleware, the network configuration within the cloud tenancy, and the application code. These layers shift up or down the stack depending on the service model.
IaaS in practice: A company running virtual machines on Amazon EC2 is responsible for patching the operating system on every instance. AWS secures the physical host and the hypervisor. The customer secures everything above the hypervisor. If a customer runs an EC2 instance with an unpatched Log4j vulnerability and that instance is internet-facing, AWS has fulfilled its obligation. The customer has not. The breach that results is the customer's liability, not AWS's.
PaaS in practice: A development team deploying an application to Google App Engine hands OS and runtime patching responsibility to Google. The team is still responsible for the application code they deploy, the API keys they store, and the IAM permissions they grant to service accounts. A developer who stores a database credential in plaintext within application code has violated their portion of the model. Google securing the underlying infrastructure does not mitigate that exposure.
SaaS in practice: An organization using Microsoft 365 relies on Microsoft to secure the application, the infrastructure, and the runtime. But the organization retains full responsibility for configuring conditional access policies, enabling multi-factor authentication, classifying sensitive data before it enters the platform, and managing which external domains are permitted to receive shared files. The 2020 SolarWinds incident illustrated this dynamic clearly: Microsoft's infrastructure was not compromised, but customer tenants that failed to apply proper conditional access controls suffered lateral movement within their Microsoft 365 environments after attacker-controlled OAuth tokens were issued.
Multi-tenancy considerations: The model becomes more complex in multi-tenant environments where a single physical infrastructure serves multiple customers. Container platforms like Google Kubernetes Engine (GKE) create overlapping responsibility zones. Google manages the Kubernetes control plane, node OS patching, and cluster networking. The customer manages pod security policies, container image scanning, network policies between services, and service account permissions. A misconfigured pod security policy that allows privileged containers creates a breakout risk that sits entirely on the customer side, even though the underlying Kubernetes infrastructure is managed by Google.
Configuration boundaries: The most frequent failures occur at configuration boundaries where both parties share interface points. Take AWS S3 bucket policies. AWS manages the underlying storage infrastructure, encryption in transit to AWS endpoints, and the access control engine that evaluates bucket policies. But the customer writes the actual bucket policy language, assigns IAM permissions to users and roles, and configures bucket-level settings like public access blocks. A customer who writes a bucket policy with "Principal": "*" has created public read access to potentially sensitive data. AWS's infrastructure operates exactly as designed. The customer's understanding of policy language was insufficient.
Automation and Infrastructure as Code: Modern cloud deployments increasingly use Infrastructure as Code (IaC) tools like Terraform, CloudFormation, or Pulumi. These tools shift responsibility for configuration accuracy to the customer's development pipeline. A Terraform module that creates security groups with overly permissive inbound rules will deploy those misconfigured security groups consistently across every environment where the module is applied. The customer must implement security scanning within their IaC pipeline to catch misconfigurations before they reach production. The cloud provider has no visibility into customer infrastructure definitions until they are applied.
Monitoring and detection gaps: The model creates natural visibility boundaries that affect security monitoring. Cloud providers monitor the health and security of their infrastructure but have limited visibility into customer-managed layers. AWS CloudTrail logs API calls made to AWS services but does not log what happens inside customer virtual machines. Customers must deploy their own endpoint detection and response (EDR) tools, log aggregation systems, and security information and event management (SIEM) platforms to monitor their portion of the stack. A breach that starts with a compromised virtual machine and moves laterally through customer-managed network segments may be invisible to the cloud provider's security operations center.
---
Failures in the Shared Responsibility Model are the dominant cause of cloud security incidents, not failures in the provider's infrastructure. Gartner has consistently projected that through 2025, 99 percent of cloud security failures would be the customer's fault. That projection has proven accurate in practice.
When the model is not understood, organizations treat cloud environments as if the provider has secured everything. Security teams that spent years managing on-premises firewalls often assume that moving to the cloud transfers risk wholesale to the provider. It does not. It transfers a specific and bounded set of risks while creating new categories of customer-owned risk, particularly around identity, configuration, and data exposure.
The consequences are well-documented and expensive. The Capital One breach of 2019 exposed over 100 million customer records. The root cause was a misconfigured web application firewall on an AWS EC2 instance, combined with an overly permissive IAM role that allowed the instance to access S3 buckets containing customer data. AWS's infrastructure performed exactly as designed. The customer's responsibility, specifically the firewall configuration and the IAM role permissions, was not executed correctly. The resulting regulatory fines, legal costs, and reputational damage exceeded $80 million in settlements alone.
The 2020 Microsoft Exchange Server vulnerabilities (ProxyLogon) demonstrated the model's boundaries in SaaS environments. Organizations running Exchange Online (Microsoft's SaaS email service) were protected because Microsoft patched the vulnerabilities in its managed infrastructure. But organizations running Exchange Server on-premises or in IaaS environments like Azure Virtual Machines had to patch their own instances. The vulnerability was identical. The exposure was determined entirely by which side of the shared responsibility model owned the Exchange Server installation.
A common misconception is that a shared responsibility model implies equal responsibility. It does not. The division is asymmetric and varies by tier. In SaaS, the customer's residual responsibility is narrow but critically important: access control and data governance. Neglecting those narrow obligations produces breaches that are indistinguishable in impact from full infrastructure compromises.
Another dangerous misconception is that compliance certifications held by the CSP extend automatically to customer workloads. A provider holding a SOC 2 Type II or ISO 27001 certification validates the provider's controls, not the customer's. Customers must independently satisfy their portion of any regulatory framework, whether that is HIPAA, PCI DSS, FedRAMP, or GDPR. Regulatory auditors understand this distinction clearly. Customers who do not understand it fail audits and, more consequentially, fail to protect the data they are trusted to secure.
---
CDA approaches the Shared Responsibility Model through the Risk Governance and Assurance (RGA) domain of the Planetary Defense Model (PDM), treating it not as a conceptual diagram but as a live accountability structure that requires continuous verification and operationalization.
The core methodology is Perpetual Compliance Assurance (PCA), which operates on the principle that compliance is not an event but a state. Traditional approaches to shared responsibility create responsibility matrices during initial cloud adoption and then assume those assignments remain static and well-understood. PCA recognizes that responsibility assignments must be continuously verified, updated as services evolve, and monitored for configuration drift in real-time.
CDA's implementation of PCA for shared responsibility begins with a Responsibility Attribution Matrix (RAM) that maps every security control in the applicable framework to either the provider or the customer, with specific internal team assignments for customer-owned controls. But unlike static responsibility charts, the RAM is integrated directly into the organization's cloud security posture management (CSPM) and compliance monitoring systems. When a customer-owned control drifts from its required configuration, the deviation is immediately attributed to the responsible team and tracked through resolution.
The methodology addresses a fundamental gap in conventional shared responsibility approaches: verification lag. Most organizations discover responsibility gaps during audit cycles, months after misconfigurations have been introduced. CDA's PCA approach detects and remediates these gaps in near real-time by treating the responsibility model as a continuous monitoring framework rather than a one-time planning exercise.
CDA also distinguishes between legal responsibility (what the cloud service agreement assigns to each party) and operational reality (what actually happens when controls fail). Through the RGA domain, CDA maps provider contractual obligations to measurable control outcomes, ensuring that customer teams do not over-rely on provider-side assurances that may be limited in scope or effectiveness.
This operational approach transforms shared responsibility from a division of labor into an integrated defense posture where both parties' obligations are continuously validated and any gaps are immediately visible and actionable.
---
---
---
CDA Theater missions that address topics covered in this article.
COBIT 2019 is ISACA's IT governance framework with 40 objectives across five domains, featuring a flexible design factor system that aligns IT strategy with business goals and maps to standards like NIST CSF and ISO 27001.
CMMC 2.0 requires defense contractors to demonstrate cybersecurity maturity at three levels.
HITRUST CSF harmonizes multiple frameworks into one certifiable standard for healthcare.
Written by CDA Editorial
Found an issue? Help improve this article.