Gartner predicts that 99% of cloud security failures through 2025 will be the customer's fault—not the cloud provider's. The root cause? Misunderstanding the shared responsibility model.
This guide explains what the shared responsibility model means, how it differs across AWS, Azure, and GCP, and what you're actually responsible for securing.
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.
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
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.
