Cloud Security: The Shared Responsibility Model
One of the most common — and most expensive — misunderstandings in cloud computing is assuming the provider secures everything. They secure a great deal, but never all of it, and the split follows a clear, learnable pattern.
Updated 2026-08-06
The provider secures the cloud; you secure what you put in it
The shared responsibility model splits security duties into two halves. The cloud provider is responsible for the security of the underlying platform — physical data centres, the hardware, and the core infrastructure. The customer is responsible for security in how they use that platform — their data, their configuration choices, and often their own application code. Misreading which half is whose is one of the most common causes of real cloud security incidents.
How the split shifts by service model
The exact dividing line moves depending on which service model you are using, echoing the same layers from the IaaS/PaaS/SaaS article. With IaaS, you are responsible for almost everything above the physical hardware — the operating system, its security patches, and your application. With PaaS, the provider also takes on the operating system and runtime, leaving you responsible mainly for your application and its data. With SaaS, the provider manages nearly the entire stack, and your responsibility narrows down mostly to your own data, your account security, and who you allow to access it.
The part that catches people out: configuration
A huge share of real cloud security incidents are not the provider's infrastructure being breached — they are a customer's own storage bucket, database, or admin panel left open to the public by mistake. The provider offers secure default settings and controls, but applying them correctly is the customer's job. "The cloud got hacked" is, in practice, almost always "a customer misconfigured something the cloud gave them full control over."
A practical habit
Whenever you provision anything in the cloud — storage, a database, a server — explicitly check who can access it by default, rather than assuming it starts private. Many serious breaches trace back to exactly that assumption being wrong.
Why this model exists at all
Splitting responsibility this way lets cloud providers invest enormous, specialised resources into securing the parts every customer shares — physical security, network infrastructure — while customers retain the control (and responsibility) over the parts unique to their own application and data. Understanding exactly where that line sits, for whichever service model you are using, is one of the most practically important cloud computing skills there is.