PCI DSS Cloud Backup Obligations and Controls

PCI DSS (Payment Card Industry Data Security Standard) imposes specific obligations on any organization that stores, processes, or transmits cardholder data — including the cloud-based backup systems that retain copies of that data. The standard governs not only production environments but the full lifecycle of cardholder data (CHD) and sensitive authentication data (SAD), meaning backup repositories are subject to the same encryption, access control, and audit requirements as primary systems. Organizations using cloud infrastructure for backup must map their architecture against PCI DSS requirements precisely, as misconfiguration in a backup layer can expose the entire cardholder data environment (CDE) to scope expansion and audit failure.

Definition and scope

PCI DSS is maintained by the PCI Security Standards Council (PCI SSC), an independent body founded by American Express, Discover, JCB International, Mastercard, and Visa. The standard reached version 4.0 in March 2022, with version 3.2.1 formally retired in March 2024 (PCI SSC, PCI DSS v4.0).

Scope under PCI DSS v4.0 extends to all system components that store, process, or transmit CHD or SAD, as well as systems that connect to or could impact the security of those components. Cloud backup repositories that hold encrypted or unencrypted cardholder data fall squarely within this scope — a point explicitly addressed in the PCI SSC Cloud Computing Guidelines (Information Supplement), which clarifies that cloud service providers (CSPs) and their customers share a shared responsibility model in which backup data inherits CDE obligations.

Three categories of data define what triggers backup obligations:

1. Primary Account Numbers (PAN) — The 16-digit card number; must be rendered unreadable anywhere it is stored, including backups (PCI DSS v4.0, Requirement 3.5.1).
2. Cardholder Data (CHD) — PAN plus cardholder name, expiration date, and service code.
3. Sensitive Authentication Data (SAD) — Full magnetic stripe data, CVV/CVC codes, and PINs; SAD must never be stored post-authorization, including in backup snapshots (Requirement 3.2.1).

The cloud backup providers available through this provider network identify providers by their stated PCI DSS compliance posture, which directly affects how scope is determined during a Qualified Security Assessor (QSA) engagement.

How it works

PCI DSS compliance for cloud backup operates through a structured set of requirement domains. The following breakdown maps the standard's primary requirement families to their backup-specific implications:

1. Encryption at rest (Requirement 3.5): All stored PAN must be rendered unreadable using strong cryptography. For cloud backups, this means AES-256 encryption at the object or volume level is the accepted baseline. Encryption keys must be managed separately from the encrypted data — storing keys in the same backup repository as the encrypted CHD is a finding.

2. Encryption in transit (Requirement 4.2): Backup data transmitted to cloud storage endpoints must use TLS 1.2 or higher. Older protocols (SSL, TLS 1.0, TLS 1.1) are explicitly prohibited under v4.0.

3. Access control (Requirements 7 and 8): Access to backup repositories must follow least-privilege principles. Multi-factor authentication (MFA) is required for all non-console administrative access to the CDE, including backup management consoles, under Requirement 8.4.2.

4. Audit logging (Requirement 10): Logs covering backup operations — initiation, completion, deletion, and restoration — must be retained for at least 12 months, with 3 months immediately available for analysis (Requirement 10.7).

5. Testing and verification (Requirement 11): Backup integrity and restoration capability must be validated periodically; penetration testing scope includes backup systems within the CDE boundary.

6. Vendor management (Requirement 12.8): Written agreements with cloud backup vendors must confirm their PCI DSS responsibilities. A CSP's own PCI DSS certification does not transfer compliance to the customer — each party's scope must be documented in a responsibility matrix.

The reference explains how provider classifications in this network relate to shared responsibility documentation.

Common scenarios

Scenario 1 — Backup of a payment application database to cloud object storage: A merchant runs a PostgreSQL database containing PANs and backs it up nightly to Amazon S3. The backup falls within CDE scope. AWS's PCI DSS Attestation of Compliance (AWS Compliance Programs) covers the infrastructure layer, but the merchant retains responsibility for encryption of the backup objects, key management, bucket access policies, and logging.

Scenario 2 — SaaS payment platform with CSP-managed backups: A payment service provider uses a SaaS platform that performs automated backups. The CSP's PCI DSS certification applies to its own infrastructure. The merchant must obtain and review the CSP's Attestation of Compliance (AOC) and a responsibility matrix confirming that CHD within backups is protected under Requirement 12.8.

Scenario 3 — Tokenized environment backup: An organization implements tokenization, replacing live PANs with tokens before data reaches backup systems. If implemented correctly, backup repositories may fall outside CDE scope — removing PCI DSS backup obligations for those repositories. The PCI SSC's Tokenization Product Security Guidelines defines the conditions under which tokenized data is out of scope.

Scenario 4 — Cross-region backup replication: An organization replicates encrypted backups across AWS regions. Both the primary and replica backup locations inherit CDE scope, requiring consistent encryption, access control, and logging controls in each region. Data transfer between regions must occur over encrypted channels meeting Requirement 4.2.

Decision boundaries

The central compliance decision is whether a backup repository is in scope for PCI DSS — and this determination controls the entire control burden applied to that system.

In scope vs. out of scope: A backup repository is in scope if it stores CHD or SAD in any readable form, or if it is networked in a way that could impact CDE security. A repository storing only tokenized data or data with PANs rendered unreadable through approved cryptographic methods, and network-isolated from the CDE, may qualify as out of scope — subject to QSA confirmation.

Customer responsibility vs. CSP responsibility: The division of controls between a cloud backup customer and the CSP must be documented, not assumed. AWS, Microsoft Azure, and Google Cloud each publish responsibility matrices specific to their PCI DSS AOCs. A customer whose QSA finds undocumented responsibility gaps in the backup layer faces a Requirement 12.8 deficiency regardless of the CSP's own certification status.

Encryption key custody: Where keys are managed by the CSP (CSP-managed encryption), the CSP controls access to plaintext data. Where keys are managed by the customer (customer-managed encryption, such as AWS KMS with customer-managed keys), the customer retains cryptographic control. For PCI DSS purposes, customer-managed key custody strengthens the compliance posture by eliminating CSP administrative access to CHD — a distinction QSAs evaluate against Requirements 3.6 and 3.7.

Retention vs. deletion obligations: PCI DSS v4.0 Requirement 3.2.1 prohibits post-authorization storage of SAD. Backup retention policies must include logic that prevents SAD from persisting in backup snapshots. Automated deletion mechanisms and periodic backup content audits are the two primary controls used to demonstrate compliance with this boundary.

The how-to-use-this-cloud-backup-resource reference describes how provider compliance documentation is indexed within this network, supporting the vendor verification process required under Requirement 12.8.