Category: Data Protection Methods

Rendering PAN Unreadable

Also known as: Render PAN Unreadable, Making Stored PAN Unreadable

Simply put

Rendering PAN unreadable means transforming a stored payment card number so that it cannot be read as the original number if someone gains access to it. PCI DSS requires this protection wherever the primary account number (PAN) is stored, such as on backup media, portable digital media, and in logs. There are several accepted methods to achieve this, and the choice affects how the data is protected and whether it can be recovered.

Formal definition

Rendering PAN unreadable refers to the PCI DSS control objective of ensuring that the primary account number (PAN) cannot be read in its original form anywhere it is stored, including on portable digital media, backup media, and in logs. Recognized approaches include one-way hashes based on strong cryptography (of the entire PAN), truncation (permanently removing a segment of the PAN according to approved truncation formats, such that no more than the first six and last four digits are retained), index tokens, and strong cryptography with associated key-management processes and procedures. These methods differ materially: truncation and one-way hashing are non-reversible transformations, whereas encryption is reversible with the appropriate keys and therefore depends on sound key management; masking (a display control) is distinct from truncation (which removes stored data). The effect of any method on data protection and PCI DSS scope depends on its specific implementation and validation, not on the label alone. This control addresses stored PAN, a form of cardholder data; it is separate from the prohibition on storing sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, PINs/PIN blocks) after authorization, which must not be stored regardless of how it is protected. This requirement has historically been associated with PCI DSS Requirement 3.4, but requirement numbering and wording differ between versions of the standard; readers should confirm the applicable requirement against the current published version of PCI DSS.

Why it matters

Stored payment card numbers are a primary target for attackers, and any place a primary account number (PAN) lands at rest — backup media, portable digital media, application logs, or databases — represents a potential point of exposure. Rendering PAN unreadable is the control that reduces the value of that stored data to an attacker who obtains it, because the number can no longer be read in its original form without additional means such as encryption keys. This is why PCI DSS requires the protection wherever PAN is stored, rather than only in the systems teams consider primary.

The method chosen matters as much as the fact that a method is applied. Truncation and one-way hashing based on strong cryptography are non-reversible, so there is no key to steal or manage, but the original PAN cannot be recovered. Strong cryptography is reversible with the appropriate keys, which preserves business use of the data but shifts the security burden onto key-management processes; if keys are poorly protected, the underlying protection can be undermined. Because the label alone does not determine the outcome, the effect of any approach on data protection and on PCI DSS scope depends on how it is implemented and validated.

This control also has clear boundaries that teams should not overlook. Rendering PAN unreadable governs stored PAN, which is a form of cardholder data; it is separate from the prohibition on storing sensitive authentication data — full track data, CAV2/CVC2/CVV2/CID, and PINs/PIN blocks — which must not be stored after authorization regardless of how it is protected. Treating one requirement as if it satisfies the other is a common and consequential misunderstanding.

Who it's relevant to

Security engineers and application developers

Teams building or maintaining systems that store PAN must select and correctly implement an approved method — hashing, truncation, index tokens, or strong cryptography with key management — and ensure it is applied everywhere PAN is stored, including logs and backups. Because the protective effect depends on implementation rather than the label, careful design and validation are essential, particularly for the key-management processes that encryption relies on.

Compliance officers and QSAs

Those assessing or attesting to PCI DSS compliance need to verify that stored PAN is rendered unreadable across all storage locations and that the chosen method meets the standard's definitions, such as approved truncation formats retaining no more than the first six and last four digits. They should confirm the applicable requirement against the current published version of PCI DSS rather than assuming a fixed requirement number, and confirm that this control is not conflated with the separate prohibition on storing sensitive authentication data.

Database and infrastructure administrators

Administrators responsible for storage, backups, portable media, and log management are directly in scope, since PAN can appear in places outside primary transaction databases. They help ensure that unreadable-rendering methods extend to backup media and logs and that reversible methods are supported by protected key management.

Merchant and processor risk teams

Risk stakeholders weigh the trade-off between non-reversible methods (truncation, hashing), which minimize recoverable data but limit later use, and reversible encryption, which preserves business use at the cost of managing keys. Understanding these differences supports decisions that reduce exposure while meeting operational needs, and reinforces that rendering PAN unreadable does not address sensitive authentication data, which must not be stored after authorization at all.

Inside Rendering PAN Unreadable

One-way hashes of the entire PAN

Applying a strong one-way cryptographic hash to the full PAN so the original value cannot be practically recovered. Because PANs occupy a predictable and relatively small value space, hashing without additional protection can be vulnerable to brute-force or precomputation; keyed hashing (using a secret key) is generally expected to reduce this risk. Consult the current published PCI DSS for the exact method and wording, as these differ between versions.

Truncation

Permanently removing a segment of the PAN so the full value cannot be reconstructed from the retained portion. Truncation differs from masking: truncation permanently discards digits, while masking hides digits in display without necessarily removing the underlying stored value. The specific number and position of digits that may be retained should be confirmed against the current standard and applicable card brand rules.

Index tokens

Substituting the PAN with a token that has no exploitable value or mathematical relationship to the original PAN, where the mapping is held in a securely protected token vault or equivalent. Tokenization is not encryption: it replaces the data value rather than transforming it with a reversible algorithm, and its effect on scope depends on implementation and validation, not on the label alone.

Strong cryptography with associated key management

Encrypting the PAN using strong cryptography paired with documented key-management processes and procedures for generating, distributing, storing, rotating, and retiring keys. Encryption is reversible by design, so protecting the keys is central; where the same environment holds both ciphertext and the keys, the data may still be considered present for scope purposes.

Scope of applicability (cardholder data vs. sensitive authentication data)

Rendering PAN unreadable applies to stored PAN, which is cardholder data that may be retained under defined controls. It does not authorize storing sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, PINs and PIN blocks), which must not be stored after authorization even if encrypted.

Masking (display control, distinct from storage protection)

Masking limits the digits of a PAN shown on screens, receipts, or reports based on business need to know. It is a display-time control and is generally distinct from the methods used to render stored PAN unreadable; masking a displayed value does not by itself render a stored PAN unreadable.

Common questions

Answers to the questions practitioners most commonly ask about Rendering PAN Unreadable.

Does encrypting the PAN mean it is automatically rendered unreadable and therefore out of PCI DSS scope?

No. Applying encryption does not by itself remove data from PCI DSS scope or automatically satisfy the requirement to render PAN unreadable. The effect on scope depends on the implementation and how it is validated, not on the label 'encryption' alone. Where the entity has access to both the ciphertext and the means to decrypt it, the PAN and the cryptographic keys remain in scope, and key management controls apply. Whether encryption alone is an acceptable method of rendering PAN unreadable, and under what conditions, should be confirmed against the current published PCI DSS standard rather than assumed.

Are truncation, masking, hashing, tokenization, and encryption interchangeable ways to render PAN unreadable?

No. These methods transform or reduce data differently and are not interchangeable. Truncation permanently removes a portion of the PAN, masking controls what is displayed while the underlying data may still be stored, hashing produces a one-way representation, tokenization substitutes a surrogate value, and encryption produces recoverable ciphertext under key control. Each has different implications for reversibility, retention, and PCI DSS scope, and each must be implemented and validated to established criteria. The label alone does not determine whether PAN is adequately rendered unreadable; confirm the acceptable methods and their conditions against the current published standard.

If we display only a masked PAN to users but still store the full PAN, have we met the requirement to render stored PAN unreadable?

Masking addresses what is displayed, which is a distinct control from rendering stored PAN unreadable. If the full PAN is still stored in a recoverable, readable form, masking on screen does not satisfy the storage requirement on its own. You would still need an acceptable method applied to the stored PAN itself. Treat display masking and storage protection as separate obligations, and confirm the specific requirements and any conditions against the current published PCI DSS standard.

How should we handle the fact that requirement numbers for rendering PAN unreadable may differ between PCI DSS versions?

Do not hardcode a fixed requirement number in policies, tickets, or evidence references if you expect them to remain accurate across versions, because requirement numbering and wording differ between PCI DSS versions. Reference the control by its intent, rendering stored PAN unreadable, and map it to the applicable numbered requirement in the version you are being assessed against. Confirm the current numbering and wording against the published standard for that version before finalizing documentation.

Does rendering PAN unreadable change how we must treat sensitive authentication data?

No. Rendering stored PAN unreadable is a control that applies to cardholder data such as the PAN. It is separate from the prohibition on retaining sensitive authentication data, which includes full track data, card verification codes, and PINs or PIN blocks. Sensitive authentication data must not be stored after authorization even when encrypted, so a method that renders PAN unreadable does not create an allowance to retain sensitive authentication data. Keep the two obligations distinct in your data flows and retention controls.

When we use a method that requires cryptographic keys, what should we plan for beyond applying the algorithm?

Where the method relies on cryptographic keys, such as with encryption, the keys and their lifecycle become part of what must be protected, and key management controls apply. Plan for how keys are generated, stored, restricted, rotated, and retired, and for separation between the protected data and the means to recover it. Because the presence of keys and access to them affect scope and validation, treat key management as an integral part of the control rather than an afterthought, and confirm the specific expectations against the current published PCI DSS standard.

Common misconceptions

Masking a PAN on screen means the stored PAN is rendered unreadable.

Masking controls what is displayed based on need to know, but it does not necessarily change how the PAN is stored. Rendering stored PAN unreadable requires methods such as truncation, appropriate one-way hashing, index tokens, or strong cryptography with key management. A masked display can coexist with an unprotected stored value.

Tokenization and encryption are interchangeable ways to render PAN unreadable.

They work differently. Tokenization substitutes the PAN with a value that has no exploitable relationship to the original, with the mapping held in a protected vault, while encryption reversibly transforms the PAN and relies on protecting the keys. Their impact on PCI DSS scope depends on the specific implementation and how it is validated, not on the label used.

If sensitive authentication data is encrypted, it can be stored like PAN.

Sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks must not be stored after authorization, even when encrypted. Methods for rendering PAN unreadable address cardholder data that may be retained under defined controls, and do not extend to permitting storage of sensitive authentication data.

Best practices

Confirm the acceptable methods and any digit-retention limits for truncation and hashing against the current published PCI DSS version and applicable card brand rules, rather than assuming a fixed requirement number.

Do not store sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, PINs and PIN blocks) after authorization; scope rendering-unreadable methods to stored PAN and other retained cardholder data only.

Where encryption is used, implement documented key-management processes for key generation, distribution, storage, rotation, and retirement, and avoid holding keys and ciphertext together in a way that leaves the data effectively recoverable.

Prefer keyed hashing or additional protection over unsalted one-way hashes of the PAN alone, given the predictable and limited PAN value space.

Treat masking as a display-time control based on need to know, and keep it distinct from the methods used to render stored PAN unreadable.

Validate the chosen approach (truncation, hashing, index tokens, or encryption) through appropriate assessment, since scope reduction depends on implementation and validation rather than on the labeled technique.