Cardholder Data Encryption Playbook
AES or ECC? Pick the Right One for Every Payment Workload
You encrypt the data. You still fail the assessment.
Encryption is present, so the control feels done. But PCI DSS v4.0 tests against a precise definition of strong cryptography, not a general concept, and assessors trace algorithm name, key length, mode of operation, and key management together. Teams that treat cryptography as an implementation detail rather than a control discipline routinely produce findings at assessment time. If you cannot show your AES key length, cipher mode, and ECC curve choices are defensible, you carry compensating controls or remediation commitments that delay your Report on Compliance.
37-Page Operational Playbook
Get the encryption playbook
- Algorithm acceptability vs. the 112-bit threshold
- AES-128 vs. AES-256, GCM/CBC/XTS mode selection
- NIST-approved ECC curves and what to avoid
- Key-length justification for Requirements 3.6 and 3.7
Download the playbook
The thresholds your choices are measured against
Acceptability is not determined by algorithm name alone. These are the numbers assessors test against.
The problem is rarely the cipher. It is the rationale.
PCI DSS v4.0 does not publish a closed list of approved algorithms. It defers to NIST, so acceptability is not determined by algorithm name alone. A repeated GCM nonce, a CBC mode with no MAC, an RSA-1024 certificate on an internal API, a key stored in the same schema as the data it protects, all pass a casual glance and fail a QSA. This playbook resolves the ambiguity by mapping each choice to the specific requirement and the authoritative reference behind it.
What is inside the playbook
What you can do once you have read it
Justify every algorithm to an assessor
Point to a specific PCI DSS v4.0 sub-requirement and NIST reference for each key length, mode, and curve you deploy.
Match the primitive to the workload
Choose confidently for data at rest, data in transit, and the key-wrapping layer instead of applying one setting everywhere.
See findings before the QSA does
Recognize the recurring weak-cryptography and key-management finding patterns and close them ahead of fieldwork.
Walk into assessment ready
Apply the assessment-readiness checklist and remediation priority tiers to triage gaps and organize your evidence bundle.
Grounded in the standards assessors actually cite
Questions practitioners ask
No. It is an operational playbook for educational and informational purposes. It is not legal, regulatory, audit, or compliance advice, and you should still consult qualified counsel and your QSA on your specific obligations.
No. It distinguishes workloads, AES-256 in GCM for at-rest PANs, XTS for storage volumes, ECDH curves for key exchange, and shows where AES-128 or CBC remain defensible with documented exceptions and compensating controls.
FIPS validation is strong evidence but not the whole control. The playbook covers the documentation, key-length justification, lifecycle artifacts, and segregation-of-duties records assessors expect alongside a validated module.
Yes. It explains harvest-now-decrypt-later exposure, hybrid key exchange as an interim control, and how Requirement 12.3.3 review cycles make crypto-agility an ongoing obligation.
The Cardholder Data Encryption Playbook