“The cloud got hacked” is a common but usually inaccurate way to describe cloud security incidents. In the overwhelming majority of publicly documented cases, the provider’s own infrastructure wasn’t breached — a customer misconfigured something on their own side of a well-defined boundary. Understanding that boundary is the starting point for cloud security.
What the shared responsibility model actually says
The shared responsibility model divides security obligations between a cloud provider and its customers along a specific line, and every major provider publishes some version of it: AWS’s shared responsibility model, Google Cloud’s shared responsibility and shared fate framework, and Microsoft’s shared responsibility documentation all describe the same underlying split, in slightly different language.
The provider is responsible for security of the cloud: physical data center security, the host infrastructure, the virtualization layer, and the global network that makes the platform run at all. The customer is responsible for security in the cloud: how they configure identity and access, how they configure their network, what they do with their data, and the security of the application code they deploy.
Where the line actually moves
The exact line shifts depending on which service model is in use, a distinction covered in What Is Cloud Computing?. With infrastructure as a service, the customer is responsible for nearly everything above the physical hardware and virtualization layer, including the guest operating system. With platform as a service, the provider takes on responsibility for the operating system and runtime, leaving the customer responsible mainly for their application and its configuration. With software as a service, the customer’s responsibility narrows further, typically to how they manage user access and what data they put into the system.
This means “is this secure” is never a question with a single, service-independent answer — it depends on exactly which layer a given customer is responsible for under the specific service model they’re using, and whether they’ve actually secured it.
Why customer-side misconfiguration is the dominant failure mode
Given this split, it follows directly that the provider’s infrastructure being compromised and a customer’s own configuration being wrong are two very different failure modes — and the second is far more common in practice. A storage bucket left publicly accessible, overly broad permissions granted to a service identity (the same over-permissioning problem covered in Cloud IAM and the Principle of Least Privilege), or a database with no network restriction at all (the gap What Is a Virtual Private Cloud (VPC)? exists specifically to prevent) are all customer-side configuration failures. The provider’s infrastructure did exactly what it was configured to do; the configuration itself was the problem.
The practical implication: nothing is secure by default just because it’s “in the cloud”
A common misconception this model directly corrects: moving a workload to a major cloud provider does not, by itself, make that workload secure. The provider’s baseline infrastructure security is generally very strong — stronger, in practice, than most individual organizations could build and maintain on their own — but that only covers the provider’s half of the line. Everything on the customer’s half still has to be deliberately configured correctly, and left unconfigured or misconfigured, it’s exactly as vulnerable as it would be anywhere else.
This is why frameworks like zero trust architecture exist specifically for the customer side of this boundary — they’re strategies for getting the customer’s share of the responsibility right, not something the underlying cloud platform does automatically. It’s also why formal compliance audits like SOC 2 evaluate an organization’s own controls and practices, not just which cloud provider they happen to use.
A practical checklist implied by the model
Given the split described above, a reasonable starting checklist for the customer side includes: reviewing identity and access permissions against least privilege, confirming network resources aren’t more broadly exposed than intended, verifying data storage isn’t publicly accessible unless deliberately meant to be, and treating application-level security (input validation, dependency management, secrets handling) as entirely the customer’s problem, since it always is regardless of provider.
Key takeaway
The shared responsibility model draws a specific line: providers secure the infrastructure underneath a service, customers secure what they configure on top of it, and where exactly that line falls shifts depending on whether the service is IaaS, PaaS, or SaaS. Most real-world cloud security incidents happen on the customer’s side of that line, which means the provider’s strong infrastructure security is necessary but never sufficient on its own.
This article explains a general security framework; specific responsibilities vary by provider and service. See our disclaimer.