The shared responsibility model: which half of cloud security is yours
On this page
- Security of the cloud vs security in the cloud
- The line moves with the service model
- Where it actually goes wrong
- Turning the model into action
- FAQ
- What is the shared responsibility model in cloud computing?
- Who is responsible for a data breach in the cloud?
- Does the cloud provider back up my data?
- How does the split change between IaaS, PaaS, and SaaS?
The most dangerous sentence in cloud security is “the provider handles security.” They handle some of it, a well-defined half, and the other half is yours whether you staff it or not. The shared responsibility model is the map of that split, and misreading it is how competent teams end up writing breach notifications.
Security of the cloud vs security in the cloud
One line each:
- The provider secures the cloud itself, physical data centres, servers and storage hardware, the network backbone, and the virtualization layer. You will never patch their hypervisor or badge into their loading dock, and their track record on this half is genuinely excellent.
- You secure what you run on it, your data, who can access it, how every service is configured, and (depending on the service model) the operating system and application code.
The provider hands you secure building blocks. Stacking them insecurely is on you, and the platform will let you, because a public bucket is sometimes exactly what a customer wants.
All three major clouds publish the same idea under slightly different names: AWS’s “Shared Responsibility Model,” Microsoft’s shared responsibility matrix (which is explicit that the split shifts per service), and Google’s “shared fate” framing, which adds that they’d rather help you not fail. The mechanics below are the same everywhere.
The line moves with the service model
How much lands on you depends on how managed the service is, this is the practical payoff of understanding IaaS vs PaaS vs SaaS:
| Layer | IaaS (a VM) | PaaS (managed DB, app platform) | SaaS (a finished app) |
|---|---|---|---|
| Physical / data centre | Provider | Provider | Provider |
| Virtualization | Provider | Provider | Provider |
| OS & patching | You | Provider | Provider |
| Runtime / middleware | You | Provider | Provider |
| Application code | You | You | Provider |
| Configuration & settings | You | You | You |
| Identity & access | You | You | You |
| Your data | You | You | You |
Read the bottom three rows twice: configuration, access, and your data are yours in every model. Moving from a VM to a managed database sheds OS patching; it sheds nothing about who can log in or whether the endpoint is public. And those three rows are where the breaches live.
Where it actually goes wrong
Gartner’s much-quoted projection, that through 2025, 99% of cloud security failures would be the customer’s fault, matches what breach post-mortems keep showing. The failures are mundane and repetitive:
- Public storage buckets. An object storage bucket flipped to public, exposing customer records. The provider’s storage was flawless; the setting wasn’t. Still the most common cloud data leak in the world.
- Over-permissive access. Roles with far more permission than the job needs, so one compromised credential opens everything. The Capital One breach (2019) rode exactly this: a server-side flaw plus an IAM role that could read far more than it should have.
- Missing MFA. One phished admin password, no second factor, full account takeover.
- Unpatched IaaS. On a raw VM, the OS is yours, the provider will not patch it, and scanners find the ones nobody does.
- No backups. Assuming durability equals backup. The platform will durably store the results of your bad deploy.
Notice what’s not on the list: hypervisor escapes, data-centre intrusions, provider-side data loss. Those make headlines precisely because they’re rare.
Turning the model into action
The diagram is only useful as a to-do list:
- Classify what you run. For each system, know whether it’s IaaS, PaaS, or SaaS, that row-by-row table is now your ownership list. (SaaS isn’t “zero work”: sharing settings, admin access, and export/backup of your data are still yours.)
- Lock down the always-yours rows first, identity, access, configuration. The concrete steps are in securing your first cloud account.
- Enforce with guardrails, not memos. Org-level policies in your landing zone that make public buckets, unencrypted storage, and disabled logging impossible beat any training deck.
- Own data protection explicitly. Backups, versioning, retention, and a tested restore, decided and documented, not assumed.
FAQ
What is the shared responsibility model in cloud computing?
The division of security duties between the cloud provider and the customer. The provider is responsible for security OF the cloud, physical data centres, hardware, network backbone, virtualization. The customer is responsible for security IN the cloud, their data, identity and access, configuration, OS patching where applicable, and application code. Where the line sits depends on whether the service is IaaS, PaaS, or SaaS.
Who is responsible for a data breach in the cloud?
Almost always the customer, in practice. Gartner has projected that through 2025, 99% of cloud security failures will be the customer’s fault, public storage buckets, over-permissive roles, missing MFA, and breach post-mortems bear that out. Provider infrastructure failures are genuinely rare; misread responsibility lines are not.
Does the cloud provider back up my data?
Not in the sense you probably mean. Providers keep infrastructure durable, object storage is designed for eleven nines of durability, but durability protects against their hardware failing, not against your mistakes. Accidental deletion, a bad deploy, or ransomware will be faithfully and durably stored. Backups, versioning, and retention are yours to configure.
How does the split change between IaaS, PaaS, and SaaS?
The more managed the service, the more the provider takes. IaaS: you own the OS, patching, runtime, application, and data. PaaS: the provider takes the OS and runtime; you keep the application, configuration, and data. SaaS: the provider runs nearly everything; you keep your data, its sharing settings, and who can access it. No model takes access control or data ownership off your plate.
The provider’s half of this model is world-class; the breaches happen on the customer half, usually in a gap nobody knew they owned. If you want an experienced engineer to walk your estate and show you exactly where your side of the line is, and isn’t, being held, talk to a Webisoft cloud engineer.
Frequently asked questions
What is the shared responsibility model in cloud computing?
The division of security duties between the cloud provider and the customer. The provider is responsible for security OF the cloud, physical data centres, hardware, network backbone, virtualization. The customer is responsible for security IN the cloud, their data, identity and access, configuration, OS patching where applicable, and application code. Where the line sits depends on whether the service is IaaS, PaaS, or SaaS.
Who is responsible for a data breach in the cloud?
Almost always the customer, in practice. Gartner has projected that through 2025, 99% of cloud security failures will be the customer's fault, public storage buckets, over-permissive roles, missing MFA, and breach post-mortems bear that out. Provider infrastructure failures are genuinely rare; misread responsibility lines are not.
Does the cloud provider back up my data?
Not in the sense you probably mean. Providers keep infrastructure durable, object storage is designed for eleven nines of durability, but durability protects against their hardware failing, not against your mistakes. Accidental deletion, a bad deploy, or ransomware will be faithfully and durably stored. Backups, versioning, and retention are yours to configure.
How does the split change between IaaS, PaaS, and SaaS?
The more managed the service, the more the provider takes. IaaS: you own the OS, patching, runtime, application, and data. PaaS: the provider takes the OS and runtime; you keep the application, configuration, and data. SaaS: the provider runs nearly everything; you keep your data, its sharing settings, and who can access it. No model takes access control or data ownership off your plate.