Understanding the Shared Responsibility Model in Cloud Security
For senior IT and risk leaders, the Shared Responsibility Model is not an abstract technical concept. It’s a contract that defines where your suppliers risk ends, and yours begins. Misunderstanding it is one of the most common and costly mistakes we see in cloud migrations.
This framework is the dividing line between what your cloud provider secures and what is down to your organisation. Get it wrong, and you can expose client data, breach contracts, and fail audits, even if your provider’s infrastructure is flawless.
What is the Shared Responsibility Model?
Think of it like renting a high-security facility. The landlord is responsible for the building’s structure, surveillance, and controlled entry. You are responsible for what you store inside, how it’s locked, and who has a key.
In cloud terms:
Security of the cloud (provider): The cloud provider — AWS, Azure, or Google Cloud — secures the global infrastructure, data centres, physical hardware, and foundational services.
Security in the cloud (customer): You secure your data, access controls, applications, and any configurations that sit on top of that infrastructure.
If you are unclear on these boundaries, see our guide to common cloud security mistakes. Misunderstanding the shared responsibility model is at the top of the list.
A Deeper Look: The AWS Shared Responsibility Model
Amazon Web Services (AWS) uses a clearly defined Shared Responsibility Model, shown in the diagram above. The split between security of the cloud (AWS’s role) and security in the cloud (your role) is non-negotiable and misunderstanding it is one of the fastest ways to create gaps an attacker can exploit.
AWS’s Responsibilities: Security of the Cloud
AWS is accountable for protecting the infrastructure that runs all of its services. This includes:
Global infrastructure security: Physical facilities, environmental controls, and physical access to data centres.
Hardware and software infrastructure: The compute, storage, database, and networking services.
Core service security: For managed services such as Amazon S3 and Amazon RDS, AWS handles the underlying operating system patching, service configuration, and built-in encryption options.
This layer of security gives a secure foundation, but isn’t the whole picture.
Your Responsibilities: Security in the Cloud
Your responsibilities depend on the services you choose. If you are using a foundational service like Amazon EC2 (virtual servers), you take on more responsibility than if you are using an abstracted service like AWS Lambda.
However, you are always responsible for:
Customer Data: Classifying, encrypting (at rest and in transit), and managing your data. A misconfigured service that exposes your data is your responsibility, not AWS’s.
Identity and Access Management (IAM): Controlling who has access to your cloud resources. This means strong password policies, enforced Multi-Factor Authentication (MFA), and applying the Principle of Least Privilege so users and applications have only the permissions they need. Read more about what least privilege means and how to implement it here.
Platform, Applications, and Operating Systems: For services like EC2, you must patch the guest operating system, install antivirus software, and secure the applications you deploy.
Network and Firewall Configuration: Designing and configuring your Virtual Private Cloud (VPC), subnets, route tables, and firewall rules (Security Groups and Network ACLs) to control traffic to and from your resources.
The takeaway from this model is simple: AWS secures the site and the building, but you are responsible for locking, monitoring, and controlling access to your space inside it.
What About Azure and Google Cloud?
While we've used AWS as our primary example, this model is a universal cloud computing concept. Both Microsoft Azure and Google Cloud Platform (GCP) operate on the same principle, though the specific names of services and documentation may differ. The core division of responsibility remains the same.
Why Getting This Right is Non-Negotiable
Most cloud security breaches are not the result of a sophisticated attack on the cloud provider’s infrastructure. They happen because of customer-side misconfigurations, that is, failing to manage your part of the model.
Common examples include:
Leaving an Amazon S3 bucket publicly accessible
Using overly permissive IAM roles
Failing to patch a vulnerability in an application running on an EC2 instance
Not enforcing 2FA
For commercial organisations in finance, legal, and technology, these mistakes go far beyond technical issues. They can expose regulated client data, trigger contractual penalties, attract regulatory fines, and cause significant reputational damage.
The cloud is not inherently less secure than an on-premise data centre; it simply shifts the focus of your security efforts. You are no longer managing physical servers, but you are now responsible for a complex, software-defined security posture, and that posture has to stand up to scrutiny from regulators, clients, and internal stakeholders.
Find out more about Cloud Security Posture Management.
Getting It Right
The Shared Responsibility Model is not about shifting blame, it’s about clarity. You need to know exactly where your provider’s role ends and yours begins, and ensure those gaps are closed before attackers find them.
At Defended Solutions, we help commercial organisations translate the model into action:
Locking down IAM policies
Hardening configurations
Validating compliance against client and regulatory requirements
Giving boards and stakeholders the reporting they need to demonstrate control
Cloud security is not a checkbox; it’s an ongoing operational commitment. If you want to be confident that your part of the model is under control, we can help. Contact us to discuss how we can help.
FAQ: The Shared Responsibility Model
-
Both the cloud provider and the customer share responsibility. Providers secure the underlying infrastructure, while customers secure their own data, configurations and access controls.
-
Yes. Whether you use AWS, Azure or Google Cloud, the principle is the same though the specific details and service names differ.
-
Conduct regular configuration audits, enforce IAM best practices and use tools such as CSPM to validate compliance.
-
Not inherently. The security outcome depends on how well you manage your responsibilities within the model.
