The cloud shared responsibility model splits security into two halves: the provider secures the cloud (physical facilities, hardware, the hypervisor, and core networking), and you secure what you put in the cloud (data, identities, access policies, network configuration, and—on IaaS—the guest operating system). The dividing line slides up the stack as you move from IaaS to PaaS to SaaS, but two things never transfer to the provider under any model: your data and your identities. Gartner has projected that through 2025, 99% of cloud security failures will be the customer's fault—almost all of them misconfiguration on the customer side of that line.
That summary is the part an AI Overview can flatten into three sentences. What it can't show you is where the line actually sits for each service model, or the specific settings that quietly land on your side of it. Below is a stacked responsibility matrix you can read at a glance, a service-model comparison table, and the exact misconfigurations that account for most breaches—so you can stop guessing which security work is yours.
The Line, Visualized: Who Owns What as You Move Up the Stack
The single most useful mental model is a layer stack. On-premises, you own everything. As you adopt more managed services, layers transfer to the provider from the bottom up—but the top of the stack (data and identity) stays yours in every model.
Read it left to right: the further right you go (more managed), the more layers turn green (provider). Read it top to bottom: the top two rows stay blue (you) all the way across. That amber band is the part every breach post-mortem comes back to.
What Is the Shared Responsibility Model?
The shared responsibility model defines the security boundary between cloud providers and their customers:
- Cloud providers are responsible for security of the cloud (infrastructure, hardware, facilities)
- Customers are responsible for security in the cloud (data, access, configurations)
Think of it like renting an apartment. The landlord maintains the building structure, plumbing, and electrical systems. But you're responsible for locking your door, not leaving valuables in plain sight, and who you give keys to.
Why This Matters
Many organizations assume their cloud provider handles all security. This leads to:
- Public S3 buckets exposing sensitive data (the provider secures S3 infrastructure; you secure bucket policies)
- Overly permissive IAM roles granting attackers access (the provider secures IAM infrastructure; you configure permissions)
- Unpatched virtual machines with known vulnerabilities (the provider secures hypervisors; you patch OS)
- Disabled logging preventing incident investigation (the provider offers logging; you must enable it)
The 2024 National Public Data breach exposed 2.9 billion records through misconfigured database access—a customer responsibility, not a provider failure.
The misconfigurations that land on your side of the line
| Misconfiguration | What the provider gives you | What you failed to do (your job) | The fix |
|---|---|---|---|
| Public object storage | Secure S3/Blob/GCS infrastructure + Block Public Access controls | Left bucket/ACL policy open | Enforce Block Public Access; audit ACLs and bucket policies |
| Over-permissive IAM | The IAM engine and policy language | Granted * or broad roles | Apply least privilege; scope roles; review with access analyzers |
| Unpatched VM | Secured hypervisor and host | Skipped guest-OS patching | Automate OS patching (SSM, Update Manager, OS Config) |
| No audit trail | CloudTrail / Activity Log / Cloud Audit Logs (available) | Never enabled or centralized logs | Turn on org-wide logging; ship to a monitored store |
| Unencrypted data | KMS and encryption features | Didn't enable encryption or manage keys | Enforce encryption-at-rest defaults via policy |
Notice the middle column: in every row the provider built and secured the feature. The breach happened in the last two columns—the configuration you own.
What Cloud Providers Secure
All major cloud providers handle:
Physical Security
- Data center facilities with 24/7 security
- Biometric access controls
- Video surveillance and intrusion detection
- Environmental controls (fire suppression, cooling)
Infrastructure Security
- Network infrastructure (routers, switches, load balancers)
- Hypervisor and virtualization layer
- Storage systems and hardware encryption
- Physical host security
Compliance & Certifications
- SOC 1, SOC 2, SOC 3 reports
- ISO 27001, ISO 27017, ISO 27018
- PCI DSS (for infrastructure)
- FedRAMP, HIPAA eligibility
- Regional certifications (C5, IRAP, etc.)
What Customers Secure
Your responsibilities vary by service model (IaaS, PaaS, SaaS), but generally include:
Always Your Responsibility
| Area | What You Must Do |
|---|---|
| Identity & Access | Configure IAM policies, MFA, least privilege |
| Data | Encrypt data, classify sensitivity, manage keys |
| Network Configuration | Set security groups, NACLs, firewall rules |
| Application Security | Secure code, patch applications |
| Logging & Monitoring | Enable CloudTrail/Activity Logs, configure alerts |
| Compliance | Meet regulatory requirements for your industry |
Varies by Service Model
IaaS (EC2, VMs, Compute Engine):
- Operating system patches and updates
- Antivirus and endpoint protection
- Host-based firewalls
- Application stack security
PaaS (Lambda, App Service, Cloud Functions):
- Application code security
- Runtime configuration
- Dependency management
SaaS (managed services):
- Access management
- Data classification
- Usage policies
Service-Model Responsibility at a Glance
| Layer | On-Prem | IaaS (EC2/VMs) | PaaS (Lambda/App Service) | SaaS (managed) |
|---|---|---|---|---|
| Data & content | You | You | You | You |
| Identity & access | You | You | You | You |
| Application code | You | You | You | Provider |
| Operating system | You | You | Provider | Provider |
| Network controls | You | You* | Provider | Provider |
| Virtualization | You | Provider | Provider | Provider |
| Hardware & facilities | You | Provider | Provider | Provider |
| Which to pick when | Max control / regulatory isolation | You need OS-level control or custom stacks | You want to ship code without managing servers | You want an outcome, not infrastructure |
*Network controls on IaaS are shared: the provider owns the physical fabric, you own security groups, NACLs, route tables, and firewall rules.
The pattern is consistent: the two rows you can never delegate are data and identity. Every other layer can move to the provider by choosing a more managed service—but no service model hands the provider your access policies or your data classification.
Shared Responsibility by Provider
AWS Shared Responsibility Model
AWS divides responsibility along service lines:
AWS Manages:
- Global infrastructure (regions, availability zones, edge locations)
- Hardware and networking
- Managed services infrastructure
- Hypervisor and below
Customer Manages:
- Guest operating system (for EC2)
- Application software
- Security group configuration
- Network ACLs
- IAM policies and permissions
- Data encryption (at rest and in transit)
- Client-side encryption and integrity
For managed services like RDS, AWS handles OS patching, but you manage database users and access.
Azure Shared Responsibility Model
Azure uses similar divisions with Microsoft branding:
Microsoft Manages:
- Physical datacenters and hosts
- Physical network
- Hypervisor
Customer Manages (varies by service):
- Identity and directory infrastructure
- Applications
- Network controls
- Operating system (for VMs)
- Accounts and identities
- Devices (endpoints)
- Information and data
Azure provides clear documentation mapping responsibilities by service type.
GCP Shared Responsibility Model
Google Cloud calls this "shared fate" and emphasizes partnership:
Google Manages:
- Hardware and physical infrastructure
- Low-level infrastructure (firmware, networking)
- Platform-level security services
- Encryption of data in transit between facilities
Customer Manages:
- Access control (IAM)
- Application-level security
- Network configuration (VPC, firewall rules)
- Content and data classification
- Operating system security (for Compute Engine)
GCP's secure by default approach reduces customer burden but doesn't eliminate it.
Common Misconceptions
"The cloud provider handles security"
Reality: Providers secure infrastructure; you secure everything you deploy on it. A misconfigured security group is your responsibility, even though the provider built the security group feature.
"Compliance certifications mean I'm compliant"
Reality: Provider certifications (SOC 2, ISO 27001) cover their infrastructure. You must achieve your own compliance for your applications and data. A HIPAA-eligible service doesn't make your deployment HIPAA-compliant.
"Managed services eliminate security work"
Reality: Managed services shift responsibilities but don't eliminate them. RDS handles database patching, but you still manage database users, encryption settings, and network access.
"Default configurations are secure"
Reality: Defaults prioritize functionality over security. S3 buckets weren't private by default until 2023. Always review and harden configurations.
How to Map Your Responsibilities
Step 1: Inventory Your Services
List every cloud service you use. For each service, determine:
- Is it IaaS, PaaS, or SaaS?
- What does the provider manage?
- What do you manage?
Step 2: Review Provider Documentation
Each provider publishes detailed responsibility matrices:
Step 3: Implement Security Controls
For each customer responsibility:
- Define security standards
- Implement technical controls
- Automate compliance checking
- Document for auditors
Step 4: Monitor Continuously
Enable native security tools:
- AWS: Security Hub, GuardDuty, Config
- Azure: Defender for Cloud, Policy
- GCP: Security Command Center, Organization Policies
Shared Responsibility in Multi-Cloud
Multi-cloud environments compound complexity:
- Each provider has different terminology
- Responsibility boundaries vary slightly
- Policies must translate across platforms
- Security teams need expertise in all platforms
Consider:
- Standardizing on Infrastructure as Code (Terraform)
- Using cloud-agnostic security tools (CSPM platforms)
- Creating unified security policies mapped to each provider
- Training teams on all relevant platforms
Frequently Asked Questions
What is the shared responsibility model in cloud computing?
The shared responsibility model divides security duties between cloud providers and customers. Providers secure the underlying infrastructure (hardware, networking, facilities). Customers secure what they deploy (data, applications, access controls, configurations).
Who is responsible for data security in the cloud?
You are. Cloud providers secure the storage infrastructure, but customers are responsible for data encryption, access controls, classification, and backup. If your S3 bucket is public, that's a customer configuration error, not a provider failure.
Does the shared responsibility model vary between AWS, Azure, and GCP?
The core concept is identical—providers secure infrastructure, customers secure deployments—but terminology and specific boundaries differ. AWS emphasizes "security of the cloud vs. in the cloud." Azure maps responsibilities by service layer. GCP uses "shared fate" language emphasizing partnership.
What happens if there's a breach due to provider infrastructure failure?
Cloud providers are responsible for breaches caused by their infrastructure failures. Major providers have strong incident response and will notify customers. However, the vast majority of cloud breaches (Gartner says 99%) result from customer misconfigurations, not provider failures.
How do I prove compliance under the shared responsibility model?
Document which controls you inherit from the provider (using their SOC 2 reports, certifications) and which controls you implement. Auditors expect evidence of both inherited controls and customer-managed controls. Tools like AWS Artifact provide compliance documentation.
Take Action
- Audit your cloud inventory to identify all services in use
- Map responsibilities for each service using provider documentation
- Enable security monitoring (Security Hub, Defender for Cloud, SCC)
- Document for compliance showing both inherited and implemented controls
- Train your team on shared responsibility boundaries
Use our Cloud Security Self-Assessment to evaluate your current security posture against shared responsibility requirements.
For more cloud security best practices, see our comprehensive guide: 30 Cloud Security Tips for 2026.