PCI DSS Encryption Requirements for Payment Data
The Payment Card Industry Data Security Standard (PCI DSS) establishes binding encryption requirements for any organization that stores, processes, or transmits cardholder data. These requirements govern cryptographic algorithm selection, key management practices, transmission security, and the scope of protected data elements across the full payment processing lifecycle. Non-compliance exposes acquiring banks, merchants, and service providers to fines, suspension of card processing privileges, and mandatory forensic audits following a breach.
Definition and scope
PCI DSS is a private regulatory framework administered by the PCI Security Standards Council (PCI SSC), a body founded jointly by American Express, Discover, JCB International, Mastercard, and Visa. The standard is not a US federal statute, but card network contracts make compliance effectively mandatory for any entity that accepts branded payment cards. PCI DSS version 4.0, published by PCI SSC in March 2022, became the sole active version in March 2024 after PCI DSS v3.2.1 retired.
The encryption scope under PCI DSS centers on two data categories:
- Primary Account Number (PAN) — the 16-digit card number. PAN is the primary protected element and must be rendered unreadable anywhere it is stored (PCI DSS v4.0, Requirement 3.5).
- Sensitive Authentication Data (SAD) — includes full magnetic stripe data, card verification codes (CVV/CVC), and PINs. SAD must never be stored after authorization, regardless of encryption status.
The Cardholder Data Environment (CDE) defines the compliance boundary: all systems that store, process, or transmit PAN, plus all systems directly connected to or capable of affecting those systems. Scope reduction — through network segmentation or tokenization — is one of the primary architectural strategies used to limit the surface area subject to PCI DSS controls.
PCI DSS applies to merchants at five defined levels, determined by annual transaction volume, with Level 1 merchants (exceeding 6 million Visa or Mastercard transactions annually) subject to annual on-site audits conducted by a Qualified Security Assessor (QSA).
How it works
PCI DSS encryption requirements are distributed across two primary requirement domains: Requirement 3 (Protect Stored Account Data) and Requirement 4 (Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks).
Requirement 3 — Stored Data Protection mandates that PAN stored in any form must be unreadable using one of four approved techniques:
- One-way hashes based on strong cryptography (SHA-256 or stronger, per PCI DSS guidance aligned with NIST FIPS 180-4)
AES-256 is the dominant symmetric cipher deployed for PAN encryption at rest. PCI DSS does not mandate a specific algorithm by name but requires alignment with "industry-accepted" standards — a threshold that excludes deprecated algorithms such as DES, 3DES (deprecated by NIST SP 800-131A Rev 2 for most uses), and RC4.
Requirement 4 — Transmission Security prohibits sending unprotected PANs over open, public networks. Compliant implementations use TLS 1.2 or TLS 1.3; earlier protocol versions including SSL 3.0 and TLS 1.0 were formally disallowed under PCI DSS v3.2.1 and remain prohibited under v4.0. This requirement governs payment terminals, e-commerce checkouts, API integrations, and any network path where PAN traverses infrastructure not under the merchant's exclusive physical control. The maps the service categories involved in building and auditing these transmission controls.
Key Management is addressed in Requirement 3.7, which specifies a structured key lifecycle including generation using approved random number generators, secure distribution, storage in the fewest possible locations, retirement at the end of a defined cryptoperiod, and destruction procedures that prevent key reconstruction. Dual control and split knowledge are required for manual key management operations, meaning no single custodian can access a complete key without a second authorized party.
Common scenarios
E-commerce checkout: A cardholder enters PAN into a browser form. Point-to-point encryption (P2PE) or a payment page hosted by a PCI DSS-compliant payment processor removes the PAN from the merchant's environment before it is submitted. Under a validated P2PE solution, the merchant's CDE scope is substantially reduced because the merchant never receives the plaintext PAN.
In-person card-present transactions: PAN is encrypted at the point of interaction (POI) terminal using hardware-based encryption. The encrypted payload travels to a payment processor where decryption occurs within a secure decryption environment. Terminals must be PCI PTS (Pin Transaction Security) approved.
Tokenization as a scope-reduction strategy: Rather than encrypting stored PANs, tokenization replaces the PAN with a surrogate value (token) that carries no mathematical relationship to the original number. Tokens are resolved only within the token vault, which is isolated from merchant systems. PCI SSC distinguishes tokenization from encryption: tokens do not require key management on the merchant side but shift the compliance burden to the token service provider (TSP). Merchants using a third-party TSP must verify the TSP holds a current PCI DSS certification. The broader landscape of encryption service providers includes both token vault operators and key management service providers.
Cloud-hosted payment systems: Merchants processing payments within AWS, Azure, or GCP environments must ensure the cloud provider's shared-responsibility model does not leave PAN unencrypted in object storage, database snapshots, or log files. Cloud provider compliance attestations (e.g., AWS PCI DSS Compliance Package) cover the provider's infrastructure but do not extend to merchant application layers. Key management using a dedicated Hardware Security Module (HSM) or a cloud-native KMS with customer-managed keys is required to satisfy Requirement 3.7 in these environments.
Decision boundaries
The primary classification boundary in PCI DSS encryption is whether an organization stores PAN at all. If PAN is never stored — achieved through tokenization or immediate pass-through to a processor — Requirements 3.4 through 3.7 are largely inapplicable to the merchant's own systems.
A secondary boundary separates encryption from tokenization:
| Attribute | Encryption | Tokenization |
|---|---|---|
| Reversibility | Yes, with decryption key | Yes, within token vault only |
| Key management burden | Merchant or key custodian | Token service provider |
| CDE scope impact | Reduces risk; CDE still exists | Can eliminate merchant CDE if fully outsourced |
| Regulatory coverage | PCI DSS Req. 3.5 | PCI SSC Tokenization Guidelines |
A third boundary involves algorithm currency. Organizations still operating legacy systems with 3DES are operating outside PCI DSS compliance for new implementations and must migrate. NIST SP 800-131A Rev 2 disallows 3DES for federal use after 2023; PCI DSS v4.0 aligns with this posture by requiring "strong cryptography" that meets current NIST guidance.
The encryption resource overview provides additional context on how cryptographic standards intersect across compliance frameworks, including how PCI DSS requirements compare to HIPAA addressable encryption specifications and federal FIPS mandates.
Service providers — entities that store, process, or transmit PAN on behalf of another organization — carry elevated obligations under PCI DSS. They must maintain their own PCI DSS certification and provide documentation to each customer. A merchant's compliance posture is only as strong as the weakest link in the chain of certified providers handling PAN in the transaction flow.