What is the shared responsibility model, and why does it need modernization?
The shared responsibility model is a framework that defines the division of cloud security responsibilities between cloud service providers (CSPs) and their customers. CSPs manage the security of the cloud infrastructure itself, while customers must secure their data, applications, and configurations.
CSPs handle data center security, network hardware, and core services, including operating system patching and availability guarantees. For example, AWS secures its physical data centers and ensures the reliability of services like S3. However, AWS customers must manage access controls, configure permissions, encrypt data, and continuously monitor cloud resource usage.
Many organizations mistakenly assume their CSP handles all protection measures, including data and application security. Closing this gap is critical for securing cloud environments in 2026 and beyond.
The Cloud Security Workflow Handbook
Get the 5-step framework for modern cloud security maturity.
Why the old shared responsibility model no longer fits modern cloud environments
The shared responsibility model hasn’t evolved to meet the complexity of today’s cloud reality. With the rise of distributed, multi-cloud, and serverless architectures, and the surge in AI adoption, the boundaries of responsibility have become too fluid for the old model to remain useful.
Modern environments introduce ephemeral infrastructure, rapid DevOps cycles, and AI-driven workloads that require constant reassessment of who owns what. For example, AI models bring a new layer of accountability—from data lineage and model integrity to training security and inference protection—that traditional IaaS-based models never accounted for.
Responsibilities shift depending on service types and deployment patterns. Provider-managed tasks in SaaS could fall entirely on the customer in IaaS. These variations create dangerous gaps when security teams rely on outdated assumptions, leaving blind spots that attackers are quick to exploit.
Understanding the goal of modernization is clarity, not complexity
Modernizing the shared responsibility model isn’t about adding complexity or redefining every security rule. It focuses on clarifying the roles and ownership required to secure cloud services. The objective is to enable teams to understand what they own, how to protect it, and how to collaborate across disciplines.
A modern shared responsibility framework democratizes security across engineering, DevOps, and cloud operations by moving beyond a rigid contract model. With accurate role mapping and continuous validation, organizations can reduce risk while accelerating innovation.
How does shared responsibility vary by service type?
The shared responsibility model shifts depending on these types of cloud services:
Infrastructure as a Service (IaaS)
Platform as a Service (PaaS)
Software as a Service (SaaS)
Function as a Service (FaaS)
Each cloud service model draws the shared responsibility line in a different place. That boundary determines which security controls the CSP manages and which ones you must own.
Below is a practical overview of how responsibility shifts across each model:
Infrastructure as a Service
In an IaaS model, the customer assumes the broadest set of responsibilities. While the CSP secures the underlying infrastructure, including physical data centers, virtualization layers, and network components, customers must secure the rest of the stack. Customer duties include managing the operating system, middleware, runtime, applications, configurations, user access, and data.
For instance, in AWS EC2 deployments, Amazon ensures hypervisor security and infrastructure uptime. However, configuring firewall rules, installing patches, and enforcing identity and access management (IAM) policies remain the customer's responsibility.
Platform as a Service
PaaS environments shift more responsibility to the CSP, including managing and securing infrastructure, operating systems, runtime, and middleware. Customers focus on application code, data, and access controls.
For example, with Google App Engine, developers can write and deploy code without managing the underlying servers or runtime environment. While developers must still manage roles, permissions, and application security, they benefit from CSP-handled patching and system reliability.
Software as a Service
In the SaaS model, customers rely most heavily on the CSP. The provider secures the application, infrastructure, availability, and performance, while customers own user management, access controls, and data protection within the application.
For example, Microsoft 365 provides uptime, security patches, and data redundancy, while customers must configure role-based access, enforce multi-factor authentication, and protect sensitive documents through policies like data loss prevention.
Function as a Service and serverless computing
FaaS environments, such as AWS Lambda or Azure Functions, abstract infrastructure management almost entirely. Customers focus on code, permissions, and application logic, while CSPs maintain the runtime, operating system, and infrastructure scalability.
Security responsibilities here remain easily misunderstood. While the cloud provider auto-scales and updates the infrastructure, developers must secure environment variables, define IAM roles, and validate inputs and dependencies to ensure secure code execution.
For example, a team might use AWS Lambda to process uploaded images. The cloud provider automatically patches and scales the runtime—but the team must restrict the function’s IAM role, encrypt environment variables, and validate file inputs to prevent unauthorized access or code execution.
Multi-cloud and hybrid environments
In hybrid or multi-cloud deployments, customers spread workloads across various service types and cloud providers. This expansion introduces significant complexity to the shared responsibility model and increases the potential for configuration drift, blind spots, and role confusion.
Each cloud provider—including AWS, Microsoft Azure, and Google Cloud—uses its own model, terminology, and SLAs. Enterprises must unify these into a cohesive view and define internal ownership across platforms. A shared responsibility matrix clarifies roles across teams and cloud services while improving audit and compliance readiness.
What are customers’ cloud security responsibilities today?
Cloud customers actively secure their environments and don’t assume cloud providers manage all aspects of security. The shared responsibility model intentionally places key controls in the customer’s hands, particularly when configuration choices and access decisions directly affect risk.
In practice, those responsibilities focus on four core security areas, forming the foundation of effective cloud security ownership:
1. Data protection and encryption
Customers are responsible for safeguarding the confidentiality, integrity, and availability of their data, which involves moving beyond checking compliance boxes. Teams must consistently monitor encryption in transit and at rest to ensure continuous security. Misconfigured encryption policies remain a leading cause of cloud data breaches. Customers must also configure backup and recovery processes to guarantee business continuity.
Advanced Cloud Security Best Practices [Cheat Sheet]
This cheat sheet is built for hands-on practitioners who secure, build, and operate cloud environments day to day
2. Identity and access management
Controlling identity and access across cloud services demands constant attention to prevent unauthorized access. Customers must define and enforce least-privilege access policies, favor temporary credentials and IAM roles over long-lived access keys, and require multi-factor authentication (MFA).
Adopting modern practices such as just-in-time access, role-based access control, and federated identity helps teams enforce access boundaries and reduce lateral movement risk across cloud workloads.
3. Configuration and posture management
Misconfiguration remains one of the most persistent and damaging risks in cloud environments because cloud providers don’t dictate how customers configure services or apply security controls. To stay secure, teams must actively monitor for configuration drift, regularly validate their cloud posture, and ensure all workloads align with internal security standards.
Adopting continuous validation tools—like Cloud Security Posture Management (CSPM) and Infrastructure as Code (IaC) scanning—helps catch misconfigurations before they reach production. Automated remediation workflows further reduce exposure by closing gaps at scale.
4. Application and workload security
Customers are responsible for securing their applications and associated cloud workloads. Effective security includes implementing secure coding practices, conducting vulnerability scans before deployment, and integrating automated security tests into the CI/CD pipeline. Teams also define runtime security policies to detect anomalies after applications launch.
What are cloud service providers’ security responsibilities?
Cloud service providers secure the foundational components powering cloud services, protect physical infrastructure, maintain resilient cloud networks, and enable customers to meet compliance requirements. These responsibilities create the baseline that allows customers to build secure systems without managing physical infrastructure:
| Area | Cloud service provider responsibilities |
|---|---|
| Physical and infrastructure security | Operate secure data centers, enforce physical access controls, manage environmental systems, and secure servers, storage, and virtualization layers. |
| Core network and availability | Secure network infrastructure (including routers, switches, and inter-region links), provide DDoS mitigation, threat detection, and failover while meeting SLA-driven uptime commitments. |
| Shared services and compliance | Undergo third-party audits (e.g., SOC 2, ISO 27001, and FedRAMP), provide compliance artifacts, and support customers in meeting standards like HIPAA and PCI DSS. |
What CSPs don’t cover
CSPs don’t manage customer security tasks—and they don’t configure IAM policies, application permissions, or controls to prevent data exposure. Customers are responsible for securing their operating systems, cloud APIs, and in-app data flows to maintain a strong security posture.
Here’s a high-level view of excluded CSP coverage, though these capabilities vary by tool and infrastructure:
| Areas outside CSP coverage | Customer-owned responsibility |
|---|---|
| IAM policies and permissions | Define least-privilege roles, rotate keys, and enforce MFA. |
| Application-level controls | Configure app permissions, secure data flows, and validate inputs. |
| Customer-managed operating systems | Patch, harden, and monitor OS configurations. |
| Cloud APIs | Secure endpoints, authenticate callers, and monitor API usage. |
| In-app data exposure risks | Protect sensitive data, apply encryption, and enforce access controls. |
Where do responsibilities overlap, and how can teams avoid ambiguity?
Some responsibilities in the shared responsibility model fall into a gray area where both the customer and the CSP influence the security outcome. These overlapping areas often create confusion, especially when teams rely on assumptions rather than documented ownership. Clear boundaries and consistent communication help organizations reduce ambiguity and improve their security posture.
Common overlapping areas include:
Operating systems and patch management
Responsibility for securing the operating system (OS) varies by service type. In IaaS environments, customers perform OS hardening, patching, and configuration. In PaaS and SaaS models, however, the CSP manages OS-level security. Containers and managed Kubernetes services introduce shared ownership where providers secure the control plane while customers must secure worker nodes, container images, and workload configurations. These nuances underscore why teams must document OS responsibilities clearly to avoid drift and missed patch cycles.
Native vs. third-party tools
CSPs deliver native services for logging, identity, networking, and threat detection, but customers decide how to configure and use them. When customers deploy third-party tools, they assume responsibility for securing those tools, managing integrations, and validating configurations. Providers support the underlying infrastructure, but the customer must ensure that each tool aligns with internal security controls and compliance needs.
Network controls and segmentation
Both customers and cloud providers influence network security. CSPs secure backbone networks and offer foundational capabilities like virtual networks, firewalls, routing controls, VPC Peering, Transit Gateways, and PrivateLink. Customers are responsible for configuring segmentation rules, defining ingress and egress policies, and enforcing zero trust principles.
Despite available controls, misconfigured network policies remain a leading cause of cloud breaches—often due to the mistaken assumption that the provider automatically handles segmentation.
Server-based vs. serverless computing
Server-based computing tasks customers with managing OS-level security, runtime configurations, and patching. Serverless environments shift more responsibility to the cloud provider, though customers still own code quality, permissions, and event triggers. Incorrectly configured serverless functions can create vulnerabilities even while the provider maintains the operating environment.
Avoid confusion and assumption risk
Teams reduce ambiguity when they maintain a shared responsibility matrix outlining ownership across cloud services and cloud providers. Updating this matrix quarterly ensures it keeps pace with new features, deployments, and changes in team structure.
For example, Wiz automatically maps shared responsibility zones to help teams avoid assumption of risk. This visibility clarifies which risks belong to the customer and which reside with the provider.
Security Leaders Handbook: The Strategic Guide to Cloud Security
Learn the new cloud security operating model and steps towards cloud security maturity. This practical guide helps transform security teams and processes to remove risks and support secure cloud development.
Download Handbook
What are the biggest challenges that teams face with the shared responsibility model?
Even with clear definitions, organizations still struggle to operationalize the shared responsibility model. Modern cloud environments introduce scale, speed, and complexity that strain traditional security processes. These challenges often stem from unclear ownership, overreliance on manual processes, and misunderstandings over what cloud services actually provide:
Ambiguity and assumption risk
Many teams mistakenly believe that using cloud-native services automatically ensures cloud security, creating dangerous assumption gaps. For instance, relying on default Amazon S3 settings may leave data publicly accessible, or assuming that a private VPC endpoint restricts access to only authorized principals can also lead to unintended exposure.
Teams often think their cloud provider enforces least-privilege IAM by default, patches every workload automatically, or secures APIs out of the box. These false assumptions result in misconfigurations, excessive permissions, and data exposure.
While providers publish shared responsibility documentation, most organizations fail to operationalize it. Without clear internal processes, ownership becomes inconsistent, controls are duplicated or overlooked, and risk increases.
Responsibility fatigue
Cloud environments evolve quickly, and security teams frequently can’t keep pace without automation. Without automating tasks such as configuration validation, IAM cleanup, and patching workflows, teams struggle to consistently meet their security responsibilities.
Clear internal documentation helps teams stay aligned, but documentation alone fails to scale. Automated enforcement and real-time visibility reduce burnout, improve decision-making, and accelerate remediation.
Compliance confusion
While compliance frameworks reference CSP certifications, they don’t define customer-specific responsibilities. Teams often misunderstand which controls they must implement themselves. For example, SOC 2 or ISO 27001 attestations from a provider don’t guarantee compliance for customer-operated workloads.
Organizations benefit by mapping shared controls to frameworks such as NIST CSF, CIS Benchmarks, or internal governance models. This mapping reduces confusion during audits and ensures consistent implementation of security controls across service types.
How does Wiz simplify the shared responsibility model for modern cloud teams?
Wiz provides the clarity and visibility customers need to meet their responsibilities under the shared responsibility model while accelerating secure cloud adoption. In fact, we designed our platform to democratize cloud security, giving engineering, DevOps, and security teams a unified view of risk across AWS, Microsoft Azure, Google Cloud, and multi-cloud environments. This approach removes ambiguity, reduces friction, and enables teams to focus on their areas of ownership.
Here’s how Wiz streamlines ownership:
| Capability | What Wiz provides | How Wiz supports shared responsibility |
|---|---|---|
| Unified visibility into shared responsibility zones | Consolidates views of cloud workloads, configurations, network paths, identities, data stores, and runtime behaviors through the Security Graph. | Clarifies which risks belong to the customer and which to the CSP across IaaS, PaaS, SaaS, FaaS, and serverless environments, reducing blind spots. |
| Contextual risk mapping and prioritization | Correlates misconfigurations, vulnerabilities, permissions, identities, network exposure, runtime issues, and data sensitivity. | Highlights toxic risk combinations and pinpoints where customer-owned responsibilities require action. |
| Continuous monitoring and compliance automation | Detects configuration drift, permission changes, and emerging threats while mapping customer-side controls to NIST, CIS Benchmarks, PCI DSS, ISO 27001, and SOC 2. | Provides real-time compliance views, resource-level evidence, and automated reporting to strengthen outcomes under the shared responsibility model. |
Wiz integrates seamlessly with CI/CD pipelines, allowing customers to shift security left with automated checks before workloads reach production. These capabilities enable customers to fulfill their responsibilities and accelerate remediation times, even in complex multi-cloud environments.
Want to see how well you cover your side of the shared responsibility model? Try a free AWS Security Assessment with Wiz today to uncover hidden risks and misconfigurations and identify customer-owned areas that need your attention.
The Cloud Security Workflow Handbook
Get the 5-step framework for modern cloud security maturity.