PCI DSS in Cloud Environments: Cardholder Data Compliance Requirements

PCI DSS (Payment Card Industry Data Security Standard) governs how organizations store, process, and transmit payment card data — and cloud infrastructure introduces distinct compliance challenges that differ materially from on-premises deployments. This page covers the scope of PCI DSS requirements as they apply to cloud environments, the shared responsibility boundaries between cloud providers and merchants, the classification of cloud service models under the standard, and the technical controls required for cardholder data protection. Understanding these mechanics is essential for any organization whose cloud workloads touch the cardholder data environment (CDE).

• Definition and Scope
• Core Mechanics or Structure
• Causal Relationships or Drivers
• Classification Boundaries
• Tradeoffs and Tensions
• Common Misconceptions
• Checklist or Steps
• Reference Table or Matrix

Definition and Scope

PCI DSS is administered by the PCI Security Standards Council (PCI SSC), a body founded in 2006 by American Express, Discover, JCB International, Mastercard, and Visa. Version 4.0 of the standard, released in March 2022, contains 12 top-level requirements organized across 6 control objectives. Compliance is mandatory for any entity that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD), regardless of whether those operations occur on physical hardware or cloud infrastructure.

In cloud contexts, the cardholder data environment (CDE) is defined as the system components, people, and processes that store, process, or transmit CHD or SAD, plus any components that can directly or indirectly affect the security of the CDE (PCI SSC, PCI DSS v4.0, §1). Scope determination is the foundational task: if a cloud virtual machine, storage bucket, container, or serverless function can communicate with a CDE component, it falls within scope unless explicit network segmentation can demonstrate otherwise.

The broader regulatory context for cloud compliance situates PCI DSS alongside other overlapping frameworks including SOC 2, ISO 27001, and HIPAA, each of which may apply simultaneously to cloud-hosted payment systems.

Core Mechanics or Structure

PCI DSS v4.0 organizes its 12 requirements into 6 objectives:

1. Build and maintain a secure network and systems (Requirements 1–2): firewall configuration, secure defaults
2. Protect account data (Requirements 3–4): encryption at rest and in transit
3. Maintain a vulnerability management program (Requirements 5–6): anti-malware, secure development
4. Implement strong access control measures (Requirements 7–9): least privilege, MFA, physical access
5. Regularly monitor and test networks (Requirements 10–11): audit logs, penetration testing
6. Maintain an information security policy (Requirement 12): governance documentation

In cloud environments, these requirements map onto infrastructure that is partially managed by the cloud service provider (CSP) and partially by the customer. The PCI SSC published a dedicated guidance document, PCI DSS Cloud Computing Guidelines (Information Supplement), which clarifies that responsibility for each control is determined by the service model — IaaS, PaaS, or SaaS — and the specific contractual terms in the CSP agreement.

For organizations using infrastructure-as-code pipelines, compliance as code in the cloud offers a mechanism to enforce PCI DSS controls programmatically at the resource provisioning layer, reducing configuration drift that frequently causes scope creep.

Requirement 3 imposes specific data storage rules: primary account numbers (PANs) must be rendered unreadable anywhere they are stored, using strong cryptography (e.g., AES-256), truncation, tokenization, or one-way hashes. Requirement 4 mandates TLS 1.2 or higher for transmission of CHD across open, public networks — a specification PCI SSC hardened in v3.2.1 by deprecating TLS 1.0 and TLS 1.1.

Causal Relationships or Drivers

Cloud adoption increases PCI DSS complexity through three structural mechanisms.

Scope expansion by network adjacency. Cloud environments frequently use flat or over-permissive virtual network configurations. A misconfigured security group or VPC peering connection can pull out-of-scope systems into the CDE simply by creating a communication path to card data systems. PCI SSC guidance states that network segmentation, while not required by the standard, is a recognized scope-reduction mechanism.

Shared responsibility ambiguity. Cloud providers operate under shared responsibility models where the provider controls physical infrastructure and hypervisor-level security, while the customer controls operating system configurations, application security, and data handling. When a control gap exists — for example, a CSP that does not provide immutable audit logs by default — the merchant remains liable under PCI DSS unless contractual terms and compensating controls address the gap. A detailed treatment of these boundaries appears at shared responsibility model.

Third-party service inheritance. Payment platforms frequently chain sub-processors: a merchant may use a payment gateway (SaaS) running on a CSP (IaaS) using a colocation facility. PCI DSS v4.0 Requirement 12.8 requires merchants to maintain a list of all third-party service providers (TPSPs), confirm their PCI DSS compliance status annually, and document which requirements each TSP satisfies on the merchant's behalf.

Classification Boundaries

PCI DSS scope in cloud environments varies by cloud service model:

IaaS (Infrastructure as a Service): The customer controls the operating system, middleware, runtime, and application. Responsibility for Requirements 1 through 11 falls predominantly on the customer. The CSP is responsible for physical security (Requirement 9 physical controls) and hypervisor integrity. Relevant controls for IaaS workloads are examined in detail at IaaS and PaaS compliance controls.

PaaS (Platform as a Service): The CSP manages the OS and runtime; the customer manages the application and data. Requirements 5 and 6 (vulnerability management, secure code) remain customer responsibilities. Requirements 1 and 2 are split — the customer controls application-layer firewall rules; the CSP controls infrastructure-layer network controls.

SaaS (Software as a Service): The CSP manages the full stack. The customer's primary obligations are access control (Requirement 7–8), data retention policy (Requirement 3), and third-party oversight (Requirement 12.8). SaaS compliance obligations in payment contexts are covered at SaaS compliance obligations.

Organizations must also classify their validation path. Merchants are assigned one of four SAQ (Self-Assessment Questionnaire) levels or a Report on Compliance (ROC) requirement based on annual transaction volume. Level 1 merchants — those processing more than 6 million Visa or Mastercard transactions annually — must undergo an annual on-site audit by a Qualified Security Assessor (QSA) and quarterly network scans by an Approved Scanning Vendor (ASV), per Visa's merchant compliance program.

Tradeoffs and Tensions

Tokenization versus encryption: Tokenization replaces PANs with non-sensitive tokens and, if implemented correctly, removes tokenized systems from PCI DSS scope. Encryption preserves data format but keeps encrypted data in scope because the decryption key and the encrypted data remain within the CDE. Tokenization reduces scope but introduces dependency on the token vault, which itself becomes a high-value target. Encryption and key management in cloud compliance addresses the key management implications of both approaches.

Segmentation versus cost: Strong network segmentation reduces PCI DSS scope and therefore audit burden, but implementing microsegmentation in multi-tenant cloud environments adds architectural complexity and operational cost. A flat network architecture may be cheaper to operate but extends the audit footprint across a larger portion of the cloud estate.

Continuous monitoring versus log volume: Requirement 10 mandates retention of audit logs for 12 months, with the most recent 3 months immediately available for analysis. Cloud environments generate log volumes that can exceed tens of terabytes per month for large deployments, making SIEM and cloud compliance logging a significant cost and operational decision.

CSP compliance reports versus merchant liability: A CSP's own PCI DSS Attestation of Compliance (AOC) does not transfer compliance responsibility to the merchant. Merchants must verify which specific requirements are covered by the CSP's AOC and document remaining gaps — a step frequently misunderstood to the merchant's detriment.

Common Misconceptions

Misconception: Using a PCI-compliant cloud provider makes the merchant compliant.
Correction: A CSP's AOC covers only the infrastructure layer the CSP controls. The merchant's application, data handling practices, access controls, and monitoring configurations remain the merchant's responsibility. PCI SSC explicitly states in its Cloud Computing Guidelines that compliance of the CSP does not confer compliance on the customer.

Misconception: Tokenization eliminates all PCI DSS obligations.
Correction: Tokenization scopes down PCI DSS obligations but does not eliminate them. The token vault, the systems that generate tokens, and any system that can access the mapping table remain in scope. Requirement 3.3, 3.4, and 8.3 (MFA for CDE access) still apply to the tokenization infrastructure.

Misconception: Encrypting data at rest with a CSP-managed key satisfies Requirement 3.
Correction: PCI DSS v4.0 Requirement 3.5.1 requires that encryption keys used to protect PAN be protected against disclosure and misuse. If a CSP holds and manages the encryption key, the merchant must evaluate whether the key management practices meet PCI DSS key management requirements under Requirement 3.7. Customer-managed keys (CMKs) stored in a dedicated key management service provide stronger compliance evidence than CSP-managed default encryption.

Misconception: Serverless functions are automatically out of PCI DSS scope.
Correction: A serverless function that processes, transmits, or has access to cardholder data is in scope regardless of the underlying infrastructure model. The runtime environment may be CSP-managed, but the function code, environment variables (which may contain credentials), and invocation logs fall under merchant responsibility.

Checklist or Steps

The following sequence reflects PCI SSC's scoping methodology as documented in PCI DSS v4.0 and the associated Guidance for PCI DSS Scoping and Network Segmentation document:

1. Identify all cardholder data flows — map every point where CHD or SAD enters, traverses, or exits the cloud environment, including APIs, message queues, storage services, and logging pipelines.
2. Define the CDE boundary — classify each cloud resource as in-scope (stores/processes/transmits CHD), connected-to (can communicate with CDE), or out-of-scope (isolated from CDE by network segmentation).
3. Validate segmentation controls — document the technical mechanism (VPC isolation, security group rules, network ACLs, service mesh policies) that prevents out-of-scope systems from reaching in-scope systems; test segmentation at least annually and after significant changes (PCI DSS v4.0, Requirement 11.4.5).
4. Inventory third-party service providers — list all CSPs, payment gateways, and sub-processors; obtain their current AOC or equivalent compliance documentation; document the split-responsibility matrix for each.
5. Map controls to PCI DSS requirements — for each of the 12 requirements, document which party (merchant, CSP, or shared) is responsible, the control implementation, and the evidence source.
6. Implement encryption and key management — deploy TLS 1.2+ for all data-in-transit paths; apply AES-256 or equivalent for data at rest; store encryption keys in a dedicated key management service with access logging.
7. Configure logging and monitoring — enable centralized audit logging for all CDE-adjacent cloud resources; configure log retention to meet the 12-month/3-month-immediate-access requirement; establish alerting for anomalous access events.
8. Conduct vulnerability scanning and penetration testing — schedule quarterly ASV scans for external-facing CDE components; conduct annual penetration tests (and after major infrastructure changes) using methodology consistent with Requirement 11.4.
9. Document and review the security policy — maintain Requirement 12-compliant policies covering incident response, access control, change management, and third-party oversight; review annually.
10. Complete the appropriate validation artifact — submit SAQ or ROC based on merchant level; retain the completed AOC and supporting evidence for audit purposes.

For organizations building this compliance function from the ground up, the cloud compliance program build resource provides a structured framework for establishing policies and operational procedures.

The Cloud Compliance Authority home provides orientation across the full landscape of cloud compliance frameworks relevant to US organizations.

Reference Table or Matrix

PCI DSS v4.0 Responsibility by Cloud Service Model

Source: PCI SSC, PCI DSS v4.0 and PCI DSS Cloud Computing Guidelines (Information Supplement)

Merchant Validation Level Thresholds (Visa)

Source: Visa Merchant Data Security

References

• PCI Security Standards Council — PCI DSS v4.0
• PCI SSC — Cloud Computing Guidelines (Information Supplement)
• PCI SSC — Guidance for PCI DSS Scoping and Network Segmentation
• Visa — Merchant Data Security Best Practices
• Mastercard — Site Data Protection Program
• NIST SP 800-145 — The NIST Definition of Cloud Computing
• NIST SP 800-53 Rev 5 — Security and Privacy Controls for Information Systems