Shared Responsibility, Drawn Plainly

The cloud provider secures the infrastructure; you secure everything running on top of it. The line moves depending on which service model you chose — and most incidents live right on that line.

Where the Boundary Sits

With IaaS, the provider owns physical security, hypervisor integrity, and network fabric. You own the operating system, every patch it needs, the firewall rules, the identity configuration, and the data. The provider cannot see inside your VM; that is the point, and it is also the exposure.

Move up to PaaS and the provider absorbs the OS and the runtime. You no longer patch the underlying stack — but you still own the application code, its dependencies, the access controls on the managed service, and every secret the application touches. The boundary shifts inward, toward the application layer, which is precisely where most real vulnerabilities live.

With SaaS the provider runs essentially everything. Your residual surface is narrower but still real: who has accounts, what permissions those accounts carry, whether single sign-on is enforced, what data users are allowed to export, and whether your configuration matches what you actually intended. SaaS misconfigurations — a shared link set to public, an admin account without MFA, an overly permissive data-retention policy — account for a disproportionate share of reported incidents.

What the Model Does Not Cover

The shared responsibility model is a liability diagram, not a security architecture. It tells you which party is contractually responsible for a given layer; it says nothing about whether your half of the arrangement is implemented correctly. Providers routinely publish versions of this diagram; those diagrams are accurate and also almost entirely silent on the question of whether the tenant is doing their job well.

The place where things go wrong is consistently the tenant side. Exposed storage buckets, over-privileged service accounts, unrotated credentials, unused access keys that were never revoked — these are not failures of the provider's infrastructure. They are failures to occupy the responsibility the model assigns to you. The provider's tooling can surface some of them; surfacing is not the same as fixing, and no provider tool substitutes for a coherent access-control policy.

The shared responsibility model is a liability diagram, not a security architecture.

There is also a grey zone that the clean diagrams understate: the IaaS, PaaS, SaaS service model boundary is rarely a sharp line in a real deployment. A single application can mix a managed database, a self-managed VM, and a third-party SaaS integration in one architecture. Each component carries a different responsibility split, and the aggregate attack surface is the union of all of them. Keeping that union visible — and honestly small — is the actual work.

The model is a starting point. Treat it as one.