Moving to the cloud doesn’t mean handing off your security obligations. Every cloud service agreement divides security duties between the provider and the customer, and understanding that division is the difference between a protected business and an exposed one. This guide maps exactly who owns what, across every major service type.
What the Cloud Shared Responsibility Model Actually Means
The cloud shared responsibility model is a framework that divides security and compliance duties between a cloud service provider and its customers. The provider secures the infrastructure it operates. You secure everything you deploy, configure, and manage on top of that infrastructure.
The model exists because cloud providers operate infrastructure at massive scale across thousands of customers simultaneously. They’re in the best position to secure physical hardware, networking equipment, and the software that separates your workloads from another customer’s. But they have no visibility into your data, your user accounts, or how your applications are configured. That’s your domain.
The most common and costly misunderstanding in cloud security is this: assuming that moving to the cloud transfers all security responsibility to the provider. It doesn’t. Your provider secures the platform. You secure what you put on it.
What Your Cloud Provider Always Covers
Regardless of which service model you use, your cloud provider is responsible for securing the foundational layers of its platform. These responsibilities don’t shift.
Physical Infrastructure and Data Centers
Your provider controls physical access to data centers, manages power and cooling systems, and maintains the networking hardware that connects everything. AWS, Microsoft Azure, and Google Cloud all publish documentation confirming they own this layer entirely. You don’t manage a single physical server.
Hypervisor and Virtualization Security
The hypervisor is the software that separates one customer’s virtual machines from another’s. Keeping that boundary secure is the provider’s job. If a vulnerability in the hypervisor allowed one tenant to access another’s data, that would be a provider failure, not yours.
Core Platform Availability
Infrastructure-level disaster recovery, redundancy across availability zones, and platform uptime guarantees all fall to the provider. AWS, Azure, and Google Cloud each publish service level agreements (SLAs) that define their uptime commitments and what happens when they fall short.
How Cloud Security Responsibilities Shift by Service Model
Your specific security obligations change depending on which type of cloud service you use. The three models are IaaS, PaaS, and SaaS, and each one shifts the responsibility boundary in a meaningful way.
| Security Layer | IaaS | PaaS | SaaS |
|---|---|---|---|
| Physical Infrastructure | Provider | Provider | Provider |
| Hypervisor / Virtualization | Provider | Provider | Provider |
| Operating System | Customer | Provider | Provider |
| Runtime / Middleware | Customer | Provider | Provider |
| Application Code | Customer | Customer | Provider |
| Data | Customer | Customer | Customer |
| Identity and Access Management | Customer | Customer | Customer |
IaaS: You Own the Most
IaaS, or Infrastructure as a Service, gives you virtual servers, storage, and networking that you configure yourself. AWS EC2 and Azure Virtual Machines are common examples. The provider secures the physical hardware and virtualization layer. You’re responsible for the operating system, patches, middleware, application code, data, and access controls. If you don’t patch your OS, no one else will.
PaaS: The Provider Takes the OS
PaaS, or Platform as a Service, extends provider coverage to include the operating system and runtime environment. You deploy your application code into a managed environment. AWS Elastic Beanstalk and Azure App Service work this way. Your responsibilities narrow to your application code, the data it processes, and who can access it.
SaaS: You Still Own More Than You Think
SaaS, or Software as a Service, covers the full application stack. Microsoft 365, Google Workspace, and Salesforce are SaaS products. The provider manages everything from infrastructure to the application itself. But you still own user access management, data governance, and configuration settings. A misconfigured sharing permission in Microsoft 365 that exposes sensitive files is your failure, not Microsoft’s.
What Your Business Always Owns
Three security responsibilities stay with your business regardless of which provider or service model you use.
Of those three universal responsibilities, Identity and Access Management is arguably the most foundational — and the most frequently underestimated. No matter which cloud provider you use or which service model you operate under, controlling who can access your resources, and exactly what they can do with them, is entirely in your hands. Getting this wrong can expose sensitive data and critical systems even when everything else in your environment is configured correctly. Our deep dive into cloud identity and access management principles covers why IAM is so consequential and how to approach it strategically.
Identity and Access Management (IAM)
IAM refers to controlling who can log in, what they can access, and at what privilege level. AWS IAM and Azure Role-Based Access Control (RBAC) give you the tools to manage this, but the configuration is yours. Over-privileged accounts are one of the most common attack vectors in cloud environments. Enforcing multi-factor authentication (MFA) and applying least-privilege access principles are customer responsibilities across every service model.
Data Classification and Encryption
You decide what data is sensitive and how it must be protected. Encryption at rest and in transit is available on every major platform, but you must turn it on and apply it correctly. Leaving sensitive data unencrypted because you assumed the provider handled it by default is a gap that creates real compliance exposure under regulations like HIPAA, GDPR, and PCI-DSS.
Endpoint Security
The laptops, phones, and workstations your employees use to access cloud services are entirely your responsibility. A compromised endpoint can expose cloud credentials. Your provider has no visibility into those devices.
How Major Providers Define Their Side
AWS frames the model as “security of the cloud” versus “security in the cloud.” The provider handles security of the infrastructure. You handle security of everything you put inside it. This phrasing is worth internalizing because it maps cleanly to how incidents get investigated and attributed.
Azure publishes a detailed responsibility matrix that shifts by service type, making it a practical reference for IT managers conducting security reviews. Google Cloud follows the same structural logic. Organizations including Check Point, NEC, and Cisco Systems operate within this model as cloud service participants, building security products that address the customer-side responsibilities the providers don’t cover.
The Cloud Security Alliance (CSA) and the UK’s National Cyber Security Centre (NCSC) both reference the shared responsibility model as a baseline expectation for cloud security governance. Compliance frameworks like SOC 2 and ISO 27001 require you to demonstrate that your side of the boundary is covered, not just that your provider is certified.
Common Gaps That Create Real Risk
Where do businesses actually get into trouble? The patterns are consistent.
- Assuming SaaS means zero security work. Misconfigured sharing settings, weak passwords, and no MFA enforcement are customer failures in any SaaS environment.
- Neglecting IAM in IaaS deployments. Teams spin up AWS EC2 instances and leave admin accounts with broad permissions and no MFA. That’s an open door.
- Skipping encryption because it seemed automatic. Encryption is available, but you must configure it. Data sitting unencrypted in cloud storage is a compliance violation waiting to happen.
- Ignoring third-party integrations. Plugins and connected apps that access your cloud services fall outside provider coverage. Audit them regularly.
Steps to Align Your Security With the Model
- Identify your service models. List every cloud service your business uses and categorize each as IaaS, PaaS, or SaaS.
- Pull your provider’s responsibility documentation. AWS, Azure, and Google Cloud all publish this. Map it against your current security controls.
- Prioritize IAM, encryption, and endpoint security. These are the baseline customer-side controls that matter most across every model.
- Review annually. Revisit provider documentation when you add new services or when providers update their terms.
Why This Model Protects Your Business
Misunderstanding the shared responsibility model is one of the most documented causes of cloud data breaches. The risk isn’t theoretical. Compliance audits for SOC 2, HIPAA, and PCI-DSS require you to demonstrate that your side of the responsibility boundary is covered, with evidence. Knowing exactly what you own also helps you invest in the right security tools rather than paying for coverage your provider already delivers.
Your next step is straightforward: pull your provider’s shared responsibility documentation, compare it against your current security posture, and identify the gaps. That single exercise will tell you more about your actual cloud security exposure than any general checklist can.
Frequently Asked Questions
Does my cloud provider protect my data from breaches?
Your provider protects the infrastructure your data sits on. Protecting the data itself, including encryption, access controls, and backup policies, is your responsibility regardless of which provider or service model you use.
Who is responsible for patching in a SaaS environment?
In a SaaS environment, the provider handles all patching for the application and underlying infrastructure. Your responsibility is to manage user access, enforce authentication policies, and configure the application correctly.
Does my responsibility change if I switch from IaaS to SaaS?
Yes, significantly. Moving from IaaS to SaaS shifts OS, runtime, and application security to the provider. You retain responsibility for data governance, user access, and configuration settings in both models.
What security mistakes do businesses most often make in cloud environments?
The most common gaps involve weak identity and access management, missing encryption on stored data, and misconfigured permissions in SaaS tools. All three are customer-side responsibilities that providers cannot fix on your behalf.
How does the shared responsibility model affect compliance audits?
Compliance frameworks like HIPAA, GDPR, and PCI-DSS require you to demonstrate control over your side of the responsibility boundary. Your provider’s certifications cover their infrastructure. You must document and prove your own controls separately.
