The Shared Responsibility Model in Cloud Computing: A Comprehensive Analysis of Security, Data Protection, and Compliance Paradigms

Abstract

Cloud computing has fundamentally reshaped the landscape of information technology, offering unprecedented scalability, flexibility, and cost efficiency. Central to understanding security in this transformative paradigm is the Shared Responsibility Model (SRM). This report delves into the SRM, explicating its core tenets, historical evolution, and granular distinctions across various cloud service models (IaaS, PaaS, SaaS). A critical objective is to address the pervasive misconception that cloud providers assume full responsibility for comprehensive data backup and long-term retention, clarifying the distinct roles and duties of cloud providers and customers regarding data protection, security, and compliance. Furthermore, the report explores the intricate challenges inherent in implementing the SRM, including complexity and visibility gaps, and proposes best practices for customers to mitigate risks. Finally, it considers the ongoing evolution of the model, particularly concepts like ‘Shared Fate,’ and offers a forward-looking perspective on cloud security governance for an expert audience.

Many thanks to our sponsor Esdebe who helped us prepare this research report.

1. Introduction: Deconstructing the Cloud Security Paradigm

The advent of cloud computing, marked by its on-demand availability of computing resources over the internet, has instigated a profound shift in how organizations conceptualize and manage their IT infrastructure. From small startups to multinational enterprises, the allure of reduced operational overhead, enhanced agility, and global reach has propelled widespread cloud adoption. However, alongside its myriad benefits, cloud migration introduces a novel set of security considerations that necessitate a departure from traditional on-premises security frameworks. A cornerstone concept in navigating these complexities is the Shared Responsibility Model (SRM), a fundamental framework that delineates the security obligations between Cloud Service Providers (CSPs) and their customers [9, 17, 19].

Despite the clear articulation of the SRM by major CSPs, a persistent and often critical misconception prevails among many cloud adopters: the erroneous belief that migrating to the cloud inherently transfers all security and data protection responsibilities, including comprehensive data backup and long-term retention, entirely to the cloud provider [13, 15, 23]. This misunderstanding can lead to significant security gaps, data loss, and compliance failures, underscoring the imperative for a deeper, more nuanced understanding of the model. This research report aims to provide a comprehensive analysis of the Shared Responsibility Model, clarifying the demarcation of duties, exploring its variations across different service models, examining key areas of shared responsibility, and addressing common misconceptions, particularly concerning data resilience. It seeks to equip experts in the field with a detailed understanding necessary for robust cloud security posture management and effective risk mitigation.

Many thanks to our sponsor Esdebe who helped us prepare this research report.

2. Historical Context and Evolution of the Shared Responsibility Model

The Shared Responsibility Model did not emerge as a singular, pre-defined doctrine but rather evolved organically out of necessity as cloud computing matured. In the early days of cloud adoption, the novelty of outsourcing infrastructure and services led to ambiguity regarding accountability for security incidents. Enterprises, accustomed to complete control over their on-premises environments, often struggled to grasp the distributed nature of cloud security. Incidents stemming from customer misconfigurations or inadequate data protection practices highlighted the need for a clear division of labor [29, 3].

Major CSPs, such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP), formally introduced and popularized the SRM to bring clarity to this complex domain [4, 7, 34, 38]. This model serves to prevent security gaps by ensuring accountability across both the cloud provider’s infrastructure and the customer’s deployed workloads [14]. Initially, the emphasis was on defining the boundary between the physical infrastructure (managed by the CSP) and the applications/data (managed by the customer). As cloud services diversified and became more abstract, the model itself had to adapt.

The evolution of cloud computing, marked by the proliferation of containers, Kubernetes, edge computing, and serverless architectures, has continuously influenced the SRM [11]. What began as a relatively simple division has grown into a sophisticated framework that differentiates responsibilities based on the chosen service model and even the specific features utilized within a service. More recently, some providers, notably Google Cloud, have introduced the concept of ‘Shared Fate,’ which suggests an even deeper partnership where the CSP not only secures its part but also actively aids customers in securing their portion, often through advanced tooling and best practice guidance [5, 21, 31, 41]. This ‘third wave’ of the SRM acknowledges the inherent complexity customers face and the mutual interest in better security outcomes, signifying a maturing relationship between providers and consumers.

Many thanks to our sponsor Esdebe who helped us prepare this research report.

3. Core Tenets: “Security of the Cloud” vs. “Security in the Cloud”

At the heart of the Shared Responsibility Model lies a fundamental bifurcation of security duties, often articulated as “Security of the Cloud” and “Security in the Cloud” [4, 9, 16, 19, 28]. This distinction is critical for understanding the precise boundaries of accountability and forms the bedrock upon which all subsequent responsibilities are layered.

3.1. “Security of the Cloud”: The Cloud Provider’s Domain

The “Security of the Cloud” refers to the responsibilities that fall squarely on the shoulders of the Cloud Service Provider. This encompasses the foundational infrastructure that underpins all cloud services [4, 9, 17, 19, 31]. CSPs are responsible for protecting the hardware, software, networking, and facilities that run their cloud services [4, 7, 33]. This includes, but is not limited to:

• Physical Security: Safeguarding data centers through stringent access controls, surveillance, environmental controls (power, cooling), and protection against natural disasters [4, 10, 19, 34, 43]. This is an area where CSPs typically invest heavily, often exceeding the capabilities of individual enterprises [23, 24].
• Network Infrastructure Security: Protecting the core network infrastructure, including routers, switches, and the underlying network fabric, from external threats like Distributed Denial of Service (DDoS) attacks and ensuring secure data transfer within their data centers [19, 34].
• Virtualization Layer: Securing the hypervisor, which allows multiple virtual machines to run on a single physical server, ensuring isolation and integrity between customer environments [4, 7, 33].
• Global Infrastructure: Managing and maintaining the availability, durability, and reliability of the overall cloud platform, including global regions and availability zones [12].

In essence, the CSP is responsible for the operational aspects of the cloud services themselves and the underlying infrastructure that supports them [7, 36]. This managed responsibility helps alleviate a significant operational burden from the customer, allowing them to focus on higher-level business objectives [7].

3.2. “Security in the Cloud”: The Customer’s Imperative

Conversely, “Security in the Cloud” represents the customer’s obligations, focusing on the security of everything they create, configure, and deploy within the cloud environment [4, 9, 16, 17, 28, 31]. This is where the misconception often arises, as customers sometimes assume the provider’s robust infrastructure security extends to their specific workloads without active configuration. Key customer responsibilities include:

• Data Security and Management: Protecting their data, including classifying sensitive information, implementing encryption (at rest and in transit), ensuring proper storage, and managing secure deletion practices [10, 28, 34, 42]. This explicitly covers data backup and long-term retention, a point of frequent misunderstanding.
• Identity and Access Management (IAM): Configuring and managing user identities, roles, permissions, and access controls to cloud resources. This includes enforcing strong authentication mechanisms like multi-factor authentication (MFA) and adhering to the principle of least privilege [10, 17, 28, 34]. Misconfigurations in IAM are a leading cause of cloud security breaches [5, 16].
• Network Configuration: Setting up network security controls such as virtual private clouds (VPCs), security groups, network access control lists (NACLs), and firewall rules to control traffic to and from their resources [7, 28].
• Operating System, Application, and Middleware Security: For services where the customer controls the operating system (e.g., in IaaS), they are responsible for patching, updates, security configurations, and monitoring for vulnerabilities [7, 10, 28, 34]. This also extends to securing any applications or middleware deployed on top of the cloud infrastructure [17].
• Client-Side Data Encryption and Integrity: Ensuring the security of data before it is uploaded to the cloud and after it is retrieved.

In summary, while the CSP provides a secure foundation, the customer is ultimately responsible for how they use that foundation, the data they place upon it, and the configurations they apply [6, 10]. Neglecting this ‘in the cloud’ responsibility is a primary source of security vulnerabilities and breaches [16, 41].

Many thanks to our sponsor Esdebe who helped us prepare this research report.

4. Variations Across Cloud Service Models

The precise demarcation of responsibilities within the SRM is not static; it dynamically shifts depending on the cloud service model adopted. Understanding these variations is paramount for organizations to accurately assess their security posture and allocate resources effectively. The three primary service models – Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS) – represent a progressive transfer of responsibility from the customer to the provider [1, 22, 43].

4.1. Infrastructure as a Service (IaaS)

In the IaaS model, the CSP provides the fundamental computing infrastructure, including virtualized servers, storage, and networking components [1, 44]. The customer, however, retains significant control and, consequently, significant responsibility. In this model, the CSP is responsible for the “security of the cloud” – the physical data centers, networking hardware, and the virtualization layer [1, 6, 7, 33]. The customer’s responsibilities, constituting the “security in the cloud,” are extensive and include [22, 28, 43]:

• Guest Operating System: Installation, configuration, patching, and security hardening of the operating system (OS) running on virtual machines.
• Applications and Middleware: Deployment, patching, and security of all applications and middleware installed on the OS.
• Network Configuration: Setting up virtual networks, subnets, firewalls (security groups, Network Access Control Lists – NACLs), and routing tables.
• Data: All data stored and processed within the IaaS environment, including encryption and backup strategies.
• Identity and Access Management: Managing user access, permissions, and authentication mechanisms for the virtualized environment.

This model offers the highest degree of flexibility to the customer but demands the most proactive security management from their side. Misconfigurations in any of these customer-managed layers can directly lead to security incidents [6].

4.2. Platform as a Service (PaaS)

PaaS offerings provide a managed environment for developing, running, and managing applications, abstracting away much of the underlying infrastructure complexity [1, 44]. Here, the CSP takes on a greater share of responsibility compared to IaaS. The provider is responsible for the underlying infrastructure, operating systems, and often middleware, databases, and development tools [1, 22, 31, 43]. The customer’s focus shifts primarily to their applications and data. Customer responsibilities typically include [22, 43]:

• Application Code: Securing the application code they develop and deploy on the platform.
• Application Configurations: Configuring security settings within their application.
• Data: Management, encryption, and protection of the data stored within the PaaS application.
• Identity and Access Management: Managing user access to the deployed applications and data.

While PaaS reduces the burden of OS patching and infrastructure management, customers must still be diligent in securing their application logic, data, and access controls. A vulnerability in the application code or an overly permissive data access policy remains the customer’s responsibility [1, 6].

4.3. Software as a Service (SaaS)

SaaS represents the highest level of abstraction, where the CSP manages the entire application stack, from infrastructure to the application itself [1, 44]. Customers consume the software as a service over the internet, with minimal control over the underlying components. Consequently, the CSP assumes the vast majority of security responsibilities [1, 22, 43]. However, crucial customer responsibilities persist and are often overlooked [6, 22]:

• User Access and Permissions: Managing user accounts, passwords, multi-factor authentication, and ensuring appropriate access levels within the SaaS application [6, 10, 22, 43].
• Data Input: Responsibility for the security and integrity of the data that they input into the SaaS application [6, 10, 43]. This includes ensuring data classification, appropriate sharing settings, and protecting sensitive information.
• Endpoint Security: Securing the devices used by end-users to access the SaaS application.
• Compliance for Data Usage: Ensuring their usage of the SaaS application and the data within it complies with relevant regulations and organizational policies [6].

Even in a SaaS model, a data breach can still occur due to customer negligence, such as weak user credentials or improper sharing settings, demonstrating that complete security outsourcing is a myth [13, 22].

Many thanks to our sponsor Esdebe who helped us prepare this research report.

5. Key Areas of Shared Responsibility and Customer Imperatives

The Shared Responsibility Model extends across various critical security domains, each demanding a clear understanding of the customer’s active role. Beyond the infrastructure distinctions of IaaS, PaaS, and SaaS, several specific areas require meticulous attention from the cloud consumer.

5.1. Data Protection and Privacy: Debunking the Backup Myth

One of the most persistent and dangerous misconceptions in cloud adoption is the belief that CSPs automatically provide comprehensive data backup and long-term retention for customer data [13, 15, 23]. While CSPs offer robust infrastructure resilience and data durability, these are distinct from customer-specific data backup and recovery. For instance, AWS is responsible for the durability of data stored in services like S3, meaning the data is replicated across multiple availability zones to prevent loss due to infrastructure failure [7]. Azure also offers resilience-enhancing capabilities like availability zones and backup strategies, but customers are responsible for configuring and utilizing them [12]. However, this durability does not equate to user-initiated backups that protect against accidental deletion, malicious activity (e.g., ransomware), or application-level corruption [13, 15, 23, 24].

CSPs’ service agreements typically limit their liability for data loss originating from customer actions or misconfigurations [15]. Customers are explicitly responsible for:
* Data Backup and Recovery: Implementing their own backup and recovery strategies, often leveraging provider-specific backup services (e.g., AWS Backup, Azure Backup) or third-party solutions, to ensure data can be restored from various points in time [10, 36, 39]. This includes defining recovery point objectives (RPOs) and recovery time objectives (RTOs).
* Data Encryption: Encrypting sensitive data both at rest and in transit, and managing encryption keys [7, 10, 28, 34, 42]. While CSPs often provide encryption capabilities, the customer is responsible for their proper implementation and key management [6].
* Data Classification and Retention: Classifying data based on its sensitivity and regulatory requirements, and defining appropriate retention policies [7, 10].
* Data Sovereignty: Understanding and meeting regulatory requirements regarding where data is stored and processed, especially for international operations (e.g., GDPR) [3, 6].

Failure to implement a robust customer-managed backup strategy can lead to irrecoverable data loss, severe operational disruption, and significant financial and reputational damage, regardless of the CSP’s underlying infrastructure resilience [13, 15].

5.2. Identity and Access Management (IAM)

IAM is a critical shared control. While CSPs provide the IAM framework and services (e.g., AWS IAM, Azure AD, Google Cloud IAM), customers are solely responsible for configuring and managing identities, users, groups, roles, and policies within their cloud environment [10, 17, 28, 34]. This includes:

• Least Privilege: Implementing the principle of least privilege, ensuring users and services only have the minimum permissions necessary to perform their tasks.
• Strong Authentication: Enforcing strong passwords, multi-factor authentication (MFA), and regularly rotating access keys [6, 22, 34].
• Access Reviews: Regularly auditing and reviewing access policies to revoke unnecessary permissions [22].
• Privileged Access Management (PAM): Securing and monitoring privileged accounts.

Misconfigured IAM policies are consistently cited as a leading cause of cloud breaches, underscoring the customer’s direct accountability in this domain [5, 16].

5.3. Network Security

CSPs are responsible for the security of their global network infrastructure. However, customers are responsible for configuring network controls within their cloud environments [7, 17, 28]. This includes:

• Virtual Network Segmentation: Designing and implementing virtual networks (VPCs, VNETs) and subnets to isolate resources.
• Firewall Rules: Configuring security groups, Network Security Groups (NSGs), and network access control lists (NACLs) to control inbound and outbound traffic to virtual machines and other resources [7, 28].
• VPNs and Direct Connect: Securing connectivity between on-premises environments and the cloud.
• DDoS Protection: While CSPs offer foundational DDoS protection, customers may need to configure higher-level protections for their applications.

An open port or a misconfigured firewall rule, despite the provider’s secure network infrastructure, is a customer’s responsibility and a common attack vector [6].

5.4. Compliance and Governance

Compliance in the cloud is a quintessential shared responsibility [3, 19, 26]. CSPs ensure that their underlying infrastructure and services comply with a wide array of global, industry-specific, and regional regulations (e.g., GDPR, HIPAA, PCI DSS, SOC 2) [3, 6, 26, 30]. They provide certifications and audit reports to demonstrate their adherence to these standards. However, this does not automatically make the customer’s use of the cloud compliant. Customers must ensure that their usage of the cloud services, their applications, data, and configurations, also comply with these regulations [6, 19, 26].

Customer compliance responsibilities include:

• Data Handling: Ensuring data processing, storage, and access align with privacy regulations like GDPR or CCPA.
• Audit Trails and Logging: Configuring and retaining audit logs and monitoring data access to demonstrate compliance [6, 34].
• Security Controls Implementation: Implementing and documenting the necessary security controls (e.g., encryption, access controls) on their side to meet specific regulatory requirements [6, 19, 30].
• Contractual Review: Thoroughly understanding the provider’s contractual obligations and security offerings to ensure they meet their own regulatory needs [8].

Ultimately, while the CSP provides a compliant platform, the customer is responsible for operating within that platform in a compliant manner [26, 30].

5.5. Incident Response

Incident response (IR) in the cloud presents unique challenges compared to traditional on-premises environments, largely due to the shared responsibility model [2, 18, 20]. Effective cloud IR requires close collaboration between the customer and the CSP, with clearly defined roles and procedures [5, 18].

CSPs are responsible for responding to incidents related to the “security of the cloud,” such as infrastructure outages or breaches of the hypervisor. They typically have sophisticated IR teams and protocols in place [12]. However, customers are responsible for responding to incidents affecting the “security in the cloud,” which includes their data, applications, and configurations [2, 17, 20]. Customer responsibilities include:

• Detection and Analysis: Implementing monitoring and logging solutions (e.g., using cloud-native tools like AWS CloudTrail, Azure Monitor, or GCP Cloud Logging) to detect suspicious activities within their cloud resources [2, 34].
• Containment and Eradication: Taking steps to contain and eradicate threats within their environment, such as isolating compromised instances or revoking compromised credentials.
• Recovery: Restoring services and data from backups, as per their disaster recovery plans.
• Communication and Reporting: Notifying affected parties and, where required, regulatory bodies.
• Forensics: Collaborating with the CSP to gather necessary logs and data for forensic analysis [5].

Organizations must integrate cloud-specific IR procedures into their overall incident response plan, ensuring their teams have the necessary skills and tools to respond effectively in a distributed cloud environment [2, 18, 20]. Without a clear understanding of roles, incident response can be significantly hampered, leading to prolonged downtime and increased damage [5, 18].

Many thanks to our sponsor Esdebe who helped us prepare this research report.

6. Challenges and Nuances in Shared Responsibility Implementation

While the Shared Responsibility Model provides a conceptual framework, its practical implementation is fraught with challenges and nuances that demand continuous attention from cloud adopters. The complexity of modern cloud environments often complicates a clear-cut division of duties [3].

6.1. Complexity and Granularity

Cloud environments are dynamic, with CSPs constantly introducing new services and features. Each service, whether IaaS, PaaS, or a highly abstracted serverless function, has its own specific responsibility boundaries, which can be difficult to discern and track [5, 6]. For an organization utilizing a diverse portfolio of services across a multi-cloud or hybrid-cloud architecture, managing these granular distinctions becomes exceptionally challenging [3, 6]. The fine line of responsibility is always case-specific [32]. This complexity can lead to oversight and inadvertent security gaps, especially when teams lack deep expertise in every cloud service they consume [14]. Google Cloud, for instance, explicitly acknowledges that understanding shared responsibility can be challenging, requiring an in-depth understanding of each service’s configuration options and what the CSP does to secure it [5, 35].

6.2. Visibility Gaps

Customers often lack full visibility into the cloud provider’s underlying infrastructure and the security controls implemented by the CSP [3, 6]. While providers offer robust monitoring and logging tools for customer-managed components, the ‘black box’ nature of certain provider-managed layers can create blind spots for customers attempting to achieve a holistic security posture. This limited visibility can hinder comprehensive risk assessments and complicate incident investigations, especially when an issue crosses the provider-customer boundary [5, 18, 20]. Customers must rely on CSP-provided certifications and audit reports to ascertain the security of the cloud itself [8].

6.3. The Human Factor and Misconfigurations

A significant proportion of cloud security breaches are attributed to human error and misconfigurations on the customer’s side, rather than vulnerabilities in the CSP’s infrastructure [5, 16, 23]. This highlights a critical, opinionated stance: the SRM effectively shifts a substantial portion of the security burden, and thus the risk, to the customer. While CSPs provide secure defaults and best practices, the onus is on the customer to correctly implement and maintain these configurations for their specific workloads [6, 16, 29]. This includes everything from improperly secured storage buckets (e.g., publicly accessible S3 buckets) to overly permissive IAM policies and unpatched guest operating systems [6, 7, 16, 23]. The ‘capability vs. responsibility gap,’ where customers may lack the skills or resources to fulfill their security responsibilities, is a notable pitfall [14].

6.4. Evolving Landscape and “Shared Fate”

The rapid evolution of cloud services means the lines of responsibility are not static; new services can blur or redraw existing boundaries [5]. This constant flux necessitates continuous learning and adaptation from customers. Recognising these challenges, some CSPs are evolving the SRM. Google Cloud’s concept of “Shared Fate” or “Shared Destiny” is a notable example [5, 21, 31, 41]. This approach suggests that while the responsibility division remains, the CSP will more actively partner with customers to achieve better security outcomes, offering more embedded security controls, best practice guidance, and even innovative insurance options [5, 21]. This philosophical shift acknowledges that the provider’s ultimate success is intertwined with the customer’s security success, hinting at a potential future where CSPs offer more active ‘security assistance’ rather than merely defining boundaries.

Many thanks to our sponsor Esdebe who helped us prepare this research report.

7. Best Practices for Customers in the Shared Responsibility Model

For organizations to effectively navigate the Shared Responsibility Model and leverage cloud benefits securely, proactive engagement and adherence to best practices are indispensable. It is not enough to simply understand the model; it must be actively integrated into an organization’s cloud strategy and daily operations.

7.1. Thorough Understanding and Documentation

The foundational best practice is for organizations to thoroughly understand the Shared Responsibility Model as it applies to each specific cloud service they consume [5, 8, 22, 28]. This requires consulting official documentation from CSPs (e.g., AWS, Azure, GCP) for detailed breakdowns [4, 7, 34, 38]. Furthermore, organizations should clearly define and document their internal security responsibilities, aligning them with the CSP’s model for each service, potentially using tools like a RACI matrix (Responsible, Accountable, Consulted, Informed) [27]. This ensures internal clarity and prevents security gaps due to assumed responsibilities.

7.2. Robust Identity and Access Management (IAM)

Given that IAM is almost entirely a customer responsibility, implementing a robust IAM strategy is critical. This includes [10, 17, 28, 34]:

• Principle of Least Privilege: Granting users and services only the minimum necessary permissions.
• Multi-Factor Authentication (MFA): Enforcing MFA for all privileged accounts and, ideally, for all user access.
• Regular Access Reviews: Periodically reviewing and auditing user and programmatic access permissions to revoke unneeded or outdated access.
• Centralized Identity Management: Integrating cloud IAM with enterprise identity systems for consistent policy enforcement.

7.3. Comprehensive Data Protection and Backup Strategy

Recognizing the pervasive misconception, customers must develop and implement their own comprehensive data protection strategies that go beyond CSP-provided durability. This involves [10, 22, 28, 36]:

• Regular Backups: Establishing automated, regular backup schedules for all critical data, utilizing cloud-native backup services or third-party solutions.
• Immutable Backups: For critical data, employing immutable backups that cannot be altered or deleted, offering strong protection against ransomware and accidental deletion [23, 25].
• Encryption: Ensuring all sensitive data is encrypted, both at rest and in transit, with proper key management [10, 34, 42].
• Disaster Recovery Planning: Developing and regularly testing disaster recovery plans that explicitly account for cloud environments and the shared responsibility model [12].

7.4. Continuous Security Monitoring and Posture Management

Active monitoring of cloud environments is a continuous customer responsibility. Organizations should [6, 10, 34]:

• Leverage Cloud-Native Tools: Utilize CSP-provided logging, monitoring, and security services (e.g., CloudWatch, CloudTrail, Azure Monitor, Azure Security Center, GCP Cloud Logging, Security Command Center) to gain visibility into their resources and detect anomalies.
• Implement Cloud Security Posture Management (CSPM): Deploy CSPM tools to continuously assess cloud configurations against best practices and compliance standards, identify misconfigurations, and remediate them automatically.
• Vulnerability Management: Regularly scan and patch operating systems, applications, and middleware under customer control for vulnerabilities.

7.5. Employee Training and Security Culture

The human factor is a significant vulnerability. Therefore, ongoing security awareness training for all employees, particularly those involved in cloud operations and development, is paramount. This training should emphasize the customer’s security responsibilities within the SRM, common misconfiguration pitfalls, and best practices for secure cloud usage [13, 22]. Fostering a strong security culture where security is seen as everyone’s responsibility is crucial to mitigating risks arising from human error.

Many thanks to our sponsor Esdebe who helped us prepare this research report.

8. Conclusion: Navigating the Evolving Landscape of Shared Responsibility

The Shared Responsibility Model stands as an indispensable framework for understanding and governing security in the cloud computing era. It provides a structured approach to delineating the complex interplay of security duties between cloud service providers and their customers. While CSPs meticulously secure the ‘cloud itself’ – the foundational physical infrastructure, network, and virtualization layers – the onus is unequivocally on the customer to secure ‘in the cloud’ – their data, applications, operating systems, configurations, and access controls [4, 7, 9, 28, 31, 36].

A fundamental misconception, often leading to critical security and data protection gaps, is the erroneous belief that cloud providers automatically assume full responsibility for comprehensive data backup and long-term retention [13, 15]. As this report has elaborated, while CSPs offer high durability for stored data, granular backup and recovery for customer-controlled data remains a clear customer responsibility, necessitating proactive strategies to mitigate risks such as accidental deletion, ransomware attacks, or application-level corruption [13, 15, 23].

The nuanced application of the SRM across IaaS, PaaS, and SaaS models further underscores the imperative for detailed understanding; as control shifts from customer to provider across these service models, so too does the explicit delineation of security responsibilities [1, 22, 43]. Challenges such as the inherent complexity of multi-cloud environments, potential visibility gaps into provider-managed layers, and the persistent threat of customer-induced misconfigurations demand ongoing vigilance and strategic investment [3, 5, 14, 16].

Looking forward, the evolution towards concepts like Google Cloud’s ‘Shared Fate’ suggests a maturing cloud ecosystem where CSPs are increasingly invested in aiding customers to achieve better security outcomes, moving beyond mere boundary definitions to more collaborative security enablement [5, 21]. However, this does not diminish the customer’s ultimate accountability. Experts in the field must continually educate their organizations, implement robust security controls, invest in continuous monitoring, and foster a strong security culture to effectively manage risks in the dynamic cloud landscape. The Shared Responsibility Model is not a mechanism for outsourcing security; rather, it is a call for a redefined, collaborative, and acutely aware approach to cybersecurity in the cloud.

Many thanks to our sponsor Esdebe who helped us prepare this research report.

9. References

[1] TechTarget. (2024, October 21). The cloud shared responsibility model for IaaS, PaaS and SaaS. Retrieved from https://www.techtarget.com/searchcloudcomputing/feature/The-cloud-shared-responsibility-model-for-IaaS-PaaS-and-SaaS (Original publication date: 2024-10-21)
[2] Palo Alto Networks. What is Cloud Incident Response?. Retrieved from https://www.paloaltonetworks.com/cyberpedia/what-is-cloud-incident-response
[3] Spot.io. Top 7 Cloud Security Challenges and How to Overcome Them. Retrieved from https://www.spot.io/blog/cloud-security-challenges/
[4] Amazon Web Services. The AWS Shared Responsibility Model. Retrieved from https://docs.aws.amazon.com/whitepapers/latest/aws-shared-responsibility-model/aws-shared-responsibility-model.pdf
[5] Google Cloud. (2023, August 21). Shared responsibilities and shared fate on Google Cloud. Retrieved from https://cloud.google.com/architecture/shared-responsibility-shared-fate (Original publication date: 2023-08-21)
[6] Upwind. Understanding the Shared Responsibility Model in Cloud Security. Retrieved from https://www.upwind.io/blog/shared-responsibility-model-in-cloud-security
[7] Amazon Web Services. Shared Responsibility Model. Retrieved from https://aws.amazon.com/compliance/shared-responsibility-model/
[8] Bobsguide. (2025, May 27). The shared responsibility model in cloud security. Retrieved from https://www.bobsguide.com/articles/the-shared-responsibility-model-in-cloud-security/ (Original publication date: 2025-05-27)
[9] Palo Alto Networks. Cloud Security Is a Shared Responsibility. Retrieved from https://www.paloaltonetworks.com/cloud-security/cloud-shared-responsibility-model
[10] DigitalOcean. (2024, December 9). What is the Shared Responsibility Model in Cloud Computing?. Retrieved from https://www.digitalocean.com/community/tutorials/shared-responsibility-model-cloud-computing (Original publication date: 2024-12-09)
[11] Medium. (2021, February 4). The Evolution of Cloud Computing and the Updated Shared Responsibility. Retrieved from https://medium.com/@florianlucas/the-evolution-of-cloud-computing-and-the-updated-shared-responsibility-1f81014a2a19 (Original publication date: 2021-02-04)
[12] Microsoft Azure. (2025, March 31). Shared responsibility for reliability. Retrieved from https://learn.microsoft.com/en-us/azure/architecture/framework/resiliency/shared-responsibility (Original publication date: 2025-03-31)
[13] Custom Computer Specialists. The Most Dangerous Myths About Cloud Data Backup. Retrieved from https://customcomputerspecialists.com/insights/4-most-dangerous-myths-about-cloud-data-backup
[14] Netsurion. 5 Pitfalls in Cloud Cybersecurity Shared Responsibility Model. Retrieved from https://www.netsurion.com/blog/5-pitfalls-cloud-cybersecurity-shared-responsibility-model
[15] EC-Council. (2024, September 27). Exploring the Misconceptions About Cloud Security & Its Best Practices. Retrieved from https://www.eccouncil.org/cloud-security-misconceptions/ (Original publication date: 2024-09-27)
[16] Planet 9 Inc. (2024, August 20). Shared Responsibility Model: Addressing Key Challenges to Cloud Security. Retrieved from https://www.planet9inc.com/blog/cloud-security-shared-responsibility-model-challenges/ (Original publication date: 2024-08-20)
[17] CrowdStrike. (2022, November 13). What is the Shared Responsibility Model?. Retrieved from https://www.crowdstrike.com/cybersecurity-101/cloud-security/shared-responsibility-model/ (Original publication date: 2022-11-13)
[18] Cloud Security Alliance. Cloud Incident Response. Retrieved from https://cloudsecurityalliance.org/research/cloud-incident-response/
[19] Refactored.pro. (2024, August 30). AZ-900 Azure Fundamentals – shared responsibility model. Retrieved from https://refactored.pro/az-900-azure-fundamentals-shared-responsibility-model/ (Original publication date: 2024-08-30)
[20] Computer Weekly. (2024, June 17). Gartner: Navigating incident response in the cloud. Retrieved from https://www.computerweekly.com/news/366571553/Gartner-Navigating-incident-response-in-the-cloud (Original publication date: 2024-06-17)
[21] IDC. The Evolution of Shared Responsibility Model to Shared Fate. Retrieved from https://www.idc.com/getdoc.jsp?containerId=US50488923
[22] CompTIA. (2024, May 30). IaaS vs PaaS vs SaaS Security: Key Differences You Need to Know in 2024. Retrieved from https://www.comptia.org/content/articles/iaas-vs-paas-vs-saas-security (Original publication date: 2024-05-30)
[23] US Signal. (2023, November 1). 4 Myths About Data Backup in the Cloud: What Municipalities Need to Know. Retrieved from https://ussignal.com/resources/blogs/4-myths-about-data-backup-in-the-cloud (Original publication date: 2023-11-01)
[24] Aabyss. (2024, May 8). Debunking the Top Myths Surrounding Cloud Data Backup. Retrieved from https://www.aabyss.com/blog/debunking-the-top-myths-surrounding-cloud-data-backup (Original publication date: 2024-05-08)
[25] US Signal. (2025, March 17). 5 Cloud Backup Myths Debunked for Better Data Security. Retrieved from https://ussignal.com/resources/blogs/5-cloud-backup-myths-debunked-for-better-data-security (Original publication date: 2025-03-17)
[26] Sonrai Security. Compliance Risks in the Shared Responsibility Model: Solutions for AWS & Azure. Retrieved from https://sonraisecurity.com/resources/compliance-risks-in-the-shared-responsibility-model-solutions-for-aws-azure/
[27] Research Computing University of Colorado Boulder. Shared Responsibility Model. Retrieved from https://www.colorado.edu/rc/security/docs/shared-responsibility-model
[28] Davenport Group. (2024, December 19). A Guide to Understanding the Cloud Shared Responsibility Model. Retrieved from https://davenportgroup.com/resources/blog/cloud-shared-responsibility-model/ (Original publication date: 2024-12-19)
[29] SC Media. (2020, February 7). The evolution of shared responsibility in cloud security. Retrieved from https://www.scmedia.com/analysis/the-evolution-of-shared-responsibility-in-cloud-security (Original publication date: 2020-02-07)
[30] Amazon Web Services. Shared responsibility model – Amazon Web Services: Risk and Compliance. Retrieved from https://docs.aws.amazon.com/whitepapers/latest/aws-security-compliance-shared-responsibility-model/shared-responsibility-model.html
[31] Resilient Cyber. (2023, March 27). Cloud Shared Responsibility Model: Time for an (R)Evolution?. Retrieved from https://resilientcyber.com/cloud-shared-responsibility-model-time-for-an-revolution/ (Original publication date: 2023-03-27)
[32] Zscaler. (2022, July 14). SaaS, IaaS, and PaaS: What the shared responsibility model means for zero trust. Retrieved from https://www.zscaler.com/blogs/articles/saas-iaas-and-paas-what-shared-responsibility-model-means-zero-trust (Original publication date: 2022-07-14)
[33] Digital Cloud Training. AWS Shared Responsibility Model | AWS Cheat Sheet. Retrieved from https://digitalcloud.training/aws-shared-responsibility-model/
[34] DEV Community. (2024, July 1). Shared Responsibility Model in Azure: A Comprehensive Guide. Retrieved from https://dev.to/azharb1704/shared-responsibility-model-in-azure-a-comprehensive-guide-2l1g (Original publication date: 2024-07-01)
[35] Rapid7. Shared Responsibility Model: The Ultimate Guide. Retrieved from https://www.rapid7.com/fundamentals/shared-responsibility-model/
[36] Veeam. (2024, April 18). AWS Shared Responsibility: Best Practices for Cloud Security. Retrieved from https://www.veeam.com/blog/aws-shared-responsibility.html (Original publication date: 2024-04-18)
[37] Sonrai Security. Azure Shared Responsibility Model Explained. Retrieved from https://sonraisecurity.com/resources/azure-shared-responsibility-model-explained/
[38] Tenable. (2022, March 8). The GCP Shared Responsibility Model: Everything You Need to Know. Retrieved from https://www.tenable.com/blog/the-gcp-shared-responsibility-model-everything-you-need-to-know (Original publication date: 2022-03-08)
[39] CoreStack. Azure Shared Responsibility Model: Real World Examples & Best Practices. Retrieved from https://www.corestack.io/blog/azure-shared-responsibility-model-real-world-examples-best-practices/
[40] Alert Logic. Defining a Shared Responsibility Model for Microsoft Azure. Retrieved from https://www.alertlogic.com/resources/white-papers/defining-a-shared-responsibility-model-for-microsoft-azure/
[41] Wiz. (2024, March 13). The Shared Responsibility Model Explained w/Examples. Retrieved from https://www.wiz.io/blog/shared-responsibility-model (Original publication date: 2024-03-13)
[42] Aqua Security. (2023, July 13). Cloud Shared Responsibility Model: Examples & Best Practices. Retrieved from https://www.aquasec.com/cloud-native-academy/cloud-security/shared-responsibility-model/ (Original publication date: 2023-07-13)
[43] Medium. (2024, September 1). Types of Cloud Services. IaaS, PaaS, SaaS… Many acronyms end…. Retrieved from https://medium.com/@florianlucas/types-of-cloud-services-iaas-paas-saas-many-acronyms-end-d9715a331168 (Original publication date: 2024-09-01)
[44] Emergent Software. (2024, October 1). SaaS, PaaS, and IaaS: Differences and Use Cases Explained. Retrieved from https://www.emergentsoftware.com/blog/saas-paas-iaas-differences-use-cases-explained/ (Original publication date: 2024-10-01)