Skip to main content
Category: Data Protection Methods

Truncation

Simply put

Truncation is a method of shortening a piece of data by permanently removing part of it. In a general sense, it means cutting off or dropping portions of a value, such as digits after a decimal point in a number.

Formal definition

Truncation is an operation that permanently removes a defined portion of a data value, retaining only a specified subset. In mathematics and computer science, this commonly refers to limiting the number of digits to the right of the decimal point, for example reducing 1.356 to 1.3. Because truncation discards data rather than transforming it reversibly, the removed portion cannot be recovered from the truncated result alone; how any specific truncation implementation affects downstream systems or compliance scope depends on the exact implementation and validation, not on the label 'truncation' by itself.

Why it matters

Truncation matters because it permanently removes part of a data value rather than transforming it in a reversible way. In the general sense established by the evidence, truncation shortens a number by dropping digits, such as reducing 1.356 to 1.3. Once those digits are discarded, the removed portion cannot be recovered from the truncated result alone. This irreversibility is what distinguishes truncation from methods that transform data in a way that can be reversed with a key or lookup.

Because the removed portion is genuinely gone, truncation reduces the amount of information retained in a stored value. However, the effect of any specific truncation implementation on downstream systems or on compliance scope depends on the exact implementation and validation, not on the label 'truncation' by itself. Two systems that both describe themselves as using truncation may retain different portions of a value and therefore carry different risk profiles. Readers should evaluate what data a given implementation actually keeps and discards rather than relying on the term alone.

Truncation should not be assumed to be equivalent to encryption, tokenization, masking, or hashing. These are distinct operations that reduce or transform data in different ways and have different reversibility characteristics. Treating them as interchangeable can lead to incorrect assumptions about what data remains recoverable and how a control affects the systems that handle it.

Who it's relevant to

Data Protection Engineers
Engineers designing systems that shorten or reduce stored data values need to understand that truncation permanently discards the removed portion and does not transform data reversibly. When choosing among data-reduction approaches, they should assess what a specific truncation implementation retains and discards rather than assuming a fixed behavior from the term, and should not treat truncation as interchangeable with encryption, tokenization, masking, or hashing.
Software and Computer Science Practitioners
Developers working with numeric values should recognize truncation as limiting the number of digits to the right of the decimal point, for example reducing 1.356 to 1.3. Because the dropped digits cannot be recovered from the truncated result, practitioners should account for the irreversible loss of precision when it affects calculations or downstream processing.
Compliance and Validation Reviewers
Reviewers evaluating controls that rely on truncation should confirm the exact implementation and its validation rather than accepting the label alone, since how a specific truncation affects downstream systems or compliance scope depends on implementation details, not the term itself.

Inside Truncation

Truncation defined
A method of permanently removing a segment of the Primary Account Number (PAN) so that only a portion remains, rendering the removed digits irrecoverable from the truncated value. It is distinct from masking, which hides digits for display while the full PAN may still be stored elsewhere.
Retained digits
Truncation typically preserves only a limited portion of the PAN (for example, a subset of leading and/or trailing digits). The specific number and position of digits that may be retained is governed by the current PCI DSS requirements, and practitioners should confirm allowances against the published standard rather than assuming a fixed format.
Irreversibility
Because truncation discards the removed digits entirely, the original full PAN cannot be reconstructed from the truncated value alone. This differs from encryption and tokenization, where the original PAN may be recoverable through keys, a token vault, or a mapping process.
Relationship to scope
Truncated data that meets the standard's criteria and cannot be used to reconstruct the PAN may fall outside cardholder data protection obligations. Whether truncation reduces PCI DSS scope depends on the implementation and validation, not on the label alone.
Data element applicability
Truncation applies to the PAN as an element of cardholder data. It does not authorize retention of sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, PINs and PIN blocks), which must not be stored after authorization even when transformed.

Common questions

Answers to the questions practitioners most commonly ask about Truncation.

Is truncation the same as tokenization or encryption?
No. Truncation permanently removes a portion of the PAN so the removed digits are not retained anywhere, making the operation irreversible. Encryption transforms the full PAN into ciphertext that can be recovered with the appropriate key, and tokenization substitutes the PAN with a surrogate value that can typically be mapped back to the original through a token vault or equivalent process. Truncation, encryption, tokenization, masking, and hashing transform data differently, and their effect on PCI DSS scope depends on how each is implemented and validated, not on the label applied to it.
If I truncate the PAN, does that automatically remove that system from PCI DSS scope?
Not automatically. The scope impact of truncation depends on the specific implementation, on whether any process can reassemble or recover the full PAN, and on how the environment is validated. A system that stores only truncated values may fall outside certain scope considerations, but that determination must be confirmed against the current published PCI DSS and the environment's actual data flows rather than assumed from the fact that truncation is used. You should verify scope conclusions against the current standard rather than a fixed requirement number, since numbering and wording differ between versions.
How many digits of the PAN can typically be displayed when applying truncation?
The specific number of digits that may be retained or displayed, and which positions are permitted, is defined by the current published PCI DSS and related card brand and network rules. Because requirement wording and details differ between versions, confirm the permitted digits and positions against the current standard rather than relying on a fixed figure.
Can truncated PAN data be combined with other stored data in a way that reintroduces risk?
Yes. If truncated PAN values are stored alongside other elements that could allow the full PAN to be reconstructed or correlated, the intended risk reduction of truncation may be undermined. Implementations should ensure that separately stored data cannot be combined to recover the original PAN, and this correlation risk should be assessed as part of validating the environment against the current standard.
How does truncation relate to masking when displaying the PAN?
Truncation permanently removes digits so the removed portion is not stored, while masking hides digits at display time even though the full value may still exist in storage. The two serve different purposes: truncation is a data-reduction control affecting what is retained, and masking governs what is shown to a viewer. Which digits may be displayed, and under what conditions, is defined by the current published PCI DSS, so confirm the applicable rules against that standard.
Is truncated data considered cardholder data for storage purposes?
Truncation reduces the stored PAN so that the full value is not retained, which changes how the remaining data is treated relative to a full PAN. How the resulting value is classified and what controls apply depends on the implementation and on the current published PCI DSS. Note that truncation applies to the PAN and does not by itself address sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, or PINs and PIN blocks, which must not be stored after authorization even when encrypted.

Common misconceptions

Truncation and masking are the same thing.
Masking hides digits from view while the full PAN may still be stored, whereas truncation permanently removes the digits so they cannot be recovered from the truncated value. They serve different purposes and have different effects on data protection.
Truncation is a form of encryption that can be reversed with the right key.
Truncation discards data permanently and has no key or reversal mechanism. Encryption and tokenization, unlike truncation, are designed so the original PAN can be recovered through keys or a mapping process, which is why their scope implications differ.
Using truncation automatically removes a system from PCI DSS scope.
Scope reduction depends on how truncation is implemented and validated, including whether the truncated value can be combined with other retained data to reconstruct the PAN. The label 'truncated' alone does not determine scope.

Best practices

Confirm the permitted number and position of retained PAN digits against the current published PCI DSS requirements rather than assuming a fixed format, since wording and numbering differ between versions.
Verify that truncated values cannot be combined with other data stored in your environment to reconstruct the full PAN, and treat any location that could enable reconstruction as in scope.
Do not rely on truncation to justify storing sensitive authentication data; full track data, CAV2/CVC2/CVV2/CID, and PIN data must not be stored after authorization regardless of any transformation.
Distinguish truncation from masking, encryption, tokenization, and hashing in data flow documentation, and record which technique is applied to each data element and why.
Validate scope impact through appropriate assessment rather than assuming the truncation label reduces obligations, and document the validation basis.
Review truncated data handling whenever the standard is updated or your data flows change, to ensure retained digit allowances and scope determinations remain accurate.