PCI DSS Cardholder Data Environment

Definition

The Cardholder Data Environment (CDE) is the set of people, processes, and technology that store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD). PCI DSS requirements apply fully inside the CDE; connected systems may fall into connected-to or out-of-scope categories depending on network segmentation and data flows. On AWS, the CDE is usually isolated in dedicated accounts or VPC segments with strict security groups, encryption, logging, and access controls — but scope reduction through tokenization or hosted payment fields often delivers more value than hardening a large self-built CDE.

When to use it

• You process, store, or transmit PAN (primary account numbers) in systems you operate — you must define and secure the CDE
• Architecture reviews for fintech, e-commerce, or subscription billing on AWS before QSA or SAQ assessment
• Evaluating network segmentation — subnets, security groups, NACLs, and peering — that bound PCI scope
• Post-incident remediation where assessors require explicit CDE boundary documentation

When not to use it

• Token-only architectures where your systems never see PAN — scope shrinks dramatically; do not over-engineer a CDE you do not need
• Using Stripe, Adyen, or similar hosted fields where card data posts directly to the processor — your CDE may exclude raw card handling
• Treating “we use AWS” as PCI compliance — AWS PCI Level 1 attestation covers the cloud; you still validate your CDE design
• Storing CVV, full magnetic stripe, or PIN data after authorization — prohibited regardless of encryption

Tips

• Reduce scope first: redirect card entry to a PCI-validated processor; retain tokens in your database instead of PAN
• Isolate the CDE in a dedicated AWS account with SCP guardrails; separate production CDE from dev/test card data entirely
• Encrypt data at rest (KMS) and in transit (TLS 1.2+); disable insecure ciphers on load balancers touching the CDE
• Log all access with CloudTrail, VPC Flow Logs, and application audit trails — assessors expect demonstrable review processes
• Document every data flow diagram from browser to processor; ambiguous flows expand scope in assessments

Gotchas

Serious

• Scope expansion via logging: Application logs that capture PAN or full track data pull logging systems into CDE scope.
• Shared databases: Multi-tenant tables mixing card data with general user profiles widen blast radius and assessment complexity.
• Flat VPCs: Workloads “logically separated” but on shared subnets without network controls fail segmentation tests.

Regular

• Test card numbers in production-like environments still require controls — non-production is not automatically out of scope if real PAN appears.
• Third-party admin tools with broad CDE access become in-scope systems — vet vendor access paths.
• SAQ type depends on processing method — self-assessment eligibility is not universal for all merchant levels.

Official references

• PCI DSS on AWS whitepaper — architecting PCI workloads on AWS
• AWS PCI compliance — AWS shared responsibility for PCI

Related FactualMinds content

• PCI DSS compliance on AWS: architecture guide
• Cloud Compliance Services