Category: Cardholder Data

Cardholder Data

Also known as: CHD, Cardholder Data (CHD)

Simply put

Cardholder data is the payment card information tied to a cardholder that is protected under the PCI DSS security requirements. At a minimum it includes the full card number, and it may also include certain related details printed on or associated with the card. Unlike sensitive authentication data, some cardholder data may be retained after a transaction is authorized, provided defined security controls are applied.

Formal definition

Cardholder Data (CHD) is a data classification defined by the PCI Security Standards Council that, at a minimum, consists of the full Primary Account Number (PAN). CHD may also comprise the full PAN in combination with other data elements such as cardholder name, expiration date, and service code. CHD is distinct from Sensitive Authentication Data (SAD)—which includes full track data, CAV2/CVC2/CVV2/CID values, and PINs/PIN blocks—in that certain CHD elements may be stored after authorization when protected under defined controls, whereas SAD must not be retained after authorization even if encrypted. The exact protection, storage, rendering, and scoping obligations for CHD are governed by PCI DSS; requirement numbering and wording differ across versions, so practitioners should confirm the applicable controls against the current published standard.

Why it matters

Cardholder data sits at the center of PCI DSS because it identifies the payment instrument and, if exposed, can be used to facilitate fraud. Understanding precisely what qualifies as CHD—at a minimum the full Primary Account Number (PAN), and potentially the PAN combined with elements such as cardholder name, expiration date, and service code—is the foundation for scoping any environment that stores, processes, or transmits payment card information. Systems that touch CHD generally fall within the cardholder data environment and become subject to PCI DSS controls, so misclassifying data can lead either to unprotected exposure or to unnecessarily broad and costly compliance obligations.

A critical distinction that drives day-to-day handling decisions is that certain CHD elements may be retained after a transaction is authorized, provided defined security controls are applied, whereas Sensitive Authentication Data (SAD)—including full track data, CAV2/CVC2/CVV2/CID values, and PINs or PIN blocks—must not be stored after authorization, even in encrypted form. Confusing these two categories is a common source of compliance failure: retaining SAD post-authorization is prohibited regardless of the encryption applied, while the storage of CHD is permitted only under the protections the standard requires.

Because the exact protection, storage, rendering, and scoping obligations for CHD are governed by PCI DSS—and because requirement numbering and wording differ across versions—teams should confirm applicable controls against the current published standard rather than relying on a fixed requirement reference. Treating CHD classification as a living, version-aware exercise helps reduce the risk of gaps that surface during assessment or after an incident.

Who it's relevant to

Compliance Officers and QSAs

Accurate CHD classification determines the boundaries of the cardholder data environment and the applicability of PCI DSS controls. Compliance teams use the CHD-versus-SAD distinction to verify that permitted CHD elements are protected under defined controls and that SAD is not retained after authorization. Because requirement numbering and wording differ across PCI DSS versions, these teams should confirm obligations against the current published standard.

Security Engineers and Architects

Engineers designing storage, processing, and transmission flows need to know which elements constitute CHD in order to apply appropriate controls and to choose among tokenization, encryption, truncation, masking, or hashing. Since the scope impact of these techniques depends on implementation and validation rather than the label, architects must design and document accordingly.

Merchants and Payment Processors

Organizations that accept or route payments must identify where CHD lives across their systems to establish PCI DSS scope. Recognizing that some CHD may be retained after authorization under defined controls—while SAD must not be—helps them design retention practices that support business needs without creating avoidable exposure.

Fraud and Risk Analysts

Analysts working with payment data benefit from understanding what constitutes CHD versus SAD, since the two categories carry different handling and retention rules. This distinction informs how data can be used and stored for downstream risk workflows while remaining consistent with PCI DSS obligations.

Inside CHD

Primary Account Number (PAN)

The payment card number that identifies the issuer and the cardholder account. The PAN is the defining element of cardholder data; when it is stored, processed, or transmitted, the associated environment is generally in PCI DSS scope. Other elements are considered cardholder data primarily when stored together with the PAN.

Cardholder Name

The name of the cardholder as it appears on the card. It is classified as cardholder data and may be stored under defined controls, but it is not sensitive authentication data.

Expiration Date

The date after which the card is no longer valid. It is a cardholder data element that may be stored under defined controls; it must not be confused with sensitive authentication data.

Service Code

The value that specifies acceptance conditions and limitations for a card. It is classified as cardholder data and may be stored under defined controls.

Distinction from Sensitive Authentication Data (SAD)

Cardholder data is a separate category from sensitive authentication data, which includes full track data, CAV2/CVC2/CVV2/CID, and PINs/PIN blocks. SAD must not be stored after authorization even when encrypted, whereas certain cardholder data elements may be stored under defined controls. Practitioners should confirm current storage and protection requirements against the published PCI DSS version, as wording and requirement numbering differ between versions.

Common questions

Answers to the questions practitioners most commonly ask about CHD.

Is CVV2/CVC2/CID part of cardholder data that I can store if I encrypt it?

No. CVV2, CVC2, CID, and similar card verification values are classified as sensitive authentication data (SAD), not cardholder data (CHD). SAD must not be stored after authorization, even when encrypted. Cardholder data elements such as the PAN, cardholder name, expiration date, and service code may be stored under defined PCI DSS controls, but the card verification codes may not. Confirm the current handling requirements against the published version of PCI DSS you are validating against, since wording and numbering differ between versions.

Are cardholder data and sensitive authentication data the same thing?

No. They are distinct categories under PCI DSS. Cardholder data (CHD) includes the primary account number (PAN), cardholder name, expiration date, and service code. Sensitive authentication data (SAD) includes full track data, card verification values (CAV2/CVC2/CVV2/CID), and PINs and PIN blocks. The key operational difference is storage: some CHD may be retained under defined controls, while SAD must not be stored after authorization, even in encrypted form. Treating the two as interchangeable can lead to prohibited retention of SAD.

Which cardholder data elements can we store, and what protection applies?

Under PCI DSS, CHD elements that may be stored under defined controls typically include the PAN, cardholder name, expiration date, and service code. Where the PAN is stored, it must be rendered unreadable using an approved method and protected according to the applicable requirements. Note that storability of an element and the required protection depend on the current published standard and your validated implementation, so confirm the specific requirements and their current wording rather than relying on a fixed reference.

Does masking or truncating the PAN take our stored data out of PCI DSS scope for that field?

Not automatically. Truncation, masking, and hashing transform PAN data in different ways, and their effect on scope depends on the specific implementation and how it is validated, not on the label used. Truncation removes digits so the full PAN is not retained, while masking controls display without necessarily changing what is stored. Whether a given approach reduces scope for that data element should be assessed against the current standard and confirmed through validation rather than assumed.

How does tokenizing the PAN differ from encrypting it when handling cardholder data?

Tokenization substitutes the PAN with a surrogate value (token), while encryption transforms the PAN into ciphertext that can be reversed with the appropriate key. These are different mechanisms with different scope implications. Whether either reduces or removes cardholder data from a given environment depends on the implementation and how it is validated, not on the term alone. Assess each approach against the current standard and validation requirements rather than assuming a scope outcome from the label.

What should we do if we discover sensitive authentication data stored after authorization?

SAD must not be retained after authorization, even when encrypted, so its presence in stored data typically indicates a control gap that needs remediation. Practical steps generally include identifying how and where the SAD is being captured or retained, locating the storage points across systems and logs, securely eliminating the retained data, and correcting the underlying process so SAD is not persisted going forward. Handle these activities in line with your organization's procedures and the requirements of the current published PCI DSS version.

Common misconceptions

Cardholder data and sensitive authentication data are the same thing and follow the same storage rules.

They are distinct categories. Some cardholder data (such as PAN, cardholder name, expiration date, and service code) may be stored under defined controls, while sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, PINs/PIN blocks) must not be stored after authorization, even when encrypted.

Encrypting or tokenizing the PAN automatically removes a system from PCI DSS scope.

Tokenization, encryption, truncation, masking, and hashing transform data in different ways, and their effect on scope depends on implementation and validation rather than on the label alone. Scope determination should be confirmed against the current published standard and the specifics of the deployment.

Elements like cardholder name or expiration date are always in scope by themselves.

Cardholder name, expiration date, and service code are generally treated as cardholder data primarily when stored together with the PAN. The PAN is the element that most directly drives PCI DSS applicability.

Best practices

Inventory and data-flow map every location where the PAN is stored, processed, or transmitted, since the PAN is the primary driver of PCI DSS scope.

Never store sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, PINs/PIN blocks) after authorization, even in encrypted form.

Apply appropriate protection to stored cardholder data (PAN, cardholder name, expiration date, service code) using controls validated against the current published PCI DSS version rather than assuming fixed requirement numbers.

Minimize retention by storing only the cardholder data elements you have a defined business need to keep, and confirm the treatment of each element against the current standard.

Select data-reduction techniques deliberately, recognizing that tokenization, encryption, truncation, masking, and hashing differ in effect, and validate their impact on scope for your specific implementation.

Re-verify classification and storage rules whenever the PCI DSS version changes, since requirement wording and numbering vary between versions.