Encryption is a non-negotiable requirement for securing cardholder data. It protects cardholder data in transit, prevents interception, and is foundational for PCI DSS compliance. However, a common misconception remains: that strong encryption alone reduces PCI DSS scope.
Encrypted cardholder data is still cardholder data (CHD). If your systems store cardholder data (even if encrypted) or if you hold decryption keys, those systems remain in PCI DSS scope. However, there is a critical exception: if encryption is performed by a validated third-party service provider that retains exclusive control of the decryption keys, and your environment never has access to those keys or the ability to decrypt the data, then those encrypted values may be considered out of scope for your assessment.
Encryption transforms readable cardholder data into an unreadable format using cryptographic keys. Under PCI DSS v4, encryption is mandatory for cardholder data in transit (Requirement 4.2.1) and subject to disciplined key management (Requirement 3.6) for any storage use. Because encrypted cardholder data can be decrypted by design, encryption performed in-house does not remove cardholder data from scope: it protects it while it exists.
PCI DSS v4 clarifies that disk or partition-level encryption alone is not sufficient to render cardholder data unreadable for storage scope reduction (Requirement 3.5.1); you must combine it with tokenization, truncation, or strong cryptography with associated key-management processes. If hashing is used for cardholder data, v4 expects keyed hashing (e.g., HMAC) using a cryptographic key managed under Requirement 3.6 to mitigate brute-force reversal and rainbow table attacks. Notably, PCI DSS v4.0 removed the ability to use hashing as a sole method for rendering cardholder data unreadable for scope reduction purposes; it is no longer considered sufficient on its own.
The implication is simple: reducing where cardholder data exists matters more than how well it is encrypted. Additionally, all cryptographic keys used to protect stored CHD must be managed per Requirement 3.6, including key generation using strong methods, secure distribution, secure storage, periodic key changes, retirement/replacement of keys when compromised or reaching end of cryptoperiod, and split knowledge/dual control for manual key-management operations.
Tokenization replaces the cardholder data with a non-sensitive surrogate value (a token) that has no mathematical relationship to the original. Business systems operate on tokens, while cardholder data is stored only inside secure, PCI-compliant vaults. When implemented correctly, tokenization removes cardholder data from systems and confines any detokenization to a narrow, audited path, materially reducing PCI scope and risk.
Encryption is designed to protect sensitive data; tokenization is designed to remove it from systems. Under PCI DSS, third-party tokenization provides meaningful scope reduction, while self-managed tokenization reduces scope for downstream systems but keeps the vault environment fully in scope. Encryption remains mandatory in transit and for any unavoidable storage. Third-party managed encryption can also reduce scope when properly validated, but requires the merchant or service provider to never have access to decryption keys.
Encrypt where PCI DSS requires it (baseline). If you capture or transmit cardholder data, strong cryptography for cardholder data in transit (TLS 1.2+ with strong cipher suites, per Requirement 4.2.1) is non-negotiable; keep certificate hygiene tight, disable insecure protocols and ciphers, and ensure certificates are valid and not expired.
Tokenize early to minimize where cardholder data exists. Collect over TLS, tokenize at the edge (preferably using a third-party provider to maximize scope reduction), operate internally on tokens, and confine any necessary detokenization to a small, controlled service. Evaluate whether in-house or third-party tokenization makes sense: third-party solutions reduce your PCI scope dramatically; in-house solutions give you control but keep your vault and related infrastructure fully in scope.
Encryption protects capture and transmission; third-party tokenization keeps internal platforms cardholder-data-free and can reduce scope to a minimal SAQ. Forward/Reverse flows cover exceptional downstream endpoints that strictly require cardholder data while keeping the overall footprint small and audited. Any forward flow (detokenization) must be tightly controlled, and restricted to only those systems with legitimate business need per Requirement 7.
Tokenize at checkout with secure frames, hosted fields, or JavaScript libraries provided by your tokenization vendor; never allow cardholder data to touch your merchant systems. Use tokens for refunds, retries, subscriptions, and customer profiles. TLS protects data until tokenization occurs; tokenization then keeps PCI scope low across web/app, microservices, and data pipelines. Implement iframe or hosted page solutions that prevent cardholder data from ever entering your environment—this is the most effective way to achieve SAQ A or A-EP eligibility. Ensure your implementation is properly scoped: if cardholder data passes through your servers even momentarily before being tokenized, you cannot use the lowest-level SAQs.
Let one token travel across booking, ticketing, servicing, and partner flows; show cardholder data only at the final authorization stage if absolutely required (or better yet, never show it and use the token for authorization). Tokens enable loyalty, changes, ancillaries, and partner handoffs without widening PCI scope; consider Network Tokens for credential freshness, improved approval rates, and automatic updating when cards are reissued. Be aware that some legacy GDS (Global Distribution Systems) and airline systems require actual cardholder data due to industry standards—in these cases, use controlled, audited detokenization with strong access controls and comprehensive logging. Consider working with industry bodies to advocate for token support in these legacy systems.
Myth: Encryption and tokenization are the same.
Reality: Encryption transforms data; tokenization replaces it. Encryption is reversible with the key; tokenization creates a surrogate with no mathematical relationship to the original.
Myth: Strong encryption removes PCI scope.
Reality: Encrypted cardholder data managed in-house is still cardholder data; systems handling it remain in scope. However, validated third-party encryption where you never control decryption keys can remove encrypted data from your scope.
Myth: Full-disk encryption is enough under PCI DSS v4.
Reality: Disk/partition encryption alone is not sufficient to render cardholder data unreadable per Requirement 3.5.1; you must combine it with tokenization, truncation, or strong cryptography with proper key management. Disk encryption protects against physical theft but does not protect against application-level compromise or unauthorized access by authenticated users.
Myth: Using a third-party tokenization provider means you have no PCI compliance obligations.
Reality: While third-party tokenization can significantly reduce your assessable scope (potentially to SAQ A or A-EP), you still have compliance obligations: you must validate the provider's PCI compliance annually, ensure your implementation properly uses tokens and never handles cardholder data, maintain security controls for the components that remain in scope, and complete the appropriate SAQ. You cannot outsource responsibility, only the management of specific systems.
Encryption and tokenization are most effective when used together, not as alternatives. Encryption is mandatory (especially in transit per Requirement 4.2.1), but self-managed encryption doesn't reduce PCI scope by itself. Third-party managed encryption can. The most effective approach under PCI DSS v4 for scope reduction is to tokenize as early as possible using a PCI-compliant third-party provider.
.svg)
.png)
