The Shared Responsibility Model Is Read as a Promise and Written as a Boundary

Read the provider's column first and the diagram feels generous. Physical security, hypervisor patching, hardware lifecycle, the network fabric, the availability zones. All of it handled by an organisation with more security engineers than your entire company has staff. The natural conclusion is that most of the work is being done for you.

That is not what the document says. The shared responsibility model is a limitation of liability. It exists so that when something goes wrong there is a published, pre-agreed line separating what the provider owes you from what you owed yourself. The provider's column is not a list of benefits. It is the boundary of a contract, drawn by the party that wrote it.

The document answers a legal question, not a design one

Nobody sits down to write a shared responsibility diagram in order to help a customer architect a system. It is written to answer a narrower question: if a customer suffers a breach, was the provider at fault? The columns are drawn so that the answer is unambiguous in the provider's favour whenever the cause sits above the infrastructure layer.

This is a reasonable thing for a provider to do. Multi-tenant infrastructure at that scale cannot function on ambiguous accountability. But it means the document has a specific rhetorical shape, and reading it as a security assessment produces a systematic error. It tells you what the provider guarantees. It says almost nothing about what is hard, what is commonly done wrong, or where your actual exposure sits. Those things live entirely in your column, described in one or two words each.

"Customer data." "Identity and access management." "Configuration." Three phrases covering the overwhelming majority of real cloud incidents, given the same visual weight as "hardware maintenance."

The specific ways this misreading plays out, and which assumptions it quietly plants, are worth working through before you rely on it. The shared responsibility model gets misread in a consistent and predictable pattern, and the pattern repeats across providers because the documents are structurally similar.

The line moves every time you adopt a service

The second problem is that there is no single line. There is a line per service, and it shifts as you move up the abstraction stack. The same organisation running virtual machines, a managed database and a serverless function operates under three different divisions of labour at once, and the differences are not intuitive.

What you run	Provider handles	What stays entirely yours
Virtual machines	Hypervisor, host OS, hardware	Guest OS patching, agents, network rules, disk encryption choices
Managed database	Engine patching, backups, failover	Who can connect, from where, with which credentials, and whether it is reachable publicly
Object storage	Durability, availability, media	Bucket policy, public access settings, key management, retention
Managed Kubernetes	Control plane, API server, plane upgrades	Worker node images, workload identity, pod permissions, network policy
Serverless functions	Runtime, scaling, host patching	Function permissions, secrets handling, dependency vulnerabilities

One thing repeats in every row: identity and configuration never move to the provider. Not at any abstraction level. The higher you go, the more infrastructure work disappears, and the more concentrated your remaining responsibility becomes in exactly the two areas that are hardest to get right and easiest to get wrong quietly.

Managed Kubernetes is the clearest case. The provider takes the control plane, which is genuinely the fiddliest part to operate, and that reads as a large transfer of responsibility. What is left is workload identity, image provenance, pod-level permissions and network segmentation, which is where nearly all container incidents originate. What a managed Kubernetes service does not cover on your behalf is a longer list than the service page implies, and none of it is optional.

Storage is the standing proof

If the model were read correctly, exposed object storage would be a rare and embarrassing anomaly. It is neither. It keeps happening at organisations with security teams, budgets and audits, and it happens because the failure mode is not carelessness. It is a chain of individually reasonable decisions inside a system where the safe state and the convenient state differ.

A bucket is created for a legitimate reason. Access is widened to make a deployment work, or to let a partner pull a file, or to test something. The widening is documented nowhere, the person who did it moves teams, and the bucket accumulates content for two years under permissions set for a temporary purpose. Nothing in the provider's column prevents any step in that sequence, because every step is a customer action taken through a supported interface.

Understanding why cloud storage keeps ending up publicly readable matters more than another reminder to check your buckets, because the reminder has been issued for a decade and the incidents continue. The mechanism is organisational, and it responds to structural controls rather than to vigilance.

The evidence problem nobody plans for

Here is the part that surfaces at the worst possible moment. When an incident happens on your side of the line, the provider will not investigate it for you, and in most cases cannot. Their visibility ends where their responsibility ends. What happened inside your account, which identity did what, and in what order, is reconstructible only from logs you chose to enable, configured to retain, and stored somewhere the incident could not reach.

That last clause is the one that fails. Audit logs written into the same account as the workload, under permissions the compromised identity held, are not evidence. They are a resource an attacker can edit. Arranging audit logging that survives a compromise of the account it was recording is a design decision made in advance or not at all, and it sits squarely in your column of the diagram.

What to do with the diagram instead

Stop reading it top to bottom and read it as a scoping document for your own work.

1. List every managed service you actually use. Not the categories, the specific services.
2. For each one, write down what remains yours, using the provider's service-specific documentation rather than the summary diagram.
3. Put a named owner and an enforcing control against every item on that list. The items with no owner are your real inventory of risk.
4. Check whether your logs would survive the compromise of the account they describe.
5. Treat identity and configuration as permanent, non-transferable work, because at every abstraction level that is what they are.

The organisations that handle cloud security well are not the ones with the most tooling. They are the ones that read their own column as a workload rather than as a footnote. If you want that column reviewed against what you are actually running, our cloud security services start from that inventory rather than from a scanner report.