The Cloud Shared Responsibility Model Explained: Who Secures What in IaaS, PaaS and SaaS

A common assumption goes something like this: “Our data is in the cloud now, so the cloud provider handles security.” It is an understandable belief, and it is behind many cloud breaches. Providers do secure a great deal. They do not secure everything, and the part they leave to you is often the part attackers target first: logins, permissions and settings.

That split is called the shared responsibility model. Every major provider, including AWS, Microsoft Azure and Google Cloud, publishes its own version. The details differ, but the logic is the same, and once you understand it you can see exactly where your team needs to focus.

This guide explains the model, shows which tasks belong to whom in IaaS, PaaS and SaaS, and gives you a checklist for your share.

What the shared responsibility model is

The shared responsibility model is a framework that divides security and compliance duties between a cloud provider and its customer.

AWS describes the split as security “of” the cloud versus security “in” the cloud. AWS protects the infrastructure that runs its services: hardware, software, networking and facilities. The customer is responsible for everything it puts into and configures within those services.

Microsoft frames it by layer. In an on-premises data center, you own the whole stack. As you move to cloud services, responsibility for lower layers such as physical hosts, networks and data centers moves to the provider. Microsoft states plainly that for all cloud deployment types, you own your data and identities.

The key variable is the service model you use. If the cloud service models are new to you, our explainer on IaaS vs PaaS vs SaaS covers the basics.

Who is responsible for what

This table follows the responsibility matrix Microsoft publishes for Azure. Other providers use similar divisions, though their wording and exact boundaries vary by service.

Read the table from the top. The first 3 rows never change. No matter what you buy, your data, your settings and your user accounts are yours to protect.

Key takeaway: The cloud provider can secure the building, the servers and the platform perfectly, and you can still be breached through a weak password, an over-permissioned account or a storage bucket left open to the internet. Those are always your responsibility.

IaaS: you manage the most

With infrastructure as a service, you rent virtual machines, storage and networks. The provider secures the physical data center, the hardware and the hypervisor, the virtualization layer that lets many virtual machines share one physical server.

Everything above that is yours. AWS’s own example is Amazon EC2: the customer handles guest operating system updates and security patches, any application software installed on the instance and the configuration of the security group firewall on each instance.

Your IaaS to-do list typically includes: - Patching and hardening the operating system - Installing and updating application software - Configuring firewalls, network segmentation and security groups - Encrypting disks and data, and managing keys - Backups and recovery testing - Identity, access and logging

IaaS gives you the most control, and therefore the most work.

PaaS: the provider takes the operating system

With platform as a service, such as managed databases, app hosting and serverless functions, the provider manages the operating system, runtime and middleware. You deploy code and data without patching servers.

The application layer becomes shared. Microsoft notes that in PaaS, it manages parts of the application stack, but you remain responsible for application configuration, code security and access controls. Network controls are also shared: the provider supplies baseline protection, and you configure application-level controls such as which networks or IP addresses can reach your database.

Your PaaS to-do list typically includes: - Writing secure code and managing dependencies - Configuring access to databases, storage and APIs - Setting network rules, private endpoints and firewall options the service exposes - Managing secrets, keys and encryption settings - Monitoring logs and alerts

SaaS: you still own data, users and settings

With software as a service, such as email, CRM and office suites, the provider runs almost everything. That does not mean you have nothing to do. Many SaaS incidents come from customer-side gaps: no multifactor authentication, shared admin accounts, overly broad sharing links or former employees who still have access.

Your SaaS to-do list typically includes: - Turning on multi-factor authentication and single sign-on - Removing access promptly when people leave - Reviewing sharing settings and admin roles - Configuring retention, audit logging and data loss prevention features - Deciding whether you need separate backups of SaaS data

If your business runs on Microsoft 365, our guide on how to secure Microsoft 365 covers the most important settings.

Tasks that always stay with the customer

Microsoft lists 4 responsibilities customers keep in every deployment type: data, endpoints, accounts and access management. In practice, that means:

Backups deserve special mention. Providers build highly durable infrastructure, but durability is not the same as being able to recover from accidental deletion, a malicious insider or ransomware that encrypts synced files. Check what your provider’s retention actually covers, then fill the gap. Our guide on how to back up business data explains the options.

Shared controls and “shared fate”

Some controls are split, with each side handling its own layer. AWS gives patch management, configuration management and awareness training as examples. AWS patches its infrastructure; you patch your guest systems and applications.

Google Cloud adds a twist it calls “shared fate.” Its architecture guidance argues that the classic model can leave customers to figure out complex configuration on their own, and describes shared fate as Google providing secure defaults, guidance and tested infrastructure templates to help customers secure their part. It complements the shared responsibility model rather than replacing it. Your duties do not disappear; you get more help carrying them out.

Where to start: a 7-step checklist

1. List every cloud service you use. Include SaaS apps, not just your main cloud platform. You cannot secure what you do not know about.
2. Label each one IaaS, PaaS or SaaS. That tells you which rows of the responsibility table apply.
3. Read the provider’s documentation. Each major provider publishes its own shared responsibility page. Note anything that differs from your assumptions.
4. Lock down identity first. Enforce MFA, remove unused accounts, limit admin roles and apply least privilege. This follows the zero trust approach.
5. Review configurations. Check storage access, network exposure, logging and encryption settings. Use your provider’s built-in security posture tools.
6. Confirm backups and recovery. Make sure you can restore critical data within the time your business needs.
7. Assign owners. For each responsibility, name a person or team. Unowned tasks are the ones that fail.

Our cloud security checklist goes deeper on each step, and our SOC 2 compliance guide explains how auditors look at these responsibilities.

Conclusion

The shared responsibility model is simple once you see it as layers. The provider secures the physical infrastructure and, depending on the service, the operating system and platform. You always secure your data, users, access and settings. The more managed the service, the less you patch, but you never hand off responsibility for who can get in and what they can see. Map your services, own your share and verify it regularly.

Sources

• AWS: Shared Responsibility Model — security “of” vs “in” the cloud, EC2 example, inherited and shared controls
• Microsoft Learn: Shared responsibility in the cloud — responsibility matrix for on-premises, IaaS, PaaS and SaaS; responsibilities customers always retain
• Google Cloud Architecture Framework: Shared responsibilities and shared fate — Google’s shared fate approach
• NIST SP 800-145: The NIST Definition of Cloud Computing — definitions of IaaS, PaaS and SaaS service models