Shared Responsibility Model

Last reviewed: August 2026

Why shared responsibility

Imagine operating your own data center in a leased building. The building’s access control, fire suppression systems, and power supply are the responsibility of the building management company. But the equipment inside the server room, data backups, and access permission settings are your responsibility as the tenant. No matter how good the building management company’s security is, if the server room password is set to “1234,” the security incident is your responsibility.

Cloud works the same way. Using the cloud doesn’t mean all security and operational responsibility transfers to the vendor. The areas of responsibility are clearly divided between vendor and user, and this is called the Shared Responsibility Model.

Core concepts

The vendor’s area of responsibility — “Security of the Cloud”

The cloud vendor is responsible for the security of the cloud infrastructure itself.

Physical security — data center buildings, access control, CCTV, biometric authentication
Hardware — management and replacement of servers, storage, and network equipment
Hypervisor — security and isolation of the virtualization layer
Network infrastructure — global backbone network, inter-region connectivity

The user’s area of responsibility — “Security in the Cloud”

The user is responsible for the security of the workloads running on the cloud.

Data — encryption, classification, and access control of stored data
Applications — security vulnerabilities in code, patch management
Access control — IAM policies, user permissions, MFA configuration
Operating system — OS patching, security configuration (for IaaS)
Network configuration — security groups, firewall rules, VPC configuration

How the responsibility boundary shifts by service model

The scope of user responsibility varies depending on the service model used (IaaS, PaaS, SaaS). The more you move toward SaaS, the more areas the vendor manages; the more you move toward IaaS, the wider the user’s management scope becomes.

Area	IaaS	PaaS	SaaS
Data	User	User	User
Application	User	User	Vendor
Runtime	User	Vendor	Vendor
Middleware	User	Vendor	Vendor
Operating system	User	Vendor	Vendor
Virtualization	Vendor	Vendor	Vendor
Server/storage/network	Vendor	Vendor	Vendor
Physical security	Vendor	Vendor	Vendor

For example, if you use EC2 (IaaS), OS patching is the user’s responsibility, but if you use RDS (PaaS), AWS handles OS patching. If you use Google Workspace (SaaS), Google handles application management as well, and the user only needs to manage data and access permissions.

Vendor comparison

Item	AWS	Azure	Google Cloud	OCI
Model name	Shared Responsibility Model	Shared Responsibility	Shared Fate	Shared Security Model
Basic structure	Traditional shared responsibility	Similar to AWS	Shared fate model	Traditional + emphasis on automation
Vendor’s additional support	Well-Architected Tool, Trusted Advisor	Defender for Cloud, Secure Score	Security Command Center, Assured Workloads	Cloud Guard, Security Zones
Security defaults	User must configure explicitly	User must configure explicitly	Stricter security defaults	Automatically enforced via Security Zones
Official documentation	AWS	Azure	Google Cloud	OCI

AWS presents the most traditional shared responsibility model. It clearly distinguishes between “security of the cloud” and “security in the cloud,” and requires users to directly manage their own areas of responsibility.

AWS provides various security services (GuardDuty, Security Hub, IAM Access Analyzer, etc.) to support this, but activation and configuration are up to the user. See Security Posture Management for details.

Model name: Shared Responsibility Model

Common gaps in practice

Even when the shared responsibility model is well understood, common security mistakes still occur in practice.

Public storage access — Data leaks caused by accidentally setting a bucket to public. See Data Protection
Excessive IAM permissions — Granting administrator privileges and never scaling them back. See IAM and Access Control
Encryption key management — Choosing between vendor-managed keys vs. customer-managed keys (CMK) vs. BYOK. See Secrets Management

Compliance

Depending on national and industry-specific regulations, security certifications may be required. Each vendor provides a service for directly downloading certification reports.

Vendor	Certification report service	Description
AWS	AWS Artifact	Direct download of SOC, ISO, PCI, and other audit reports
Azure	Service Trust Portal	Audit reports, compliance guides
Google Cloud	Compliance Reports Manager	Download ISO, SOC reports
OCI	Oracle Cloud Compliance	Certification status and reports

Common mistakes

“Using the cloud means security is the vendor’s responsibility” — The vendor is only responsible for infrastructure security. Data encryption, access control, and network configuration always remain the user’s responsibility.
“Managed services don’t need security configuration” — Even with PaaS/SaaS, access permissions, network exposure, and encryption settings must be configured directly by the user.
“Certification alone guarantees security” — A vendor’s SOC/ISO certification only proves infrastructure-level security; it does not guarantee the security of the user’s workloads.

Checklist

Have you identified the user’s area of responsibility for each service model (IaaS/PaaS/SaaS) in use?
Have you reviewed public access settings for storage (buckets/blobs) and blocked unnecessary public access?
Have you enabled the vendor’s security review tools (Trusted Advisor, Defender, Security Command Center, etc.)?

References

Standards and frameworks

Cloud Security Alliance — Security Guidance v4 — Cloud security best practices
Cloud Security Alliance — Cloud Controls Matrix (CCM) — Cloud security controls framework
NIST SP 800-144 — Guidelines on Security and Privacy in Public Cloud Computing