Key Points
- Provider Handles Infrastructure, Customer Secures the Data: Workloads, data, access controls, and compliance are within the customer’s scope of responsibilities, regardless of which provider or service model is used.
- SaaS is Commonly Misunderstood: Providers do not handle backup or recovery, but are in charge of availability. If data is deleted or corrupted, recoverability depends on what the customer has in place.
- Accountability for Data and Access Isn’t the Provider’s Responsibility: Even when a provider handles more of the stack, identity governance, retention policies, and compliance workflows will remain the customer’s responsibility.
- Multi-cloud Environments Break Governance When Policies are Managed per Platform: Security policies, IAM models, and logging formats vary across providers.
- Gaps Can Accumulate Without a Unified View: Without centralized visibility, gaps and configuration drift could build up over time across environments.
Today, most enterprise organizations move workloads to the cloud or digital workplaces handled by a service provider. However, this comes with a common misconception that the provider handles most of the security. This is where cloud security issues begin, and this could hamper the work they’re doing.
This guide covers how the shared responsibility model works. It will explain where the provider and customers’ respective accountabilities and responsibilities diverge, along with what organizations have to do to keep their own cloud security intact.
Why does the shared responsibility model exist?
The shared responsibility model works by dividing the responsibility between the customer and the service provider. The provider secures the infrastructure on which the cloud service runs, while the customer secures everything they put into it.
Providers are responsible for:
- Physical infrastructure and data centers: The hardware, facilities, and physical access controls that could underpin cloud services.
- Network foundations and hypervisors: The core network layer and virtualization stack that customers build on top of.
- Platform availability: Keeping cloud services up and running at the infrastructure level.
Customers will remain responsible for:
- User access and identity: This refers to who can access cloud resources and under what conditions.
- Workload configuration: Covers how virtual machines, containers, and services are set up and hardened.
- Data protection and recovery governance: Pertains to what gets backed up, how long it is retained, and how it is restored.
- Security policies and compliance alignment: Ensures configurations and controls meet internal and regulatory requirements.
Note that the responsibility for securing workloads, data, and who has access stays with the customer, regardless of which provider is used.
Customer responsibilities in cloud security
Under the shared responsibility model, the provider secures the infrastructure. Everything that is built and run on top of it is the customer’s responsibility.
| Responsibilities | Details |
| Identity and access governance | Controlling who has access to cloud resources and enforcing least-privilege across accounts and roles. |
| Multi-factor authentication (MFA) and privileged access control | Ensuring that elevated access will require strong verification and is granted only where needed. |
| Workload configuration and operating system hardening | Setting up and maintaining secure configurations for virtual machines, containers, and hosted services. |
| Data retention and backup | Defining what gets backed up, how long the data is kept, and how recovery works when needed. |
| Compliance reporting and security monitoring | Maintaining audit trails, generating required reports, and keeping visibility into what is happening across cloud environments. |
Cloud providers do not automatically secure customer workloads or enforce governance workflows because that work is the customer’s responsibility.
Understanding shared responsibility models across cloud services
There are three different shared responsibility models: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS).
Responsibilities shift depending on which cloud service model is in use. The more the provider manages, the less infrastructure the customer controls. However, core accountability for data, access, and governance stays with the customer.
| Responsibility | IaaS | PaaS | SaaS |
| Physical infrastructure | Provider | Provider | Provider |
| Networking and virtualization layer | Provider | Provider | Provider |
| Operating system | Customer | Provider | Provider |
| Runtime and middleware | Customer | Provider | Provider |
| Applications | Customer | Customer | Provider |
| Storage management | Customer | Customer | Customer |
| Identity and access management | Customer | Customer | Customer |
| Compliance and governance | Customer | Customer | Customer |
Infrastructure as a Service (IaaS)
IaaS providers give organizations the most control over their cloud environment, along with the responsibility to go with it. Here, customers manage:
- Operating systems and patching: The provider supplies the infrastructure, but the customer is responsible for installing, configuring, and maintaining the OS.
- Applications and workload configuration: How applications are built, deployed, and secured is entirely the customer’s domain.
- Data protection: Backup, encryption, and recovery planning are the customer’s responsibility from the get-go.
Of the three service models, IaaS places the heaviest operational load on the customer.
Platform as a Service (PaaS)
PaaS removes infrastructure and OS management from the customers’ list of responsibilities. However, the customers will still handle:
- Applications: The customer builds and deploys applications on the platform and is responsible for securing them
- Data: Organizations will be responsible for the data stored, how it is protected, and how long it is retained.
- Access control and workload configuration: This covers managing permissions regarding who can access the platform and how workloads are configured.
Handing off infrastructure management will not hand off accountability for what the customer builds and runs on the platform.
Software as a Service (SaaS)
SaaS hands off application management and infrastructure to the provider. This is why it produces a lot of confusion about what the customer handles.
- Identity governance and access management
- Retention policies and backup governance
- Compliance workflows
A common example is assuming that SaaS providers like Microsoft 365 or Google Workspace automatically back up email and file data. Both platforms provide availability, but not backup. If data is deleted or corrupted, recovery depends on whether the customer has another backup policy in place.
Why can multi-cloud governance become difficult?
The shared responsibility model applies across all major cloud providers, but how it is implemented is vastly different. For example, AWS, Azure, and Google Cloud each have their own identity and access management (IAM) model, logging tools, backup solutions, and native security controls.
If you run workloads across more than one provider, you will have to manage those differences on a consistent basis, which is where governance starts to break down.
| Challenges | What it means |
| Fragmented logging | Each provider generates logs in different formats and locations, making unified visibility difficult without a central aggregation tool. |
| Inconsistent policies | Security policies configured on one platform will not carry over to another. This creates gaps and configuration drift when the same standard needs to apply across providers. |
| Identity sprawl | Managing separate IAM models across AWS, Azure, and Google Cloud increases the risk of orphaned or abandoned accounts, as well as excessive permissions and inconsistent access controls. |
| Governance blind spots | Without centralized visibility via a remote monitoring management (RMM) software, unmanaged resources and misconfigurations on one platform can go undetected while other environments appear compliant. |
Centralizing visibility and accountability across providers separates organizations that manage multi-cloud environments well from those that just use them.
Common shared responsibility gaps
Most cloud security incidents trace back to the same misunderstandings about what the shared responsibility for cloud security actually covers. Here are some of the gaps that show up a lot:
| Gap | What goes wrong |
| Assuming providers handle backup and recovery | Providers protect infrastructure availability, not customer data. Without a separate backup policy, deleted or corrupted data may be unrecoverable. |
| Treating SaaS availability as recoverability | A SaaS platform staying online does not mean that the data inside it is backed up. Retention and recovery will remain the customer’s responsibility. |
| Overlooking identity governance | Weak access controls, excessive permissions, and unreviewed accounts are among the most common causes of cloud security incidents. |
| Fragmented governance across cloud platforms | Policies that apply on one platform will not automatically carry over to others. This could leave gaps that are easy to miss until an incident or audit brings them to light. |
| Unclear operational ownership | When no one has explicitly defined who is responsible for a workload or governance workflow, the tasks under this responsibility will usually be unfulfilled. |
Operationalizing cloud accountability
Applying cloud security best practices in a shared responsibility environment means defining ownership before problems surface, not after.
Operationally mature organizations prioritize:
- Centralized governance: Managing security policies, access controls, and compliance requirements from a single framework rather than configuring each cloud platform independently.
- Identity security: Enforcing least-privilege access, reviewing permissions regularly, and ensuring MFA is applied consistently across all cloud accounts and roles.
- Workload accountability: Assigning clear ownership for every workload so configuration, patching, and security reviews have a named responsible party.
- Continuous visibility: Monitoring cloud environments in real time so misconfigurations and anomalies are caught early instead of being discovered during incidents or audits.
- Recovery readiness: Defining and testing recovery procedures for each workload and dataset. A backup that has never been tested cannot be relied on when data actually needs to be restored.
Organizations should also clearly define:
- Provider obligations: What the cloud provider is responsible for under the service agreement.
- Customer obligations: What the organization owns in terms of configuration, access, and data protection.
- Security ownership boundaries: Where provider responsibility ends, and customer responsibility begins for each service in use.
- Cross-functional governance responsibilities: Which teams own which parts of cloud governance, including aspects like security, operations, and compliance.
Operational certainty across these areas keeps accountability from falling through the gaps as cloud environments grow.
Understanding the shared responsibility and how it affects cloud security
The shared responsibility model defines who owns what in a cloud environment, and that boundary does not shift based on how much the provider manages. Organizations remain accountable for workloads, identities, data, and compliance regardless of which service model or provider they use.
Getting those boundaries wrong is what creates most cloud security gaps. Organizations that define ownership clearly and treat it as an ongoing operational responsibility are better placed to manage cloud risk as their environments grow.
Related topics:
