The shared responsibility model is the single most important concept in cloud security. It defines the boundary between what your cloud provider secures and what your organisation must secure. Misunderstanding this boundary is not a theoretical risk — it is the root cause of the majority of cloud security incidents. If your team assumes the provider is handling something that actually falls on your side, that gap becomes an open door for attackers.
Every major cloud provider publishes a shared responsibility model, yet surveys consistently show that many organisations cannot accurately describe where provider responsibility ends and customer responsibility begins. This lesson ensures that ambiguity is eliminated.
How Responsibility Is Divided
The shared responsibility model varies by service model, but the core principle is constant: the provider secures the infrastructure of the cloud, while the customer secures what is in the cloud.
- Provider responsibilities (security OF the cloud) — Physical data centres, host operating systems, network infrastructure, hypervisors, and the global backbone connecting regions and availability zones. These are elements the customer never touches and cannot configure.
- Customer responsibilities (security IN the cloud) — Identity and access management, data encryption, network configuration (security groups, NACLs), operating system patches (for IaaS), application-level security, and compliance validation.
- Shared controls — Some areas involve both parties. Patch management is a shared control: the provider patches the underlying platform, but the customer must patch guest operating systems and applications. Similarly, the provider offers encryption tools, but the customer must enable and configure them.
Diagram
The Shared Responsibility Model — Provider vs Customer
Split view showing provider responsibilities on the left (physical security, hypervisor, global network) and customer responsibilities on the right (IAM, data, encryption, app config) with shared controls in the centre.
Where Organisations Get It Wrong
The most dangerous mistakes executives make regarding the shared responsibility model include:
- Assuming data is automatically encrypted. Most providers offer encryption capabilities, but they are often not enabled by default. Your team must configure encryption for data at rest and in transit explicitly.
- Neglecting identity management. The provider gives you an IAM framework, but every user, role, and permission is your responsibility to define and maintain. Overprivileged accounts are your problem, not the provider’s.
- Ignoring logging and monitoring. Providers offer audit logging services (CloudTrail, Azure Monitor, Cloud Audit Logs), but you must enable them, store the logs securely, and actually review them.
- Treating compliance as the provider’s job. A provider may hold ISO 27001 or SOC 2 certification for their infrastructure, but your configuration, access controls, and data handling practices must independently meet compliance requirements.
Action steps for your organisation:
- Obtain and review the shared responsibility documentation from every cloud provider you use
- Create a responsibility matrix (RACI) that maps every security control to either the provider, your team, or both
- Conduct a gap analysis to identify any controls that currently fall between the two parties without clear ownership
- Include shared responsibility education in onboarding for any staff who provision or manage cloud resources
Quick Knowledge Check
- What does the phrase “security OF the cloud versus security IN the cloud” mean?
The provider is responsible for securing the underlying infrastructure (of the cloud), while the customer is responsible for securing their data, identities, configurations, and applications running within that infrastructure (in the cloud). - If a cloud provider holds SOC 2 certification, does that mean your deployment is automatically compliant?
No. The provider’s certification covers their infrastructure controls only. Your configurations, access policies, and data handling must independently satisfy compliance requirements.