The Shared Responsibility Model in Cloud Backup Security

The shared responsibility model defines how security obligations are divided between a cloud provider and the customer using that provider's infrastructure. In cloud backup contexts, misunderstanding where provider responsibility ends and customer accountability begins is one of the primary causes of undetected data loss and compliance failures. This reference describes the model's structure, its operational mechanics, the scenarios where boundary ambiguity creates risk, and the decision logic used to assign controls.

Definition and scope

The shared responsibility model is a contractual and architectural framework that partitions security duties across two parties: the infrastructure provider and the cloud customer. Amazon Web Services, Microsoft Azure, and Google Cloud Platform each publish formal versions of this model as part of their service documentation. The division is not negotiable in standard service agreements — providers control physical security, hypervisor integrity, and network infrastructure, while customers retain responsibility for data classification, access management, encryption key custody, and backup configuration.

For cloud backup specifically, the scope of the model extends beyond general cloud usage. Cloud backup providers within the market span dozens of service types, and each service tier — Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS) — shifts the responsibility boundary in a different direction. Under IaaS, customers manage the operating system, application stack, and backup agents. Under SaaS, the provider manages the application layer, but the customer remains solely responsible for ensuring backup coverage exists for the data stored within that application.

The National Institute of Standards and Technology addresses this partition in NIST SP 800-144, Guidelines on Security and Privacy in Public Cloud Computing, which explicitly identifies data portability, backup retention, and access control as customer-owned obligations regardless of service model.

How it works

The model operates through a layered structure, where each layer carries assigned ownership. The following breakdown reflects the standard partition across the three primary service models:

1. Physical infrastructure — Provider-owned in all models. Includes data center security, hardware maintenance, and network backbone integrity.
2. Hypervisor and virtualization layer — Provider-owned in IaaS, PaaS, and SaaS. Customers have no visibility or control at this layer.
3. Operating system — Customer-owned under IaaS. Provider-managed under PaaS and SaaS.
4. Application layer — Customer-owned under IaaS. Shared under PaaS. Provider-managed under SaaS.
5. Data and content — Customer-owned across all models without exception. This includes backup copies, retention schedules, encryption at rest, and deletion procedures.
6. Identity and access management (IAM) — Customer-owned across all models. Misconfigured IAM policies represent the most common source of backup exposure in cloud environments.
7. Backup configuration and scheduling — Customer-owned across all models. Providers may offer native backup tooling (e.g., AWS Backup, Azure Backup), but activating, configuring, and testing those tools is the customer's obligation.

The Federal Risk and Authorization Management Program (FedRAMP) operationalizes this structure for federal agency cloud use, requiring agencies to document inherited controls — those fulfilled by the provider — and customer-responsible controls within a system security plan before any cloud service achieves authorization to operate.

Common scenarios

Three scenarios illustrate where shared responsibility boundaries produce real-world failures in cloud backup security.

Scenario 1 — SaaS data without backup coverage. An organization migrates business data to a SaaS productivity platform and assumes the provider handles backup. The provider maintains platform uptime and infrastructure redundancy, but does not guarantee point-in-time recovery of user-deleted data beyond a retention window that may be as short as 30 days. The customer, having never configured a third-party backup integration, has no recoverable copy after the window expires. The HHS Office for Civil Rights has issued guidance noting that HIPAA-covered entities using cloud storage must confirm backup and recovery provisions with their Business Associate, as cloud providers are not automatically responsible for PHI recovery — (HHS Cloud Computing Guidance).

Scenario 2 — Misconfigured IAM and ransomware propagation. A customer operating IaaS workloads grants overly permissive IAM roles to backup service accounts. When ransomware compromises the production environment, it traverses the same IAM permissions into the backup storage bucket and encrypts backup copies. AWS, Azure, and GCP have all published security best practices stating that backup storage should use separate IAM identities with deny-write permissions on production credentials — (AWS Security Best Practices). The provider fulfilled its responsibility; the IAM misconfiguration was entirely within the customer's control domain.

Scenario 3 — Encryption key custody failure. A customer enables server-side encryption for backup objects but allows the cloud provider to manage the encryption keys under a provider-managed key scheme. Regulatory frameworks including the FTC Safeguards Rule (16 CFR Part 314) may require that covered financial institutions maintain independent key custody. When the provider account is compromised at the administrative level, the customer has no independent cryptographic control over backup data.

For organizations evaluating how backup services across the market address these scenarios, the reference explains how service classifications are structured.

Decision boundaries

Assigning responsibility correctly requires mapping each control category to the service model in use and the applicable regulatory framework. The following boundaries govern that assignment:

Provider-owned controls (no customer action changes the outcome):
- Physical access to data center hardware
- Network infrastructure between availability zones
- Hypervisor patch management
- Platform-level availability SLAs

Customer-owned controls (provider tooling available, but activation and configuration are customer obligations):
- Enabling backup services (e.g., AWS Backup policies, Azure Backup vaults)
- Configuring retention periods and geographic replication
- Managing encryption keys, particularly under customer-managed key (CMK) schemes
- Defining IAM policies for backup service accounts
- Testing recovery procedures — provider tools do not self-test

Shared controls (both parties contribute, but failure at either layer creates a gap):
- Patch management for customer-deployed operating systems on IaaS (customer patches; provider patches hypervisor)
- Logging and monitoring — providers generate logs, but customers must configure retention, alerting, and SIEM ingestion
- Incident response — providers notify of platform-level events; customers must maintain their own response plans covering backup environments

The distinction between IaaS and SaaS is the most consequential contrast in backup security responsibility allocation. Under IaaS, the customer controls 5 of the 7 layers verified in the How it works section. Under SaaS, the customer controls only the data layer — but that single layer contains everything that needs to be recovered. The narrower the customer's control surface, the more deliberately backup coverage must be engineered, because fewer native mechanisms exist to enforce it automatically.

NIST SP 800-53 Rev. 5, control family CP (Contingency Planning), provides the baseline control catalogue against which cloud backup responsibility assignments are audited in federal and federally-adjacent environments. CP-9 (Information System Backup) specifically requires organizations to document what is backed up, at what frequency, by which party, and under what cryptographic protections — obligations that fall entirely within the customer's domain regardless of which cloud provider hosts the data.

The how-to reference at how to use this cloud backup resource describes how service providers in this network are classified relative to responsibility model structure.