PCI DSS Encryption Requirements for Payment Data
The Payment Card Industry Data Security Standard (PCI DSS) establishes mandatory cryptographic controls for any organization that stores, processes, or transmits cardholder data. These requirements govern which algorithms are acceptable, how keys must be managed, and where encryption must be applied across payment infrastructures. Non-compliance carries financial penalties and can result in the revocation of card acceptance privileges — making these technical specifications operationally critical for merchants, processors, and service providers at every scale.
Definition and scope
PCI DSS is administered by the PCI Security Standards Council (PCI SSC), an independent body founded in 2006 by American Express, Discover, JCB, Mastercard, and Visa. The standard applies to all entities that handle Primary Account Numbers (PANs) — the 13- to 19-digit sequences embossed on payment cards — along with associated sensitive authentication data including CVV codes and PIN blocks.
The encryption requirements are concentrated in Requirement 3 (protect stored account data) and Requirement 4 (protect cardholder data with strong cryptography during transmission over open, public networks) of PCI DSS version 4.0, published by PCI SSC in March 2022. Version 4.0 replaced version 3.2.1 and introduced expanded scope for multi-factor authentication and customized implementation paths.
Scope under PCI DSS extends beyond payment terminals. Any system that can connect to or influence the security of cardholder data — including internal networks, cloud environments, and third-party integrations — falls within the Cardholder Data Environment (CDE). Tokenization vs. encryption is a structurally significant distinction here: tokenization replaces PANs with non-sensitive substitutes and can reduce CDE scope, whereas encryption retains the sensitive value in a protected form, keeping the encrypted data within scope.
How it works
PCI DSS encryption requirements operate across three functional layers: data at rest, data in transit, and key management.
Data at rest (Requirement 3)
PANs stored in any medium — databases, log files, backup archives — must be rendered unreadable using one of the following approved methods (PCI DSS v4.0, Requirement 3.5.1):
- Strong one-way hash functions (hashing of the full PAN) — see Hashing vs. Encryption for the functional distinction.
- Truncation (removing a segment of the PAN so the full number is not stored).
- Index tokens with securely stored pads.
- Strong cryptography using algorithms such as AES-256 or RSA-2048, paired with secure key management.
The AES encryption standard with a 256-bit key is the most widely deployed option for stored PAN encryption. PCI SSC explicitly disallows algorithms classified as weak or deprecated, including DES, RC2, RC4, and MD5 (for security purposes).
Data in transit (Requirement 4)
Cardholder data transmitted across open, public networks must be protected using strong cryptography. Acceptable protocols are TLS 1.2 and TLS 1.3; SSL and TLS versions below 1.2 are prohibited and cannot be used as security controls. The deprecation of SSL and early TLS has been a compliance enforcement point since the PCI DSS 3.1 migration deadline. TLS/SSL encryption protocols describes the technical architecture underlying compliant transport security.
Key management (Requirement 3.6 and 3.7)
Cryptographic keys protecting cardholder data are subject to a formal lifecycle covering generation, distribution, storage, retirement, and destruction. Key-encrypting keys must be at least as strong as the data-encrypting keys they protect. Dual control and split knowledge procedures are required for manual key management operations. Encryption key management and Hardware Security Modules (HSMs) are the primary infrastructure mechanisms used to implement these controls.
Common scenarios
Point-of-Interaction (POI) encryption: Payment terminals encrypt PANs at the moment of card swipe, dip, or tap using Point-to-Point Encryption (P2PE). PCI SSC maintains a separate P2PE standard; solutions validated under that standard can significantly reduce the merchant's CDE scope.
E-commerce environments: Online checkout flows must implement TLS 1.2+ on all pages that collect cardholder data. Payment iframes served from a PCI-compliant processor can shift scope, but the merchant's network handling the session remains subject to Requirement 4.
Cloud-based payment processing: Encrypting cardholder data in cloud storage requires careful key custody. The Bring Your Own Key (BYOK) model allows organizations to retain control of encryption keys even when data resides in third-party cloud infrastructure. Encryption for cloud environments outlines the architectural considerations applicable to PCI-scoped workloads.
Database storage: Relational databases holding PAN data require column-level or tablespace encryption, with key storage segregated from the database server itself. Database encryption methods covers the technical implementation patterns that align with Requirement 3.5.
Decision boundaries
PCI DSS encryption requirements are not uniform across all entity types. The Merchant Level classification — Level 1 through Level 4, determined by annual transaction volume — affects the validation method (on-site audit versus Self-Assessment Questionnaire) but not the technical cryptographic requirements themselves. Algorithm and protocol standards apply uniformly regardless of merchant size.
A critical boundary exists between encryption and tokenization. A tokenized PAN removed from scope through a validated tokenization service eliminates the encryption obligation for that stored value. However, if the token-to-PAN mapping table is stored within the same environment, that environment remains in scope.
Encryption vs. tokenization — key structural differences:
| Attribute | Encryption | Tokenization |
|---|---|---|
| Stored value | Ciphertext of original PAN | Surrogate token (no PAN) |
| Reversibility | Decryptable with key | Reversible only via vault |
| CDE scope impact | Retains CDE membership | Can reduce CDE scope |
| PCI SSC validation | Algorithm requirements apply | Separate tokenization standard |
Organizations using FIPS 140-validated cryptographic modules satisfy the PCI SSC "strong cryptography" definition, as PCI DSS references FIPS 140-2 (and by extension FIPS 140-3) as an acceptable benchmark for module validation. This intersection with federal cryptographic standards is particularly relevant for payment processors serving government agencies.
The cryptographic key lifecycle — from generation through destruction — must be documented and procedurally enforced under PCI DSS. Controls without documentary evidence fail during a Qualified Security Assessor (QSA) audit regardless of technical implementation quality.
References
- PCI Security Standards Council — PCI DSS v4.0 Document Library
- PCI DSS v4.0 Requirements and Testing Procedures (PCI SSC, 2022)
- NIST FIPS 140-3: Security Requirements for Cryptographic Modules
- NIST Special Publication 800-175B Rev. 1: Guideline for Using Cryptographic Standards in the Federal Government
- PCI SSC Point-to-Point Encryption (P2PE) Standard
- NIST Cryptographic Algorithm Validation Program (CAVP)