Cloud Security Shared Responsibility Model

Reviewed by the Fully Compliance editorial team

Short answer: The shared responsibility model divides cloud security between provider and customer. The provider secures physical infrastructure, hypervisors, and the network backbone. You secure everything from the operating system upward in IaaS, from the application layer upward in PaaS, and user access and data governance in SaaS. Most cloud breaches happen on the customer side through misconfiguration — not because the provider's infrastructure failed.

The phrase "shared responsibility model" appears in every discussion about cloud security. It sounds straightforward: the cloud provider is responsible for some things, you're responsible for others. In practice, this division is often misunderstood or ignored. Organizations have deployed cloud infrastructure believing the provider was responsible for security that actually was their responsibility. They've been breached because they didn't understand what "shared" actually meant. Gartner projects that through 2025, 99% of cloud security failures will be the customer's fault. The shared responsibility model is not clever marketing. It's the actual framework that determines who is responsible for security at every layer of your cloud infrastructure. Understanding it is the difference between secure cloud deployments and vulnerable ones.

Providers Secure the Foundation — Physical Infrastructure and Hypervisors

Cloud providers — AWS, Azure, Google Cloud — manage the security of the infrastructure layer. This is the foundation everything sits on. They're responsible for physical security of the data centers — the locks, the access controls, the guards who prevent unauthorized people from walking in and pulling servers out. They're responsible for power, cooling, and backup power systems so their data centers keep running. They're responsible for the network infrastructure that connects the data centers to the internet and to each other.

They're responsible for the virtualization layer — the hypervisor that isolates your virtual machines from your neighbors' virtual machines. This isolation is critical. If the hypervisor is broken, an attacker in one customer's virtual machine could escape and access another customer's machine. But that's not your problem to solve. That's the provider's responsibility. They manage the operating system and control plane that runs the infrastructure. They provide you with access to compute, storage, and networking resources. They manage the scale and reliability so your resources are available when you need them.

This is where providers are incredibly secure. A breached Amazon data center would be catastrophic for millions of customers. But that's not where most cloud breaches happen. Most breaches happen at the customer layer, where you have responsibility.

Your Layer Is Where Security Breaks Down

You are responsible for everything from the operating system upward in infrastructure-as-a-service, everything from the application layer upward in platform-as-a-service, and your data and user access in software-as-a-service. You configure virtual machines. You patch operating systems. You install applications and keep them patched. You set up access controls. You configure firewalls. You choose encryption. You decide what data you store in cloud systems and who can access it.

This is your layer. This is where security breaks down. If an attacker gets into your environment, it's usually because of something in your responsibility layer: misconfigured access control, unpatched operating system, weak credentials, overpermissive application, user error, or insider threat. Providers provide tools to help you do this correctly. But tools aren't security. Using tools correctly is security.

The implication is clear: you cannot assume the provider is responsible for your security in any model. You have to understand explicitly what you're responsible for and execute on it. Organizations have been breached in infrastructure-as-a-service because they didn't patch systems. Organizations have been breached in software-as-a-service because they misconfigured access controls. The responsibility line is real, and failing to execute on your side means your security fails.

The Responsibility Line Shifts by Service Model

The responsibility line moves depending on what you're using. Understanding where the line is for your specific service is critical. If you're using infrastructure-as-a-service like AWS EC2 or Azure Virtual Machines, you're responsible for the operating system and everything above it. The provider is responsible for the infrastructure.

If you're using platform-as-a-service like AWS RDS (managed database) or AWS Lambda (serverless functions), the provider is responsible for the platform and you're responsible for the application or data and configuration. AWS patches the database, you control who accesses it and what encryption keys to use. AWS handles Lambda scaling and runtime, you handle what code runs and what data it accesses.

If you're using software-as-a-service like Microsoft 365 or Salesforce, the provider is responsible for almost everything. You're responsible for user management and data governance. The provider handles the application, the infrastructure, the patching, the updates.

The same organization will have all these services and needs to understand responsibility for each. Your email is SaaS — the email provider handles security. Your database is PaaS — the database provider handles the platform, you handle access control. Your file servers are IaaS — you handle the servers, the provider handles the infrastructure. You have to understand the specific responsibility line for each service you use, not assume a general model applies everywhere.

Misconfiguration Is the Root Cause of Most Cloud Breaches

When cloud breaches happen, most are caused by misconfiguration on the customer side, not by provider infrastructure failure. A public S3 bucket exposing data to the internet is misconfiguration. An EC2 instance with security group allowing all inbound access is misconfiguration. Overpermissive IAM policies are misconfiguration. Unpatched operating systems are misconfiguration. These are all on the customer side of the responsibility line. According to the 2024 Verizon DBIR, misconfiguration and related human errors contributed to 68% of breaches involving a human element.

Providers have security tools to help you identify misconfiguration. AWS Config identifies non-compliant configurations. Azure Policy prevents non-compliant resources from being created. Google Cloud Security Command Center shows you your compliance posture. But these are tools you have to use. They don't automatically fix misconfiguration. They identify problems and flag them. You have to fix them.

This means your security depends on your ability to configure correctly. For many organizations, that's the challenge. They understand the responsibility but lack the expertise to configure correctly. This is where third-party tools and consultants add value. They help you configure cloud environments correctly. But the responsibility is still yours. Hiring someone to configure your cloud correctly transfers the execution but not the accountability.

Provider Audit Reports Do Not Cover Your Side

Shared responsibility affects audit and compliance directly. If you're audited for compliance — whether SOC 2, ISO 27001, PCI DSS, or some other framework — the auditor will ask what the cloud provider is responsible for and what you're responsible for. You have to prove you've fulfilled your responsibility. If your responsibility is patching systems and you haven't been patching, you fail compliance.

The auditor will review provider audit reports to understand what the provider has proven about their security. Providers like AWS, Azure, and Google Cloud have SOC 2 reports and compliance certifications. These prove that the provider has appropriate controls for their responsibility area. Your responsibility is to understand what the provider has proven and what you still need to do.

Assuming the provider audit report covers everything you need is a common and dangerous mistake. Each provider audit report covers specific controls and specific scope. There are gaps between the audit scope and your environment. You're responsible for those gaps. If your compliance requires encryption of data at rest and the provider's audit report covers their encryption infrastructure but doesn't cover your configuration of encryption keys, you're responsible for verifying that you've configured encryption correctly.

Hybrid Services Make the Line Harder to Find

Some services are harder to categorize because they're partially managed. Kubernetes is a clear example. You can install and manage Kubernetes yourself — you own everything. Or you can use managed Kubernetes like AWS EKS, Azure AKS, or Google GKE where the provider manages the control plane and you manage the worker nodes. Or you can use serverless container services where the provider manages everything.

Container images are your responsibility regardless. If you build a container image with vulnerabilities, that's your problem. Network policies within Kubernetes are your responsibility. Workload security is your responsibility. The provider manages the platform and infrastructure, but you manage what runs on it.

This hybrid responsibility is common with modern services. You need to understand the specific responsibility line for each service you use. A general model that works for IaaS doesn't work for managed Kubernetes. A model that works for SaaS doesn't work for PaaS. The specifics matter.

Validate What Your Provider Has Proven — Then Prove the Rest

Cloud providers should have third-party audits proving their security. AWS, Azure, and Google Cloud all have SOC 2 reports covering their infrastructure controls. These reports prove that the provider has appropriate controls for their responsibility area. You should request these reports from your provider and review them. Understand what scope they cover. Sometimes reports are limited to specific services or regions. The audit report is evidence that the provider is meeting their responsibility.

Your responsibility is to ensure you're meeting yours. The provider's SOC 2 report doesn't exempt you from auditing your configuration. You still need to verify that you've configured services correctly, patched systems, implemented appropriate access control, encrypted data appropriately. You need to perform your own security assessment of your side of the responsibility line.

Some organizations use the provider's audit report as an excuse to skip their own security work. They say "we use AWS and AWS has a SOC 2 report so we're secure." That's not how shared responsibility works. The provider's audit proves they're doing their job. You still have to do yours.

The Math Favors Prevention Over Breach Recovery

Many organizations understand the shared responsibility model conceptually but don't execute properly because they underestimate the cost of execution and overestimate the probability of avoiding a breach. Patching systems costs money and time. Configuring access control correctly is more work than granting broad access. Encryption adds cost and complexity. Logging and monitoring add operational overhead.

But the cost of a breach is exponentially higher. The Ponemon Institute's 2024 Cost of a Data Breach report puts the average cost at $4.88 million — and that figure rises significantly for organizations in regulated industries. A breach means lost data, disrupted operations, regulatory fines, reputational damage, legal liability. The math is clear. But organizations often operate as if breach is hypothetical and cost is immediate, so they underinvest in security.

The shared responsibility model is explicit: you have responsibilities. Meeting those responsibilities costs money and effort. Not meeting them creates risk that becomes very real when something goes wrong. The question isn't whether to spend on security. It's whether to spend on prevention or pay for breach recovery.

Build a Security Program That Covers Your Side

Implementing shared responsibility correctly means having a security program that covers your side of the responsibility line. This program should include understanding what you're responsible for for each service you use, auditing yourself against those responsibilities, identifying gaps, remediation planning, and ongoing monitoring.

Start by inventorying your cloud services. What's IaaS, what's PaaS, what's SaaS? For each, understand the responsibility line. For IaaS services, you're responsible for patching, hardening, access control, monitoring. For PaaS services, you're responsible for application security, data classification, access control. For SaaS services, you're responsible for user management, data governance, access control.

Once you understand your responsibilities, assess yourself. Are you doing what you should be doing? Most organizations find they're not. They haven't configured access control properly. They're not patching systems. They're not monitoring for security issues. The gaps become your remediation backlog. Remediate systematically. Start with high-risk items. A public S3 bucket is high risk. An unpatched system with known vulnerabilities is high risk. Work through your backlog. As you fix issues, your security posture improves. This is ongoing work, not a project with an end date. Cloud environments change constantly. New services are deployed, new users are added, configurations change. Your security program has to keep up.

Shared Responsibility Requires Execution, Not Just Understanding

Shared responsibility means the provider handles infrastructure security and you handle configuration security. The division changes by service model but the principle is the same. Your responsibility is to understand what you're responsible for, audit yourself against that responsibility, and execute on it.

The challenge isn't understanding shared responsibility. Organizations generally understand the concept. The challenge is executing on it. You have to patch systems consistently. You have to control access precisely. You have to monitor for security issues. You have to respond when problems are found. This requires planning, resources, and sustained effort.

Organizations with secure cloud environments are the ones that made security a priority from the start and kept it a priority. Organizations with breached cloud environments are often the ones that did the minimum to get something running and assumed the rest would be fine. It won't be. When you're designing your cloud architecture, involve security in the design. Understand the responsibility boundaries for each service. Verify that provider audit reports cover relevant controls. Plan to execute on your side of the responsibility line. Understanding shared responsibility is the first step. Actually doing it is the second.

Frequently Asked Questions

What does the cloud provider secure versus what I secure?
The provider secures physical infrastructure — data centers, power, cooling, hypervisors, and network backbone. You secure everything built on top of that: operating systems (IaaS), applications and data (PaaS), and user access and data governance (SaaS). The exact line depends on your service model.

If my cloud provider has a SOC 2 report, does that mean I'm compliant?
No. The provider's SOC 2 report covers their infrastructure controls only. Your auditor will still require you to demonstrate that your configuration, access controls, patching, encryption, and monitoring meet your compliance obligations. The provider's report proves their side — you still have to prove yours.

What is the most common cause of cloud breaches?
Customer-side misconfiguration. Gartner estimates that through 2025, 99% of cloud security failures will be the customer's fault. Public storage buckets, overpermissive access policies, unpatched systems, and misconfigured network rules account for the vast majority of cloud security incidents.

How do I know what I'm responsible for in each cloud service?
Map every cloud service you use to its service model — IaaS, PaaS, or SaaS. Each major provider publishes shared responsibility documentation. For IaaS, you own the OS and everything above it. For PaaS, you own the application and data. For SaaS, you own user access and data governance. Review each service individually, because hybrid services like managed Kubernetes have nuanced responsibility boundaries.

How much does it cost to execute my side of shared responsibility?
Costs vary by environment size and complexity, but the Ponemon Institute's 2024 data shows the average breach costs $4.88 million. Investing in patching, access control, encryption, and monitoring is a fraction of that figure. The financial case for proactive security execution is not ambiguous.

Fully Compliance provides educational content about IT compliance and cybersecurity. This article reflects general information about cloud shared responsibility models as of its publication date. Cloud platforms, services, and responsibility boundaries evolve — consult with qualified cloud architects for guidance specific to your environment and services.