What the shared responsibility model actually omits
The provider secures the platform and almost nothing you configure, which covers most of what goes wrong. Physical security, the hypervisor and the service software are theirs. Identity, network exposure, data classification, retention and every setting reachable from the console or the API are yours, however poor the default. The part teams misread is not the division itself, which is published and unambiguous, but how far the line moves between one service and the next.
Where does the provider's responsibility actually stop?
At the point where a setting becomes reachable by you. That is the most reliable test available, and it is more useful than any diagram: if you can change it through the console, the API or a template, you own the consequences of how it is set. The provider owns the datacentre, the hardware, the hypervisor, the network fabric between their own facilities and the code of the service itself. Everything expressed as your configuration is on your side of the line.
The reason the diagrams confuse people is that they describe layers while the boundary actually follows service type. For a virtual machine you own the guest operating system, its patches and everything above. For a managed database you own the schema, the credentials, the network exposure and the backup retention, but not the engine patches. For a serverless function you own the code, its dependencies, its permissions and its triggers, and nothing beneath.
Nothing in any of those cases moves data protection or access control to the provider. They supply the mechanisms, encryption, identity policy, private networking, and operate them reliably. Whether you switched them on, and whether you switched them on correctly, is not something they undertake to check.
Which parts do teams consistently misread?
Four in particular: patching of anything above the service boundary, whether an exposed resource is exposed on purpose, key custody, and backup as distinct from replication. The table below shows how each of those shifts as you move from renting a machine to consuming a managed service, because the shift is exactly where assumptions carry over from the wrong model.
| Concern | IaaS virtual machine | Managed database | Serverless function |
|---|---|---|---|
| Operating system patches | Yours, including kernel and reboots | Provider | Provider |
| Runtime and library patches | Yours | Provider for the engine, yours for extensions | Yours, the dependencies are your code |
| Network exposure | Yours, security groups and routing | Yours, public accessibility is a setting | Yours, the trigger is the entry point |
| Identity and permissions | Yours | Yours | Yours, and the function's own role is the risk |
| Encryption keys | Provider-managed unless you choose otherwise | Same, custody is a decision you make | Same |
| Backup and tested restore | Yours | Retention is yours, restore testing always is | Not applicable, but your data store still needs it |
| Log retention | Yours | Yours | Yours, defaults are usually short |
Does the provider back up your data?
No, and this is the single most expensive misreading in the model. Providers offer durability, meaning your object is stored redundantly and is very unlikely to be lost by hardware failure. Durability protects against their failures, not yours. A delete you issue, or a delete issued by a compromised credential or a faulty script, is replicated as faithfully as a write, and the copies are all consistent with your instruction.
Replication across regions or zones is likewise not a backup. It is an availability control, and it propagates corruption and deletion by design. The controls that turn a store into something recoverable are point-in-time snapshots or versioning, retention that outlasts the time it takes to notice a problem, object lock or immutability where it matters, and a copy an ordinary production credential cannot delete.
Read the service level agreement with this in mind. It commits the provider to availability, and the remedy is a service credit. There is no clause that returns your data, which means recovery is an obligation you retain in full even on the most managed service in the catalogue.
What does the model mean for compliance?
You inherit the controls the provider operates and none of the controls you configure. Major providers publish independent audit reports, commonly ISO 27001 certification and SOC 2 examinations, plus a matrix that maps each control to whichever party is responsible. Those documents are genuinely useful to an auditor, and they cover the physical and platform layers so that your assessment does not have to.
They do not cover your account. An auditor asking how privileged access is granted, how logs are retained and made tamper-evident, or how personal data is classified is asking about configuration, which is why compliant infrastructure never adds up to a compliant system on its own. Expect to produce your own evidence for identity, change control, logging, encryption decisions and supplier management.
Where residency and jurisdiction are in play, the model gets more specific rather than less. Choosing a region places data at rest, but support access, telemetry and some global service endpoints may involve other locations, and the terms that govern this differ by provider and by contract. Treat it as a question for counsel with the provider's own documentation in hand rather than something to infer from a diagram.
How does it change with third-party SaaS?
It compresses, and you lose most of the levers. With a SaaS application you configure users, roles, sharing settings, integrations and retention, and nothing else. You cannot inspect tenant isolation, you cannot patch anything, and you usually cannot get raw logs at the depth an investigation would want. The remaining controls are contractual and administrative, which is a different discipline from the one your platform team practises.
That makes a small number of questions disproportionately important. Which sub-processors are used and how are changes notified. What audit logging is available to you, at what plan tier, and for how long. How do you export your data if the relationship ends, and in what format. What happens to your data on termination, and after what period. Who at the vendor can read your tenant, and is that access logged.
In the UK and EU the controller and processor distinction shapes those answers, and the equivalent framing elsewhere may differ, so the specifics belong with counsel. The security question you can answer yourself is narrower and often neglected: which of your staff can grant a third-party application access to your data, and whether anyone reviews what those integrations already hold.
What can you test this week?
Pick one plausible incident and trace, on paper, which party acts at each step. A credential is stolen and used to delete a production data store. Who detects it, from which log, within what window, and who restores what. Most teams discover at step two that the log they would need is not retained, or that the restore has never been attempted, and that finding is worth more than another policy document.
Then run two concrete checks. Restore one non-trivial data store into a scratch environment and time it, because an untested restore is a plan rather than a control. And list every resource in your estate that is reachable from the public internet, comparing it against the list someone would have written from memory. The gap between those two lists is the practical measure of how well the boundary is understood.
Finish by naming an owner for each managed service in use. The services that appear in an incident with no owner are almost always the ones adopted by a single team for a single project, which is where the shared responsibility model quietly fails: not because anyone misunderstood the diagram, but because nobody was assigned the side of it that belongs to you.
Common questions
- What is the shared responsibility model in cloud computing?
- It is the published division of security duties between a cloud provider and its customer. The provider secures the datacentre, hardware, hypervisor, network fabric and the service software. The customer secures everything they configure: identity and permissions, network exposure, data classification, encryption choices, retention and the code and dependencies they deploy. The most reliable test is that anything you can change through the console or API is yours to get right.
- Does the cloud provider back up my data?
- No. Providers offer durability, which protects against their hardware failures, and replication, which is an availability control. Neither protects you from a deletion or corruption you cause, because your instruction is replicated faithfully. Recovery requires you to configure snapshots or versioning, retention long enough to notice a problem, immutability where it matters, and a copy that ordinary production credentials cannot delete. Service level agreements pay credits, not data.
- Who is responsible for patching in the cloud?
- It depends entirely on the service model. On a virtual machine you patch the guest operating system, kernel and everything above it. On a managed database or queue the provider patches the engine, and you remain responsible for extensions, client libraries and credentials. On serverless the provider patches the runtime, but your dependencies are your code, so vulnerable libraries in a function package are yours to fix.
- Does using a compliant cloud provider make my system compliant?
- No. You inherit the controls the provider operates, evidenced through their audit reports and control matrices, which usually covers physical and platform layers. Everything an auditor asks about your configuration remains yours to evidence: how privileged access is granted and reviewed, how logs are retained and protected from tampering, how data is classified, and which encryption and residency decisions you made and why.
- How does shared responsibility work with SaaS applications?
- Your controls narrow to configuration and contract. You manage users, roles, sharing settings, third-party integrations and retention, and you cannot patch anything or verify tenant isolation. That makes a few questions decisive: which sub-processors are used, what audit logs you can actually obtain and for how long, how data is exported and deleted at termination, and which vendor staff can read your tenant.
- What is the fastest way to test whether we understand the boundary?
- Trace one incident on paper. Assume a credential is stolen and a production data store is deleted, then name who detects it, from which log, in what time window, and who restores what. Most teams stop at the second step because the log is not retained or the restore has never been tried. Follow it with an actual timed restore and a list of every internet-reachable resource.
