PCI DSS Cloud Backup Obligations and Controls

PCI DSS (Payment Card Industry Data Security Standard) establishes binding technical and operational controls for any organization that stores, processes, or transmits cardholder data — including all backup infrastructure where that data resides. Cloud backup environments fall squarely within PCI DSS scope when they contain or can access cardholder data (CHD) or sensitive authentication data (SAD). This page maps the specific obligations, control mechanisms, and classification boundaries that govern cloud backup under PCI DSS v4.0, the current active version published by the PCI Security Standards Council in March 2022.

Definition and scope

PCI DSS scope for cloud backup is determined by data flow and network connectivity, not by storage format or vendor designation. Under PCI DSS v4.0 (PCI Security Standards Council), any system that stores, processes, or transmits CHD — or that is networked to a system that does — is considered a "system component" subject to the full standard. This means a cloud backup repository that receives encrypted database snapshots from a cardholder data environment (CDE) is in scope, regardless of whether the backup operator directly handles card numbers.

Two categories of data drive scope determination:

• Cardholder data (CHD): Primary account number (PAN), cardholder name, expiration date, service code.
• Sensitive authentication data (SAD): Full track data, CAV2/CVC2/CVV2/CID values, PINs/PIN blocks.

SAD must never be stored after authorization under PCI DSS Requirement 3.2.1, even in encrypted backup form. CHD may be stored in backup if rendered unreadable (Requirement 3.5) through strong cryptography, tokenization, or truncation. Organizations frequently miscategorize backup systems as out-of-scope infrastructure — the PCI DSS Scoping Guidance document (available from the PCI SSC) explicitly addresses this error, classifying backup systems with access to unencrypted CHD as in-scope CDE components.

For a broader view of how compliance frameworks intersect with backup architecture, see Cloud Backup Compliance Requirements.

How it works

PCI DSS cloud backup compliance operates across a layered control framework tied to 12 top-level requirements in the standard. The requirements most directly activated by cloud backup infrastructure are:

1. Requirement 1 (Network Security Controls): Firewall or equivalent segmentation must isolate backup infrastructure from untrusted networks. Cloud backup endpoints must not be reachable from the public internet without compensating controls.
2. Requirement 3 (Protect Stored Account Data): Stored PAN must be rendered unreadable via AES-256 or equivalent. Key management must be documented and keys stored separately from encrypted data.
3. Requirement 7 (Restrict Access by Business Need): Access to backup repositories containing CHD must follow least-privilege principles. Role-based access controls must be documented and reviewed at minimum every 6 months (Requirement 7.2.4).
4. Requirement 8 (Identify Users and Authenticate): All accounts accessing backup systems must use unique IDs; shared or generic credentials are prohibited. Multi-factor authentication is required for all non-console administrative access to the CDE, which includes backup management consoles.
5. Requirement 10 (Log and Monitor All Access): Audit logs must capture all access to CHD stored in backups, all administrative actions on backup systems, and all backup job outcomes. Logs must be retained for at least 12 months, with 3 months immediately available for analysis (Requirement 10.7).
6. Requirement 11 (Test Security Systems): Backup systems in scope for PCI must be included in quarterly vulnerability scans and annual penetration testing.
7. Requirement 12 (Support Information Security): Third-party cloud backup providers that store or access CHD must execute a written agreement confirming their PCI DSS compliance obligations.

The encryption standards relevant to Requirement 3 are detailed in Cloud Backup Encryption Standards. Access control mechanisms are addressed in Cloud Backup Access Controls.

Common scenarios

Scenario 1 — SaaS payment platform with cloud backup: A software-as-a-service company processes card payments and nightly exports encrypted database backups to a cloud object storage bucket. The bucket contains PANs encrypted at rest with AES-256. The bucket is in-scope because it holds CHD, requiring network segmentation, access logging, and key management documentation even though the data is encrypted.

Scenario 2 — Tokenized CDE with offsite backup: A retailer implements a tokenization vault, replacing PANs in its operational database with tokens. Backups of the tokenized database are out-of-scope for PCI DSS because no actual PANs are present. However, backups of the tokenization vault itself are in-scope CDE components and subject to the full standard.

Scenario 3 — Third-party cloud backup vendor: An organization contracts with a cloud backup provider whose infrastructure touches CHD. Under PCI DSS Requirement 12.8, the organization must maintain a list of all such third-party service providers (TPSPs), confirm their PCI DSS compliance annually, and execute contracts specifying each party's PCI DSS responsibilities. The Shared Responsibility Model Cloud Backup framework is directly relevant to how these obligations are divided.

Scenario 4 — Ransomware affecting backup copies: If an attacker encrypts or destroys backup copies of CHD, the organization may be unable to restore card data systems, triggering incident response obligations under Requirement 12.10. Ransomware Protection Cloud Backup addresses immutability and air-gap controls that reduce this exposure.

Decision boundaries

The critical classification decisions that determine control scope:

The distinction between "connected-to" components and full CDE components is governed by network segmentation quality. Organizations that use flat network architectures cannot reduce backup systems to connected-to status — all systems on the same network segment as the CDE inherit full scope. Penetration testing must validate segmentation effectiveness annually under Requirement 11.4.

Backup audit logging and multi-factor authentication for backup platforms represent two control areas where PCI DSS assessors most frequently identify gaps during QSA reviews.

References

• PCI Security Standards Council — PCI DSS v4.0 Document Library
• PCI DSS v4.0 Full Standard (PDF)
• PCI SSC — Guidance for PCI DSS Scoping and Network Segmentation
• NIST SP 800-111 — Guide to Storage Encryption Technologies
• NIST SP 800-92 — Guide to Computer Security Log Management
• NIST Cybersecurity Framework (CSF) — Protect Function