Encryption for Card Data in Transit and at Rest: A PCI Guide

Requirement 3 addresses stored account data, while Requirement 4 addresses data in transit. They operate on separate axes that teams can easily confuse. Requirement 3 covers what account data you must never retain and how permitted PAN storage must be protected at rest. Requirement 4 covers the protocols and cipher settings required when cardholder data crosses open, public networks. A complete data protection posture covers both, but their controls, failure modes, and evidence differ enough that treating them as one issue creates gaps.

Requirement 3: What Storage Allows

The first major distinction in Requirement 3 is between primary account numbers (PANs), which require protection when stored, and sensitive authentication data (SAD), which cannot be retained after authorization completion under any circumstances.

SAD includes full magnetic stripe data, or track data, card validation values such as CVV2 and CVC2, the three- or four-digit card code, and PINs. The ban on storing SAD applies even when it is encrypted. PANs may be stored when made unreadable through truncation, tokenization, or encryption. SAD may not be stored at all after authorization is complete. If an authorization pipeline writes SAD to a log, database, or temporary file even for milliseconds afterward, that is a Requirement 3 violation.

For stored PANs, Requirement 3.5 requires unreadability through one of four approaches: a strong-cryptography one-way hash of the full PAN, truncation of the first six digits, last four digits, or both without permitting reconstruction, index tokens with a securely stored pad, or strong cryptography with related key management processes. Truncation is common when an application only displays the last four digits for customer reference. Encryption brings additional key management obligations.

Requirement 3.7 and Key Management

When PAN protection uses encryption instead of tokenization or truncation, Requirement 3.7 adds extensive key management duties. Keys must be generated by key-generating hardware or a process designed for cryptographically strong keys. Key-encrypting keys must be at least as strong as the data-encrypting keys they protect. Keys should be stored in as few places as possible, with split knowledge and dual control for key operations. Retire keys at the end of their cryptoperiod and replace known or suspected compromised keys.

Dual control means one person cannot access both portions of a split key. That is difficult for small teams. Tokenization avoids the issue by removing PAN storage from your environment, which is why merchants seeking a smaller Requirement 3 surface often use token-based designs. If you use encryption, document and test the key management process, and keep evidence of every procedure available for your QSA.

Requirement 4: Transit Protocols and Ciphers

Requirement 4.2.1 requires strong cryptography to protect PAN during transmission across open public networks. The current minimum is TLS 1.2. TLS 1.0 and 1.1 are prohibited, and QSAs will flag any negotiation path that can fall back to those versions.

"Negotiation" is important. A server supporting TLS 1.2 but accepting TLS 1.1 fails the Requirement 4 test, even if no client currently uses TLS 1.1. Insecure versions must be rejected, not merely ranked below newer ones. ASV scans flag TLS 1.1 support, while internal testing should confirm the configuration cannot be downgraded.

Cipher suite settings are the other concern. TLS 1.2 can still be exposed when paired with weak ciphers. Requirement 4 does not list a specific cipher set, but the DSS glossary's definition of "strong cryptography" excludes export-grade and NULL ciphers, anonymous key exchange, and suites using RC4, DES, 3DES, or MD5. Supporting TLS 1.2 while allowing TLS_RSA_WITH_RC4_128_SHA is therefore not compliant.

How Requirements 3 and 4 Connect

Compliance drift often appears where transit ends and storage begins. Data can pass through a Requirement 4 compliant path, then enter logging or caching before reaching its destination. If that layer writes card data to disk in cleartext, even briefly, the stored copy violates Requirement 3 regardless of the transit encryption.

A common pattern is a payment integration sending PANs over TLS to a third-party processor. Requirement 4 may be satisfied, while application request logging captures full bodies and the PAN in plaintext. If that log remains unencrypted at rest on a CDE application server, transit is compliant but log storage is not.

Audit log settings are the most frequent source of this problem. Mask or exclude card fields at the application layer, or make log storage meet Requirement 3 protections. Application-layer masking is simpler and should be the default for systems handling cardholder data.

Compliance Verification Must Continue

Requirements 3 and 4 both face drift. Software updates or web server changes can alter TLS settings. Application deployments can change log formats and begin capturing omitted fields. Key management procedures that were correct at audit time can also be bypassed under operational pressure.

For Requirement 4, continuous verification means repeatedly testing TLS settings for regressions. Run an automated scan of external-facing CDE endpoints at least monthly to check supported protocol versions and cipher suites. This provides a signal before the next ASV scan or QSA visit. The technical solution exists; operations are the barrier.

For Requirement 3, the more difficult ongoing check is PAN discovery: confirming that no new path stores unprotected PANs. Scanning CDE file systems and databases for PAN-like patterns can find accidental storage before an audit finding. Scope scans to CDE boundaries and exclude known-good token stores to keep false positives manageable.

One boundary matters: cryptographic verification of encryption and key management requires access to keys and key material, which we do not touch. PCIOasis monitors configuration signals, including supported protocol versions, available cipher suites, and log format changes that may indicate new field capture. Key management documentation and your QSA's review of key custodian procedures provide cryptographic assurance.

Requirement 3 and 4 Evidence for Assessment

For Requirement 3, your QSA will request documentation identifying your PAN storage method, whether truncation, tokenization, or encryption. They will also request evidence that SAD is not retained after authorization, typically a PAN discovery scan showing no SAD in your environment and an architecture diagram of the authorization flow. If encryption is used, provide the key management policy and dual-control evidence for key custodian operations.

For Requirement 4, your QSA will request proof that server configurations disable TLS 1.0 and 1.1, plus ASV results showing no insecure protocol or cipher findings on external-facing hosts. They will also request documentation protecting cardholder data between CDE components, since in-scope internal networks require protection under Requirement 4.2.2.

Internal transmission is often missed. Merchants focus on the external payment page and processor connection, but PAN may also move between a CDE application server and database over an internal network. That connection must be protected unless it uses a properly segmented trusted internal network. The segmentation basis needs separate supporting documentation.