The Shared Responsibility Model, Explained Without the Fog

Every major cloud provider publishes a shared responsibility model, and every diagram looks reassuringly tidy until an unpatched server or an open storage bucket makes the question concrete: whose job was that? This article lays out who secures what under IaaS, PaaS, and SaaS in plain terms, because the model is genuinely simple — the confusion comes from marketing fog around it, not from the idea itself.

What does the shared responsibility model actually say?

The short version: the provider secures the cloud itself, and you secure what you put in it. The provider owns the physical data centers, the hardware, the network backbone, and the virtualization layer. You own your data, your user accounts, and your configuration choices — always, in every model. Everything in between shifts depending on the service model, which is why the NIST SP 800-145 definitions of IaaS, PaaS, and SaaS matter here: they describe exactly which layers you control, and control is what determines responsibility.

One point we repeat to every client: responsibility for the consequences never transfers. If customer records leak because of a misconfigured bucket, the provider’s model will correctly note that bucket permissions were your job. Regulators and customers will agree.

Who patches what under IaaS, PaaS, and SaaS?

Patching is the cleanest way to see the boundaries, because someone concrete has to apply every update. Here is the split, layer by layer:

Layer	IaaS	PaaS	SaaS
Physical hardware and hypervisor	Provider	Provider	Provider
Operating system patches	You	Provider	Provider
Runtime and middleware	You	Provider	Provider
Application code and updates	You	You	Provider
Data, identity, access, configuration	You	You	You

Read the bottom row twice. Identity and configuration stay with the customer even in SaaS, where everything else belongs to the provider. Enforcing multi-factor authentication, removing departed employees’ accounts, and reviewing sharing settings is your work in every single model.

Newer service types sit between the classic columns rather than outside them. With containers on a managed Kubernetes service, the provider patches the control plane while you own the node images and everything inside your containers, including base-image vulnerabilities. With serverless functions, the provider takes the OS and runtime, but your function code and its dependencies remain yours to update. The test that resolves any gray area is control: if you can change a layer, you are responsible for it. When a vendor’s diagram is vague about a layer, ask them directly who applies updates to it and how fast — the quality of that answer tells you a lot about the vendor, too.

Walkthrough: a critical OS vulnerability drops on a Friday

Here is how the same event plays out three ways. On IaaS, the provider patches its hypervisors, but every one of your VMs waits for your team — if your inventory is incomplete, the unlisted VMs stay vulnerable indefinitely. On PaaS, the provider patches the OS and runtime under your application, usually before you have read the advisory; you only act if your own code bundles the affected component. On SaaS, there is nothing to do but confirm the vendor’s status page. When we ran this exercise with one client’s estate, the surprise was not the split itself — it was discovering how many “PaaS” services had IaaS-style VMs hiding behind them, each one back on their patch list.

This walkthrough is also the honest way to price the models against each other: the layers you are responsible for are labor, and labor belongs in the comparison. We put numbers on that in our IaaS vs PaaS vs SaaS cost breakdown.

Where do cloud security failures actually happen?

Overwhelmingly on the customer side of the line. CISA’s cloud security guidance, including its Cloud Security Technical Reference Architecture, keeps returning to the same themes: misconfigured services, weak identity controls, missing MFA, and excessive permissions. These are not hypervisor exploits; they are settings. Because of that, the practical to-do list is short and unglamorous:

• Require MFA on every account, starting with administrators.
• Review who can make storage and databases publicly readable, and alert when someone does.
• Keep an inventory of which services you run under which model, so patch duty is never ambiguous.
• Apply least privilege to both humans and service accounts, and re-review quarterly.
• Write down your side of the model per service — one page per provider is enough.

If your team cannot staff that list, delegating it is a legitimate option; we compare the economics in managed cloud services vs. in-house ops. Delegation changes who does the work, though, not who answers for it.

FAQ

Does the provider’s compliance certification cover my workload?

Only partially. Provider certifications cover their side of the model — facilities, hardware, platform operations. Your configuration, data handling, and access controls are audited separately, and inheriting a compliant foundation does not make an insecure app compliant.

If we use a managed service provider, does responsibility shift to them?

Operationally yes, legally and reputationally no. An MSP can hold patching and monitoring duties under contract, but your organization remains the accountable party for its data. Treat MSP contracts as a second responsibility model to read just as carefully.

Is SaaS the safest model since the vendor handles almost everything?

It removes whole categories of work, but it concentrates what remains: identity, sharing settings, and data governance. A SaaS tenant with weak passwords and public links is insecure no matter how good the vendor’s security team is.

Choosing providers with clear, well-documented responsibility boundaries makes all of this easier — you can compare cloud and security vendors in our directory.