Shared Responsibility Model Explained: IaaS, PaaS and SaaS for Security+

Every cloud contract contains a division of labor that most people only discover after something goes wrong. The shared responsibility model — also called the cloud responsibility matrix — is that division written down: which security tasks belong to the cloud service provider, and which remain yours.

The provider secures the cloud. You secure what you put in it. Where the line falls depends entirely on the service model.

It is the single most tested cloud security concept on CompTIA exams, and the reason is practical: the overwhelming majority of cloud breaches are customer-side misconfigurations, not provider failures. Understanding the line is what prevents assuming someone else is handling something nobody is handling.

What Never Changes

Regardless of service model, the provider is always responsible for the physical layer: data centers, physical access control, power, cooling, the host hardware, and the virtualization layer underneath your workloads. You cannot audit their cabling and you are not expected to.

And regardless of service model, you are always responsible for three things:

• Your data. Classification, retention, and whether it should be in the cloud at all.
• Identity and access management. Who has accounts, what permissions they hold, whether MFA is enforced. No provider will do this for you.
• Accountability. You can outsource the work; you cannot outsource the obligation. Regulators and customers hold you responsible for a breach of your data even when a provider's control failed.

How the Line Moves by Service Model

Layer	On-premises	IaaS	PaaS	SaaS
Data and access	You	You	You	You
Application	You	You	You	Provider
Middleware, runtime	You	You	Provider	Provider
Operating system	You	You	Provider	Provider
Virtualization	You	Provider	Provider	Provider
Servers and storage	You	Provider	Provider	Provider
Physical facility	You	Provider	Provider	Provider

Read the table as a sliding line. Moving from on-premises to SaaS, responsibility transfers upward one layer at a time — but the top row never moves. This is the shape exams test: given a service model, which party patches the guest OS? Under IaaS, you do. Under PaaS, the provider does.

The Three Models in Plain Terms

IaaS. You rent virtual machines, storage, and networking. You are responsible for the guest operating system, patching, the applications on it, host firewalls, and your network configuration inside the virtual network. This is the model with the most customer responsibility and, unsurprisingly, the most customer-caused incidents.

PaaS. You deploy code onto a managed platform. The provider handles the OS, runtime, and patching underneath. You are responsible for your application code, its dependencies, its configuration, and access to it. Insecure code is still entirely your problem.

SaaS. You use finished software. The provider runs essentially everything technical. Your responsibility narrows to configuration, user accounts and permissions, data governance, and endpoint security. Narrow does not mean small — the well-known cloud storage exposures were all SaaS or IaaS configuration errors, not provider breaches.

Where Organizations Get Burned

• Assuming backup is included. Many SaaS providers protect against their own infrastructure failure, not against you deleting something or a ransomware event syncing through. Read the agreement.
• Assuming encryption is configured. Encryption at rest is usually available. Available and enabled are different things, and key management is often yours.
• Assuming logging is on. Audit logs frequently default to off or to a short retention window, which is discovered during an investigation rather than before one.
• Ignoring the misconfiguration surface. A storage bucket set to public is a customer action. The provider offered a private default and a warning.
• Forgetting the model changes per service. A single organization typically runs IaaS, PaaS, and SaaS simultaneously, and the line sits in a different place for each.

Security+ (SY0-701) Exam Tips

• Know the responsibility split for IaaS, PaaS, and SaaS cold. Expect a scenario naming a model and asking who handles a specific task.
• Data and identity are always yours. Any answer transferring those to the provider is wrong.
• Accountability cannot be outsourced even when the work is. This wording appears almost verbatim.
• Guest OS patching is the classic discriminator: yours under IaaS, the provider's under PaaS and SaaS.
• Misconfiguration is the dominant cloud risk, and it sits on the customer side of the line.
• Related terms: the responsibility matrix as a contractual document, and its relationship to SLAs, right-to-audit clauses, and vendor assessments.

Cloud+ (CV0-004) Exam Tips

Cloud+ goes further into implementation. Know which controls you configure in each model, how the matrix informs your compliance evidence, and how to establish the split with a provider contractually — including right-to-audit clauses, SLA commitments, and where third-party attestations such as SOC 2 substitute for your own testing. Expect questions about hybrid and multicloud environments where several different matrices apply at once.

Key Takeaways

• The provider secures the cloud; the customer secures what goes in it.
• The line moves by service model — most customer responsibility under IaaS, least under SaaS.
• Data, identity, and accountability are always the customer's, in every model.
• Guest OS patching is the tested discriminator between IaaS and PaaS.
• Most cloud breaches are customer misconfigurations, which is exactly why the model is tested so heavily.
• Verify rather than assume on backup, encryption, and logging — availability is not the same as being switched on.

Related reading: Rapid elasticity · Measured service and metered utilization