Skip to main content
Commerce Security Authority
Category: Cardholder Data

Cardholder Name

Also known as: Name on Card, Cardholder
Simply put

The cardholder name is the name printed on a credit or debit card that identifies the person who owns the card and is authorized to use it. It is commonly entered during online checkout and located on the front of the card. It is one of the pieces of information used to identify whom a card belongs to.

Formal definition

The cardholder name is a data element identifying the individual to whom a payment card is issued, typically printed on the front of the card. Under PCI DSS terminology it is classified as cardholder data rather than sensitive authentication data, distinguishing it from full track data, card verification values (CAV2/CVC2/CVV2/CID), and PINs/PIN blocks, which must not be retained after authorization. As cardholder data, the cardholder name may be stored under defined security controls; its precise handling, protection, and effect on assessment scope should be confirmed against the current published PCI DSS standard, as requirement wording and numbering vary by version.

Why it matters

The cardholder name is one of the data elements used to identify whom a payment card belongs to and who is authorized to use it. Because it is classified under PCI DSS terminology as cardholder data rather than sensitive authentication data, it sits in a different category from full track data, card verification values (CAV2/CVC2/CVV2/CID), and PINs or PIN blocks, which must not be retained after authorization. Cardholder data such as the name may be stored under defined security controls, but that permission comes with responsibility: any system that stores, processes, or transmits it may fall within assessment scope and require appropriate protection.

For organizations handling payments, treating the cardholder name correctly matters because misclassifying data elements can lead to gaps in controls or to over-retention of information that should be minimized. While the cardholder name is not sensitive authentication data, it is still personally identifying and is commonly combined with other cardholder data during checkout. How it must be protected, and whether storing it affects scope, depends on the implementation and on the current published PCI DSS standard rather than on the label alone.

Because requirement wording and numbering vary between PCI DSS versions, teams should confirm the specific handling and protection obligations for the cardholder name against the current published standard rather than assuming a fixed requirement. This avoids applying outdated guidance and helps ensure that data classification decisions remain aligned with the applicable version.

Who it's relevant to

Compliance Officers
Compliance teams need to classify the cardholder name correctly as cardholder data, not sensitive authentication data, and confirm its storage and protection requirements against the current published PCI DSS standard. Because requirement wording and numbering vary by version, they should avoid relying on fixed requirement numbers when documenting how the name is handled.
Security Engineers
Engineers designing systems that capture the cardholder name at checkout or store it afterward should apply appropriate controls for cardholder data and understand that its presence may bring systems into assessment scope. The effect on scope depends on implementation and validation rather than on the data label alone.
Merchant Risk and Payment Operations Teams
Teams handling online payments regularly process the cardholder name as one of the elements used to identify whom a card belongs to. They should ensure it is treated as cardholder data under defined controls and distinguished from sensitive authentication data, which must not be retained after authorization.

Inside Cardholder Name

Classification as cardholder data
The cardholder name is one of the four data elements PCI DSS defines as cardholder data, alongside the primary account number (PAN), expiration date, and service code. It is distinct from sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks.
Storage permissibility
Unlike sensitive authentication data, which must not be retained after authorization even when encrypted, the cardholder name may be stored after authorization when protected under the applicable PCI DSS controls for cardholder data.
Relationship to the PAN
The cardholder name is a separate element from the PAN. Protection obligations for the name are generally tied to whether it is stored, processed, or transmitted together with the PAN and to how the overall cardholder data environment is scoped and validated.
Data element on the payment card
The cardholder name typically appears as printed or embossed information on a payment card and may also be captured within track data during a card-present transaction, though the sensitive authentication portions of track data are subject to stricter no-storage rules.

Common questions

Answers to the questions practitioners most commonly ask about Cardholder Name.

Is the cardholder name considered sensitive authentication data that must be deleted after authorization?
No. The cardholder name is classified as cardholder data, not sensitive authentication data. Sensitive authentication data refers to full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks, which must not be stored after authorization even if encrypted. The cardholder name, like the PAN, expiration date, and service code, may be stored under defined controls when there is a documented business need, provided it is protected according to the applicable PCI DSS requirements.
Does the cardholder name need to be masked or truncated the same way the PAN does?
Not identically. The specific display, masking, and truncation expectations that apply to the PAN are defined for the PAN itself and should be confirmed against the current published PCI DSS. The cardholder name is a separate data element within cardholder data, and how it must be protected depends on your implementation, the storage and display context, and validation, rather than on applying PAN-specific rules by default. Confirm the applicable requirements in the version of the standard you are validating against.
Where does the cardholder name typically appear in our environment, and how does that affect scope?
The cardholder name can appear in authorization messages, settlement files, receipts, customer records, logs, and support systems. Any system component that stores, processes, or transmits it as part of cardholder data may be in scope for PCI DSS. Reducing where the name is retained, and confirming it is not written to unexpected locations such as debug logs, helps limit the number of components you must assess. Validate scope against your actual data flows rather than assumptions.
Can we retain the cardholder name for customer service or reconciliation purposes?
Retention should be tied to a documented business need and governed by your data retention and disposal policies. As cardholder data, the name may be stored under defined controls, but storing it without a justified purpose increases scope and exposure. Define why it is retained, for how long, and how it is securely disposed of when no longer needed, and confirm these practices against the current published standard.
How should the cardholder name be handled in application logs and debug output?
Cardholder data, including the name, should not be written to logs unless there is a defined need and appropriate protection. Because logs are often overlooked, review application, transaction, and error logging to confirm the cardholder name is not inadvertently captured. Where it must appear, apply the access, protection, and retention controls that apply to cardholder data in your environment.
Does tokenizing or encrypting the PAN also address protection of the cardholder name?
Not automatically. Tokenization, encryption, truncation, masking, and hashing transform data differently, and controls applied to the PAN do not necessarily cover the cardholder name unless they are explicitly implemented for that element. Determine separately how the cardholder name is protected in storage, transmission, and display, and confirm that the chosen approach is implemented and validated rather than assumed based on how the PAN is handled.

Common misconceptions

The cardholder name is sensitive authentication data and can never be stored.
The cardholder name is classified as cardholder data, not sensitive authentication data. It may be stored after authorization when protected under the applicable PCI DSS controls. The prohibition on post-authorization storage applies to sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks.
Because a name is not the PAN, it falls entirely outside PCI DSS obligations.
The cardholder name is defined as cardholder data under PCI DSS and is subject to protection controls, particularly when stored, processed, or transmitted in a way that places it within the cardholder data environment. Whether it affects scope depends on the specific implementation and validation, not on the label alone.
Masking or truncating the PAN automatically resolves all obligations for the associated cardholder name.
Masking, truncation, tokenization, and encryption transform different data elements in different ways and are typically applied to the PAN. The cardholder name is a separate element, and its handling requirements depend on how it is stored and secured, so obligations for the name should be assessed independently against the current published standard.

Best practices

Classify the cardholder name explicitly as cardholder data in your data inventory, keeping it distinct from sensitive authentication data that must not be stored after authorization.
Apply the PCI DSS controls appropriate to stored cardholder data to any location where the name is retained, and confirm the specific requirements against the current published version of the standard rather than assuming fixed requirement numbers.
Identify every place the cardholder name is stored, processed, or transmitted, and assess how it affects cardholder data environment scope based on your actual implementation and validation.
Avoid retaining the cardholder name where it is not needed for a defined business purpose, reducing the footprint of data subject to protection controls.
Ensure processes that handle full track data separate and discard the sensitive authentication portions after authorization, while treating the cardholder name under the storage rules for cardholder data.
Coordinate protection of the cardholder name with protection of the associated PAN, recognizing that the two are distinct elements with different handling considerations.