What Is Shared responsibility model in Cloud Computing?
On This Page
Quick Definition
The shared responsibility model makes it clear who is in charge of different layers of security in the cloud. The cloud provider takes care of the physical security of their data centers and the underlying hardware. The customer is responsible for securing their own data, applications, and user access. Understanding this split helps prevent security gaps and unexpected costs.
Commonly Confused With
The shared responsibility model defines who secures which layer of the cloud. Zero Trust is a security architecture principle that assumes no user or device is trusted by default, even if inside the network. Shared responsibility is about division of labor between provider and customer. Zero Trust is about internal verification of every access request.
Shared responsibility says AWS secures the data center, but you must secure your app. Zero Trust says that even if a user is inside your virtual private cloud, you should still require authentication for every resource access.
Defense in depth is a security strategy that uses multiple layers of security controls to protect assets. Shared responsibility tells you which layers are managed by the provider and which by the customer. Defense in depth tells you how to design those layers, such as using firewalls, encryption, and monitoring together.
Shared responsibility says you are responsible for application layer security. Defense in depth says you should use both a web application firewall and input validation to protect that layer.
The compliance boundary refers to the legal and regulatory scope of responsibility for data protection, often documented in a Business Associate Agreement (BAA) or Data Processing Agreement (DPA). Shared responsibility is the operational model for security tasks. Compliance boundary is about legal ownership of data and audit requirements.
Under shared responsibility, you must encrypt data at rest. Under the compliance boundary, you must sign a BAA with the provider to ensure the provider is contractually obligated to meet HIPAA requirements.
Must Know for Exams
The shared responsibility model is a cornerstone concept for almost every major cloud certification exam, including AWS Certified Solutions Architect (all levels), Microsoft Azure Administrator (AZ-104), Azure Security Engineer (AZ-500), Google Cloud Associate Engineer, and CompTIA Cloud+ (CV0-003). It is also a key topic for the Certified Cloud Security Professional (CCSP) from (ISC)² and the AWS Certified Security Specialty. In these exams, the concept typically appears in two primary question formats: scenario-based questions and comparison questions.
In scenario-based questions, you are given a description of a company's cloud environment and a security event, and you are asked to determine who is at fault or what action is required. For example, an AWS exam question might describe a company that had their S3 bucket data exposed and ask whether this is the customer's responsibility or AWS's. The correct answer is always the customer, because S3 bucket policies and permissions are customer-controlled. A common twist involves the customer using an AWS-managed service like Amazon RDS, where the question might ask who is responsible for patching the database OS. The correct answer is AWS for the underlying OS, but the customer for the database engine minor version if they choose not to enable auto-minor version upgrade.
Comparison questions often ask you to distinguish responsibilities across IaaS, PaaS, and SaaS. For example, an Azure exam might ask: In which service model does the customer have the most security responsibility? The correct answer is IaaS. Conversely, who is responsible for application security in SaaS? The correct answer is the customer, even though the provider manages the application code. These questions test precise understanding of the responsibility boundaries.
For CompTIA Cloud+, you may see a question about shared responsibility in a hybrid cloud scenario, where the on-premises portion is entirely the customer's responsibility, and the cloud portion follows the standard model. Also, expect questions that map specific security controls to the responsible party. For instance, physical data center security is always the provider's responsibility. Identity and access management is always the customer's responsibility.
The best way to prepare is to memorize the responsibility split per service model for each major provider. Use the provider's official shared responsibility matrix documents as study references. Practice with official sample questions from AWS, Azure, and Google Cloud. Pay attention to language like "managed service" which shifts more responsibility to the provider, and "unmanaged service" which leaves more to the customer. In the exam, read each question carefully to identify the exact service model being used, because the answer changes depending on whether it is IaaS, PaaS, or SaaS. Incorrectly assuming the same responsibility split for all services is a common mistake that costs points.
Simple Meaning
Imagine you are renting an apartment in a large building. The building owner is responsible for keeping the lobby clean, fixing the elevator, and making sure the front door lock works. These are things that affect everyone in the building and are beyond your control as a tenant.
Now, inside your own apartment, you are responsible for locking your door, not leaving the stove on, and deciding who gets a spare key. If someone steals your laptop because you left your door open, the building owner is not at fault. The shared responsibility model works exactly the same way in cloud computing.
The cloud provider, like Amazon Web Services (AWS), Microsoft Azure, or Google Cloud, is responsible for the security of the cloud infrastructure itself. This includes the physical data centers, the networking cables, the power supply, and the hypervisors that run virtual machines. They make sure that the building is secure.
The customer, which could be a company or an individual, is responsible for security in the cloud. This means the customer must protect their own data, configure their virtual servers correctly, manage user passwords and permissions, and encrypt sensitive information. If the customer leaves a database open to the internet without a password, that is the customer's fault, not the provider's.
This division is not a suggestion. It is a fundamental rule for using cloud services safely. Many security breaches happen because people misunderstand where their responsibility ends and the provider's responsibility begins.
By understanding this model, you can avoid the common mistake of assuming the cloud provider secures everything. You must always check what you are expected to protect. This model applies to all cloud service models: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS), though the split changes slightly for each.
For example, with SaaS like Gmail, the provider does much more, but you are still responsible for your own password and the data you put into the service.
Full Technical Definition
The shared responsibility model is a foundational security framework in cloud computing that delineates the security obligations of the cloud service provider (CSP) versus those of the customer. This model is not a single static rule but a spectrum that shifts depending on the service model deployed: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or Software as a Service (SaaS). In all cases, the provider always secures the physical infrastructure: data centers, network hardware, storage devices, and the virtualization layer (hypervisor). The customer never has to worry about physical theft, power redundancy, or hardware patching at the provider level.
For IaaS, the provider secures the physical host, the network, and the hypervisor. The customer is responsible for everything above the hypervisor: the guest operating system (OS), applications, data, network access controls (firewalls, security groups), identity management (IAM), and encryption. For example, in Amazon Web Services (AWS) EC2, AWS secures the physical server and the virtualization platform, but the customer must patch the OS of their virtual machine, configure security groups to restrict traffic, and manage encryption keys.
In PaaS, the provider takes on additional responsibility for the runtime environment, middleware, and sometimes the operating system. The customer still manages their application code, data, and access policies. For instance, with Azure SQL Database, Microsoft handles OS patching, database engine updates, and underlying infrastructure security, while the customer is responsible for database user permissions, data encryption at rest and in transit, and preventing SQL injection in their application code.
In SaaS, the provider is responsible for nearly everything: application, runtime, OS, and infrastructure. The customer retains responsibility only for their data, user access, and device-level security. For example, with Google Workspace, Google secures the application and servers, but the customer must enforce strong password policies, enable multi-factor authentication (MFA), and control which employees have access to which documents.
Real IT implementation requires organizations to map out their specific responsibilities per cloud service contract. Many providers like AWS, Azure, and Google Cloud publish detailed responsibility matrices. Compliance standards such as SOC 2, ISO 27001, PCI DSS, and HIPAA often require evidence that both parties are meeting their obligations. Misalignment in responsibility is a common cause of compliance failures. For instance, a company using AWS for credit card processing must ensure that encryption and access controls on their EC2 instances meet PCI DSS requirements, because AWS does not configure these items for the customer.
The model also extends to shared security controls. Some controls, like data classification and inventory management, remain entirely with the customer. Other controls, like physical access logging, are entirely with the provider. A third category called inherited controls involves the customer inheriting some security postures from the provider, such as using the provider’s compliant infrastructure to host regulated workloads. Understanding these nuances is essential for passing cloud architecture and security exams, where scenario-based questions frequently test whether a candidate can correctly assign responsibility for a given security task.
Real-Life Example
Imagine you and your family are going on a long road trip and you decide to rent a car from a rental company. The rental company is responsible for making sure the car is mechanically sound. They check the engine, brakes, tires, oil, and air conditioning before you drive away. They also ensure the car has valid registration and insurance from their end. If the engine fails because of a manufacturing defect, that is their problem, not yours. However, once you drive the car off the lot, you are responsible for how you operate it. You must drive safely, obey traffic laws, fill up the gas tank, and lock the doors when you park. If you crash the car because you were speeding, the rental company is not going to pay for the repairs. If you leave a window open and someone steals your luggage, that is your loss, not the rental company’s.
This rental car example maps directly to the shared responsibility model in cloud computing. The rental company is the cloud provider. They provide the vehicle (the infrastructure) in good working order. They maintain the physical security of the garage where the car is stored (the data center) and ensure the basic systems (the hypervisor, network, and storage) are reliable. You, the customer, are the one who decides how to use the car. You install your own child car seats (your applications), load your own luggage (your data), and decide who gets to drive (user access). If you forget to lock the car (misconfigure a security group) and someone steals your laptop (your data), it is your fault.
This analogy also illustrates how the split changes with different service models. If you rent a car with a driver (like a chauffeured service), that is like SaaS because the provider handles the driving and maintenance, and you just sit in the back with your data. If you rent a bare chassis and build your own car around it, that is like IaaS, where you have almost full control but also full responsibility. No matter the model, the provider never drives for you in a way that makes them responsible for your choices. Understanding this analogy can help IT professionals remember who is accountable for which layer of security when designing cloud solutions.
Why This Term Matters
The shared responsibility model matters because it directly impacts the security posture and compliance standing of any organization using cloud services. A common and expensive mistake is to assume that moving to the cloud automatically transfers all security responsibility to the provider. This assumption leads to misconfigured storage buckets, open databases, weak access policies, and unpatched virtual machines, which are the root causes of the majority of cloud security breaches. According to the Cloud Security Alliance, misconfiguration is the leading cause of cloud data breaches, and almost all of those misconfigurations fall under customer responsibility.
For IT professionals, knowing the boundaries of responsibility is essential for designing secure architectures. When you build a system on AWS, you need to know that Amazon will not automatically back up your EC2 instance data unless you configure it. You must set up backups, encryption, and identity management yourself. Similarly, if you use Azure Active Directory, you must configure conditional access policies and monitor sign-in logs because Microsoft does not decide who should have access to your resources.
Compliance requirements like GDPR, HIPAA, and PCI DSS impose heavy fines for data exposure. Shared responsibility determines who must implement which controls to meet these standards. For example, under HIPAA, a healthcare provider using AWS must sign a Business Associate Agreement (BAA) and then ensure that their own configurations meet HIPAA encryption and access control rules. AWS provides the secure infrastructure, but the customer must use it correctly.
From a financial perspective, misassigning responsibility can result in unexpected costs. For instance, if a developer accidentally leaves a large dataset publicly readable, the data breach can lead to legal liability, loss of customer trust, and remediation costs. Understanding shared responsibility helps organizations allocate budget and personnel to the security tasks they actually own. It also streamlines incident response because teams know immediately whether a security issue lies with the provider or with their own configuration. Finally, this concept is a core competency for cloud architects, security engineers, and DevOps professionals. Without it, even the most expensive cloud infrastructure can be rendered insecure.
How It Appears in Exam Questions
The shared responsibility model appears in certification exam questions in three main patterns: responsibility assignment questions, troubleshooting scenario questions, and service model comparison questions. Responsibility assignment questions directly ask who is accountable for a specific security task. For example, "Who is responsible for patching the operating system of an Amazon EC2 instance?" The correct answer is the customer, because EC2 is an IaaS service. However, if the question asks about patching the hypervisor running the EC2 instance, the answer shifts to AWS. These questions test your ability to distinguish between the host level and the guest level.
Troubleshooting scenario questions present a security incident and ask you to identify the root cause or the required remediation. For instance, a question might describe a company using Azure Virtual Machines that experienced a data breach because a port was left open to the internet. The question may ask, "Who is responsible for this misconfiguration?" The answer is the customer, because network security groups are a customer-managed control in IaaS. Another variant might involve a SaaS application like Office 365 where a user's account is compromised due to weak password. The answer is the customer, because user access management is the customer's responsibility even in SaaS.
Service model comparison questions ask you to compare responsibility across different cloud service models. For example, "In which service model does the provider have the most responsibility for security?" The answer is SaaS. Or, "Which security control is the customer responsible for in all service models?" The answer is data security, including data classification and encryption of data at rest and in transit. These questions often present a table or list of controls and ask you to match each control to the responsible party for a given service model.
Some questions also integrate shared responsibility with compliance frameworks. For instance, a question might say, "A healthcare organization wants to host patient data on AWS and must comply with HIPAA. Which of the following is the organization's responsibility?" The options might include physical data center security, which is incorrect, and encryption of data at rest in S3, which is correct. Another common question type involves shared responsibility in a containerized environment, such as Amazon ECS or Azure Kubernetes Service (AKS). The provider is responsible for the container host and orchestrator control plane, while the customer is responsible for the container images, application configuration, and pod security policies.
To succeed, practice identifying the service model first. If the question mentions "managed" like Amazon RDS or Azure SQL Database, more responsibility rests with the provider. If it mentions "virtual machine" or "instance", assume more customer responsibility. Memorize the classic boundary: provider is responsible for the cloud, customer is responsible for what is in the cloud.
Practise Shared responsibility model Questions
Test your understanding with exam-style practice questions.
Example Scenario
A small company called GreenLeaf Consulting decides to move its customer relationship management (CRM) system to the cloud using AWS. They choose to run the CRM on a single Amazon EC2 instance, which is an IaaS service. The company's IT manager, Sarah, has read about the shared responsibility model but is not entirely sure how it applies.
One day, a customer database is exposed online, and the company suffers a data breach. The CEO asks Sarah who is to blame. Sarah checks the AWS documentation and learns that AWS is responsible for the physical security of the data center and the health of the hypervisor running her EC2 instance. However, Sarah's team was responsible for configuring the security group attached to the instance. They accidentally left port 3306 (MySQL) open to the entire internet.
Because the database was running on the EC2 instance and the security group allowed traffic from anywhere, an attacker scanned the internet, found the open port, and accessed the database. The company had also not enabled encryption at rest for the database data. Under the shared responsibility model, the mistake is entirely the customer's fault. AWS provided a secure and compliant infrastructure, but GreenLeaf failed to configure its own access controls.
Sarah also learns that AWS could have helped prevent the issue. If the company had used Amazon RDS for the database instead of running MySQL on EC2, AWS would have handled many more security patches and configuration settings. But even with RDS, Sarah would still be responsible for database user permissions and data encryption at rest.
After the incident, Sarah implements a new policy. She uses AWS Config to monitor security group changes, enables encryption for all new databases, and requires multi-factor authentication for all cloud console users. She also makes sure all staff complete a shared responsibility training module. This scenario shows that even a simple cloud deployment requires clear understanding of who does what, or the consequences can be severe.
Common Mistakes
Assuming the cloud provider is responsible for all security after migration.
The shared responsibility model explicitly divides security tasks. The provider only secures the infrastructure layer. The customer retains responsibility for data, access, applications, and configuration.
Read the provider's shared responsibility matrix for each service you use. Assume you have responsibility unless the documentation explicitly states the provider handles it.
Thinking that using a managed service like RDS or Azure SQL Database removes all responsibility from the customer.
Even with managed services, the customer is still responsible for data encryption, user access, network security groups, and compliance controls. The provider manages the OS and database engine patching, but not the customer's data policies.
Identify which controls are inherited from the provider and which remain the customer's. For managed services, always configure data encryption, strong authentication, and monitoring.
Confusing provider responsibility for physical security with customer responsibility for logical security.
Physical security of the data center is always the provider's job. But logical security, such as firewall rules, identity policies, and encryption keys, is always the customer's job. Mixing these up can lead to exposed resources.
Create a mental boundary: the provider owns the building and the hardware. The customer owns everything that runs on that hardware, including the operating system, applications, and data.
Believing that the shared responsibility model is the same for all cloud service models (IaaS, PaaS, SaaS).
The split of responsibilities shifts significantly. In IaaS, the customer has the most responsibility. In SaaS, the provider handles most of the stack, but the customer still owns data and access. Using a one-size-fits-all approach leads to security gaps.
Always identify the service model before assessing responsibility. Use a diagram or checklist that maps responsibility per service model from the provider's official documentation.
Neglecting to review the shared responsibility model during incident response planning.
When a security incident occurs, teams often waste time arguing with the provider about who should fix the issue. If responsibilities are not documented, response is delayed, and the breach worsens.
Include shared responsibility in your incident response plan. Predefine which team handles provider-level issues and which team handles customer-level issues. Document this in a responsibility matrix.
Exam Trap — Don't Get Fooled
{"trap":"In an exam question, a managed service like Amazon RDS is described, and the question asks who is responsible for patching the database engine. Learners often think that because the service is \"managed\" by AWS, patching is always AWS’s responsibility, but the correct answer depends on whether the customer enabled auto-minor-version-upgrade.","why_learners_choose_it":"Learners see \"managed\" and assume the provider handles everything.
They do not read that the question specifies the customer chose to disable automatic patching, which makes the customer responsible for manually applying minor version updates.","how_to_avoid_it":"Always read the question carefully for phrases like \"auto-minor-version-upgrade disabled\" or \"manual update policy.\" Remember that even with managed services, the provider only patches by default if the customer opts in.
In the exam, if the question states that the customer made a choice, that choice governs responsibility."
Step-by-Step Breakdown
Identify the cloud service model
Determine whether the service is IaaS, PaaS, or SaaS. This is the first and most critical step because the split of responsibilities changes with each model. For example, Amazon EC2 is IaaS, AWS Elastic Beanstalk is PaaS, and Gmail is SaaS.
List provider responsibilities for that model
For the identified service model, note what the provider always secures: physical data centers, network infrastructure, hypervisor, and (for PaaS and SaaS) additional layers like runtime or application. Refer to the provider’s official shared responsibility matrix.
List customer responsibilities for that model
For the same service model, identify what the customer must secure: data, user access, encryption keys, network controls, operating system (in IaaS), and application code (in IaaS and PaaS). This list may be long, so use checklists from cloud provider documentation.
Map each security control to a party
For every security control relevant to your deployment, assign it to either provider, customer, or shared. For example, physical access logging is provider-only. Identity and access management policies are customer-only. Patching of the virtual machine OS in IaaS is customer-only. This mapping prevents gaps.
Configure and verify customer responsibilities
Once responsibilities are mapped, implement the controls the customer owns. This includes setting up security groups, IAM roles, encryption, backups, and monitoring. Use tools like AWS Config, Azure Policy, or Google Cloud Security Command Center to verify that configurations are correct.
Document and review responsibilities regularly
Create a responsibility matrix document that includes all services used and the assigned parties. Review it quarterly and whenever new services are added. This documentation is essential for audits, compliance, and incident response.
Train the team on shared responsibility
All developers, operators, and security staff must understand the model. Provide training that includes the provider’s official documentation. Without team awareness, misconfigurations will occur, and breaches will follow.
Practical Mini-Lesson
The shared responsibility model is not a theoretical concept, it is a practical tool that cloud professionals use every day. When you are deploying a new workload, your first task is to identify the cloud service model. For example, if you are deploying a web application using Azure App Service (PaaS), you know that Microsoft will handle the operating system, web server, and runtime patching. However, you are still responsible for the application code, the data stored in the application, and the authentication of users.
A common practical scenario is setting up a virtual network in AWS. The Virtual Private Cloud (VPC) is a customer-managed component. AWS provides the ability to create subnets, route tables, internet gateways, and security groups, but the customer must configure them correctly. If you place a database in a public subnet, that is your misconfiguration. AWS will not automatically move it to a private subnet.
What can go wrong? One of the most frequent failures is when a customer assumes that enabling a provider’s managed security feature automatically covers all their needs. For example, AWS Shield Standard is free and provides basic DDoS protection, but it does not protect against application-layer attacks. For that, the customer must configure AWS WAF and associated rules. Another example: Azure Security Center provides recommendations, but the customer must act on them. If you ignore the recommendation to enable encryption, the data remains unencrypted.
Professionals also need to understand the shared responsibility model during incident response. When a breach happens, the provider’s support team will ask you to check your logs and configurations first. They will not accept responsibility for your security group settings. Therefore, you must have logging enabled from the start. Services like AWS CloudTrail, Azure Monitor, and Google Cloud Audit Logs are customer responsibilities to enable.
Another practical consideration is cost. Some customers over-engineer security by duplicating controls that the provider already handles. For instance, you do not need to encrypt traffic within the provider’s internal network if it is already encrypted by default. However, you must encrypt data leaving your control. Understanding where provider controls end and your controls begin helps you avoid waste.
Finally, when using third-party security tools, remember that tool integration with the cloud provider still follows the shared responsibility model. A third-party firewall running in your VPC is completely your responsibility to configure and patch. The provider is not responsible for its security. The bottom line is that cloud security requires constant vigilance. You cannot delegate your portion of the model to anyone else, not even the cloud provider.
Memory Tip
The provider secures the cloud; you secure what is in the cloud. Remember it as: the building is theirs, the apartment is yours.
Covered in These Exams
Current Exam Context
Current exam versions that test this topic — use these objectives when studying.
Related Glossary Terms
AAA (Authentication, Authorization, and Accounting) is a security framework that controls who can access a network, what they are allowed to do, and tracks what they did.
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
An A record is a type of DNS resource record that maps a domain name to an IPv4 address.
Frequently Asked Questions
Who is responsible for patching the operating system of a virtual machine in the cloud?
If you are using Infrastructure as a Service (IaaS) like EC2 or Azure VMs, you are responsible for patching the operating system. If you are using Platform as a Service (PaaS) like AWS Elastic Beanstalk or Azure App Service, the provider manages the OS patches.
Is the cloud provider responsible for data breaches?
Only if the breach is caused by a failure on the provider's side, such as a vulnerability in the hypervisor or physical security lapse. Most breaches are due to customer misconfigurations, for which the provider is not responsible.
Does the shared responsibility model apply to on-premises data centers?
No, the shared responsibility model only applies to cloud environments. In an on-premises data center, the organization is responsible for everything, from physical security to application configuration.
How does the shared responsibility model work with third-party services that run on top of the cloud?
Third-party services are treated as additional layers that the customer is responsible for. For example, if you install a third-party firewall on an Azure VM, you are responsible for configuring and patching that firewall.
What is the best way to verify that my responsibilities are being met?
Use cloud provider tools like AWS Config, Azure Policy, and Google Cloud Security Command Center to continuously monitor compliance with your responsibility controls. Regular audits and penetration testing also help.
Can the shared responsibility model change over time?
The fundamental model is stable, but cloud providers occasionally update their service terms or introduce new services that shift responsibilities. Always review the latest shared responsibility documentation from your provider for each service you use.
Is encryption always the customer's responsibility?
Not always. Some managed services, like Amazon DynamoDB or Azure SQL Database, offer encryption at rest by default, which is managed by the provider. However, the customer is responsible for managing their own encryption keys and ensuring encryption is used correctly.
Summary
The shared responsibility model is the essential framework for understanding security in the cloud. It clearly divides the security obligations between the cloud provider and the customer, ensuring that no layer of protection is neglected. The provider is always responsible for the physical infrastructure and the virtualization layer, while the customer is responsible for data, access, application security, and configuration. This division shifts depending on whether the service is IaaS, PaaS, or SaaS, but the principle remains the same: the provider secures the cloud, and the customer secures what is in the cloud.
For IT certification candidates, mastering this model is not optional. It appears in scenarios, comparison questions, and troubleshooting questions across the major cloud exams from AWS, Azure, Google Cloud, CompTIA, and (ISC)². Misunderstanding this model is one of the most common reasons for incorrect answers and also one of the most common causes of real-world security incidents.
The key exam takeaway is to always identify the service model first, then consult the provider's responsibility matrix. Use memory aids like "building vs. apartment" to recall the split. Practice with official sample questions to reinforce your understanding. In the real world, this model governs how organizations secure their cloud environments, allocate security budgets, and respond to incidents. By internalizing the shared responsibility model, you will be better prepared for both exams and a career in cloud IT.