The shared responsibility model is the way cloud providers describe the division of security and operational duties between themselves and their customers. In broad terms, the provider is responsible for the security of the cloud, meaning its data centers, hardware, network and the software that runs the service, while the customer remains responsible for security in the cloud, meaning its data, user accounts, access permissions and configuration. Where exactly the line falls depends on the type of service and on each provider’s terms.
At a glance
- Providers secure the infrastructure they run; customers secure what they put in and how they configure it.
- The customer’s share is largest with infrastructure services and smallest with SaaS, where it still covers users, access, settings and data.
- Data, identities, access and configuration typically stay with the customer across service types.
- Built-in retention features in SaaS platforms are not the same as a backup you control.
- Each provider publishes its own version, and the contract decides what is actually committed.
What problem it solves
Moving to the cloud removes a lot of work: no servers to rack, no data center to cool, far less hardware to patch. It is easy to assume it removes security work too. Many cloud incidents come from that assumption, such as storage left open to the internet, administrator accounts without multi-factor authentication, or a company discovering after a ransomware attack or an accidental mass deletion that its SaaS data couldn’t be fully restored.
The shared responsibility model makes the split explicit. It helps a company work out which controls it still needs to provide, which questions to ask a provider, and which gaps need extra tools or services. For IT leaders, it is also a practical way to explain to finance, auditors and insurers why cloud services still need security and backup budgets.
How it works
Provider responsibilities. Across most services, the provider secures the physical facilities, hardware, core network and the virtualization or platform layer, and keeps the service available within the terms of its service level agreement (SLA).
Customer responsibilities. Across most services, the customer manages who has access and how they sign in, the data it stores and how that data is classified and protected, and the configuration choices the service exposes, such as sharing settings, network rules and logging.
How the split shifts by service type:
- Infrastructure services. The customer also manages operating systems, patches, firewall rules, applications and much of the network setup inside the cloud account.
- Platform services. With platform as a service (PaaS), the provider manages operating systems and runtime; the customer manages its code, data and access.
- SaaS. With software as a service (SaaS), the provider runs the application; the customer still owns users, permissions, settings and data.
Filling the customer’s side. Companies typically cover their share with identity and MFA controls, configuration monitoring such as cloud security posture management (CSPM), logging and alerting, and third-party backup for SaaS data. These form a large part of cloud security in practice.
When it matters for buyers
- When moving workloads to cloud computing platforms. Map which controls you used to run on-premises now sit with you, the provider or a managed partner.
- When adopting or renewing Microsoft 365 or Google Workspace. Decide whether built-in retention meets your recovery needs or whether you need separate backup.
- When a cyber insurer or auditor asks about cloud controls. They often want to see that you understand and cover your side.
- When using a managed service provider. A third party adds a layer: document which responsibilities move to them and which remain with you.
- When comparing providers. Responsibility models and the tools provided to meet your share differ.
Our Microsoft 365 backup overview covers one of the most common gaps on the customer’s side.
Questions to ask vendors
- Where is your responsibility model published, and how does it apply to the services we are buying?
- Which security features are included, and which cost extra or require a higher tier?
- How long is deleted or changed data recoverable, and who can restore it?
- What logs do we get access to, and for how long are they kept?
- If a managed provider is involved, which of our responsibilities do you take on, in writing?
- What happens to our data, and how do we get it out, if we leave?
How it differs from an SLA
A service level agreement (SLA) is a contractual commitment about how the service performs, such as uptime targets and the credits you receive if they are missed. The shared responsibility model is about who is responsible for which security and operational duties. A provider can meet its SLA perfectly while your data is exposed by a setting you control, or lost because nobody backed it up. Read both: the SLA tells you what the provider promises to deliver, and the responsibility model tells you what you must do yourself.