What is the shared responsibility model?
The Shared Responsibility Model (SRM) is a cloud security framework that defines which security responsibilities are handled by the cloud service provider (CSP) and which are handled by the customer. Typically, CSPs are responsible for securing the cloud infrastructure, while customers are responsible for securing the workloads, data, and configurations they run in the cloud.
As Gartner notes, CSPs cannot offer complete security coverage—customers must understand the scope of their responsibilities to avoid security gaps and compliance issues, especially during cloud migration.
Failing to clearly define and understand their shared responsibility can lead to misconfigurations and improperly secured assets—two of the most common root causes of cloud breaches.
Shared responsibility model by cloud service provider
Each cloud provider structures their SRM slightly differently. Here’s how the major CSPs define their roles and customer responsibilities.
AWS shared responsibility model
This model states that AWS is responsible for the security of the cloud while customers are responsible for security in the cloud. While AWS works to keep its infrastructure safe, customers are in charge of IT controls such as encryption and identity and access management (IAM), patching guest operating systems, configuring databases, and employee cybersecurity training.
Microsoft azure shared responsibility model
This model states that, in an on-premises datacenter, a customer owns the whole stack. As the customer moves to the cloud, some responsibilities transfer to Microsoft. Those responsibilities will vary, depending on the type of stack deployment.
For all cloud deployment types, the customer owns their data and identities. They’re responsible for protecting the security of those data and identities, on-premises resources, and the cloud components they control. Regardless of the type of deployment, the customers will always retain the following data, endpoint, account, and access-management responsibilities.
Google cloud platform (GCP) shared responsibility model
This model states that an in-depth understanding is required for each service a customer uses, along with the configuration options each service provides and what Google Cloud does to secure the service. Every service has a different configuration profile, and it can be difficult to determine the best security configuration.
The customer is the expert in knowing the security and regulatory requirements for their business and knowing the requirements for protecting confidential data and resources. GCP has also introduced the concept of “shared fate,” which enables a customer to essentially purchase the right to pass a responsibility on to GCP.
Shared responsibility model by cloud delivery models
The Shared Responsibility Model shifts depending on the cloud delivery model your organization is using. As you move from Infrastructure as a Service (IaaS) to Platform as a Service (PaaS) and then to Function as a Service (FaaS) (also known as serverless), the cloud provider assumes more responsibility—while you, the customer, gain ease of use but lose some control and customization.
Here’s how the division of responsibilities typically breaks down:
Infrastructure as a Service (IaaS)
In IaaS, the CSP manages the core infrastructure, while the customer is responsible for nearly everything else, including the operating system and applications.
CSP is responsible for:
- Hardware
- Firmware
- Virtualization layer
Customer is responsible for:
- Operating system
- Containers
- Applications and functions
- Data
- User access and identity controls
Platform as a Service (PaaS)
In PaaS, the CSP manages more of the stack, including the runtime environment. The customer retains responsibility for data, users, and any applications built or deployed.
CSP is responsible for:
- Hardware and firmware
- Virtualization
- Operating system
- Containers
- Partial runtime and application support
Customer is responsible for:
- Data
- Functions
- Application configurations
- User access and identity controls
Function as a Service (FaaS) / serverless
In FaaS, the CSP manages nearly the entire environment. The customer is primarily responsible for the logic of the function and the data it processes.
CSP is responsible for:
- Hardware and firmware
- Virtualization
- Operating system
- Containers
- Runtime and application hosting
Customer is responsible for:
- Functions and code
- Data
- User access and identity controls
In contrast, for fully on-premises environments, the customer is responsible for every layer of the stack—including hardware, OS, networking, and all security controls.
Shared responsibility model in practice
In practice, the Shared Responsibility Model boils down to a simple rule: if you can configure, modify, or deploy it in your cloud environment, you're responsible for securing it. Anything you can't touch—like the underlying infrastructure—is the responsibility of your cloud service provider (CSP).
However, the division isn't always perfectly clean. Some responsibilities are shared between the customer and the CSP—these are known as shared control areas, and both parties must understand them fully to avoid confusion and risk.
For example, in AWS:
- Patch management is shared: AWS patches the infrastructure, but customers must patch guest operating systems and applications.
- Configuration management is shared: AWS maintains its infrastructure configuration, while customers are responsible for configuring their OS, databases, and workloads—often through infrastructure-as-code (IaC) tools like CloudFormation or Terraform.
- Security awareness training is shared: Both AWS and its customers are responsible for educating their own employees.
These shared controls require close coordination, but when handled correctly, they enhance the security posture of both the provider and the customer.
Benefits of the shared responsibility model?
The Shared Responsibility Model offers several key benefits that support cloud scalability, collaboration, and operational resilience.
Scalability
Within a CSP's ecosystem, customers can expand security capabilities as their business grows. Cloud providers like AWS, Azure, and Google Cloud offer scalable security architectures aligned with their SRM, giving customers the confidence to build out secure infrastructure without starting from scratch.
A clear division of responsibilities enables customers to scale their own data security policies in tandem with provider-managed controls.
Collaboration
SRM encourages a clear, cooperative relationship between provider and customer. Each party knows where their responsibilities begin and end, reducing confusion, overlap, and finger-pointing in the event of a security incident. Compared to managing security on a fully on-prem stack, this model reduces operational burden and increases accountability.
Architectural strength
Choosing a reputable CSP gives customers access to proven, enterprise-grade cloud infrastructure with built-in security controls. Customers can take advantage of the provider’s advanced monitoring, analytics, and threat detection tools—without needing to develop these capabilities in-house.
Shared responsibility model best practices
Following best practices can help your organization make the most of the Shared Responsibility Model—especially as you can scale cloud infrastructure, enforce compliance, and align with your cloud provider's security protocols.
Define a service level agreement (SLA)
A well-documented SLA outlines the security expectations between you and your cloud service provider. It clearly defines which party is responsible for which components, and ensures your CSP commits to performance and security obligations. It also formalizes what the CSP expects from you as a customer.
Clarify and delegate responsibilities
Don’t assume your cloud provider is handling everything. You may have chosen a trusted partner, but it’s still essential to define what falls under your control. This prevents confusion and reduces the risk of security gaps due to assumptions about who owns what.
For example, you might handle configuration management or data encryption, while the CSP handles physical infrastructure and network security.
Ensure regulatory compliance
Gray areas in responsibility can create major compliance risks. Use the SRM to clearly map responsibilities across systems and services to meet internal and external cloud compliance requirements, including frameworks like HIPAA, SOC 2, or ISO/IEC 27001.
Clarifying these roles improves accountability and helps both you and your provider maintain strong audit hygiene.