What Counts as Cardholder Data and Sensitive Authentication Data?

Not all information involved in a card payment is treated the same way.

That distinction matters because payment data serves different purposes. Some information identifies the payment account or cardholder. Other information authenticates the cardholder or authorizes the transaction. Treating those data types as interchangeable can lead to incorrect assumptions about what your organization handles and how your payment environment should be assessed.

PCI DSS separates these into two categories: Cardholder Data (CHD) and Sensitive Authentication Data (SAD). Together, PCI SSC refers to them as account data.

Understanding the difference is a practical starting point for mapping payment data, identifying where it exists, and making informed decisions about PCI DSS scope.

» Learn how to fortify your PCI DSS security strategy for long-term protection

What are Cardholder Data and Sensitive Authentication Data?

Cardholder Data and Sensitive Authentication Data are two distinct categories of payment account data.

PCI SSC defines Cardholder Data (CHD) as consisting, at minimum, of the full Primary Account Number (PAN). CHD may also appear as the full PAN together with the cardholder name, expiration date, and/or service code.

Sensitive Authentication Data (SAD) is security-related information used to authenticate cardholders and/or authorize payment card transactions. It includes full track data, card verification codes, PINs, and PIN blocks.

A useful mental model is:

• CHD relates primarily to the payment account or cardholder.
• SAD relates primarily to authentication and authorization.

That is a teaching shorthand rather than a replacement for PCI SSC's formal definitions, but it helps explain why the categories are separated.

Both can pass through the same payment flow. For example, an application may receive account information and authentication information during a transaction. Their proximity does not make them the same type of data, and their handling expectations differ.

What typically counts as Cardholder Data?

This distinction is worth getting right. CHD is often described loosely as "everything printed on the card." That explanation is easy to remember, but it is not precise enough for PCI DSS scoping or data mapping.

PAN as the anchor of Cardholder Data

The PAN is the full payment card account number. From a classification perspective, it is the starting point for determining whether you are dealing with CHD.

Organizations may encounter PANs in obvious locations, such as payment applications or transaction systems. But they can also appear in less obvious places: application logs, exports, troubleshooting records, screenshots, scanned forms, or operational workflows.

The format does not make the data stop being CHD. PCI SSC has specifically addressed images and forms containing CHD and confirmed that PCI DSS does not simply stop applying because payment information has been captured as an image or on a form.

That is why payment-data discovery needs to look beyond the primary checkout or processing application.

Other information associated with the PAN

Cardholder Data may also include:

• Cardholder name
• Expiration date
• Service code

The important nuance is their relationship to the PAN.

The service code also deserves special attention because its name can be confusing. It is a three- or four-digit value within magnetic-stripe track data that indicates service attributes or usage restrictions. It is not the same thing as a CVV, CVC, CID, or other card verification value.

Those verification values belong to a different category: Sensitive Authentication Data.

Achieve PCI DSS Compliance Faster with GRSee

Leverage Grsee’s penetration testing and training to protect cardholder data and streamline your PCI DSS efforts.

PCI DSS-compliant penetration testing

Targeted training to boost compliance

Simplified audit preparation and risk reduction

Learn More

What typically counts as Sensitive Authentication Data?

PCI SSC identifies the main SAD categories as:

• Full track data from the magnetic stripe, or equivalent data on a chip
• Card verification codes or values
• PINs and PIN blocks

SAD is separated from ordinary account-identification information because it performs a security function in the payment process. It helps establish that the card, payment credential, or cardholder is legitimate during authentication or authorization.

Full track data or equivalent chip data

Payment cards can contain track data that provides information used during transaction processing and authentication.

PCI SSC classifies the full contents of track data, or its chip equivalent, as Sensitive Authentication Data.

This distinction matters because individual CHD elements can exist within that track information. PAN, cardholder name, expiration date, and service code can have legitimate business uses as separate data elements, but retaining the full track is different.

The practical lesson is not to classify a dataset solely by noticing one familiar field. You need to understand what the complete data represents and how it is being used.

Card verification codes and values

The three- or four-digit security value printed on a payment card is SAD.

Depending on the payment brand, terminology includes CVV2, CVC2, CID, CAV2, and CVN2, among other names. PCI SSC identifies these card verification codes as Sensitive Authentication Data because they are used in transaction authorization, particularly in card-not-present transactions.

This is one of the most useful distinctions to remember:

A service code is associated with Cardholder Data when present with PAN. A card verification code is Sensitive Authentication Data.

The similar terminology does not mean the values serve the same purpose.

PINs and PIN blocks

PINs and PIN blocks also fall under Sensitive Authentication Data.

Their purpose is authentication, not simple account identification. During authorization, PIN information can be validated to help establish that the person using the card is authorized.

PCI DSS consequently treats SAD differently from CHD after a transaction has been authorized. Requirement 3.3.1 prohibits retaining SAD after authorization, even if it is encrypted. Specific applicability provisions apply to issuers and organizations supporting issuing services where SAD is needed for a legitimate issuing business need, so this rule should not be reduced to an exception-free statement covering every entity in every context.

For most readers, the key point is simpler: authentication data is not just another field to store alongside the account record.

Cardholder Data vs. Sensitive Authentication Data: Why does the difference matter?

CHD and SAD serve different purposes, so accurately identifying them affects how an organization understands and protects its payment environment. At a high level:

The difference is not academic. If you misclassify the data your systems handle, you may also misunderstand where payment data exists and what needs further review. For example, an organization might carefully track PAN in its main payments database but overlook payment data that has found its way into:

• Application or infrastructure logs
• Support tickets
• Screenshots or scanned forms
• Debugging output
• Exported spreadsheets or reports
• Monitoring systems
• Internal integrations
• Third-party systems

SAD presents an additional concern because PCI DSS restricts retaining it after authorization. A system that unexpectedly records card verification values or other SAD can therefore create a materially different problem than one that holds permitted CHD for a legitimate business purpose.

Classification also affects PCI DSS scoping, but it is not a scope determination method on its own.

Knowing which data you have is therefore one input into understanding the CDE. You still need to look at systems, connectivity, processes, people, and the actual architecture around those data flows.

Data Network Security Protection

Stay secure and compliant with expert guidance that protects your network and prepares you for evolving threats.

Contact Us

Map payment data before making PCI DSS scope assumptions

Knowing the definitions is only the first step. To understand your real exposure, trace where payment data enters your environment, where it travels, and where it may persist.

A diagram that shows only the payment processor and the main application may not tell the full story. Modern payment environments can involve APIs, browser components, cloud services, third parties, internal tools, observability platforms, and operational processes.

Where does the data enter?

Start with every place where payment account information can enter your environment.

Depending on your model, that could include:

• Checkout or payment pages
• Mobile or web applications
• APIs
• Payment terminals
• Third-party payment components
• Customer-support workflows
• Back-office processes

Do not assume that outsourcing payment processing automatically means no payment information touches your systems. What matters is how the implementation actually works.

Where can the data travel or persist?

Follow the data beyond its original entry point.

Look at the application path and supporting systems. Ask whether payment data can be written to:

• Databases
• Application and infrastructure logs
• Message queues
• Analytics platforms
• Error-tracking tools
• Support platforms
• File exports
• Screenshots or recordings
• Backups
• Third-party integrations

This exercise often matters more than memorizing PCI DSS terms. You cannot accurately classify data you don't know you have.

Which category does each data element belong to?

Once the flow is visible, classify the payment information you find. Identify:

• Where full PAN appears.
• Which associated CHD elements accompany it.
• Whether any SAD passes through the system.
• Whether SAD is being retained anywhere it should not be.
• Which systems, people, processes, and connections to consider when evaluating the CDE.

If classification is unclear, investigate rather than relying on assumptions based on system names or intended architecture. An application described internally as "out of payment scope" may still warrant review if actual data flows tell a different story.

» Build a strong payment security foundation before your startup begins handling cardholder data.

Accurately classify payment data with GRSee

Understanding the definitions of CHD and SAD is straightforward. Applying them across a real payment architecture can be more involved, especially when payment flows cross cloud infrastructure, APIs, third-party processors, operational systems, and internal support processes.

GRSee works with organizations to understand their cardholder-data flows and use that information to support PCI DSS scope determination. For SAQ-based environments, our PCI DSS SAQ process includes analyzing how the organization handles cardholder data, identifying the appropriate SAQ type, and identifying legitimate opportunities to reduce the CDE footprint.

For organizations requiring a broader PCI DSS assessment, our PCI services also cover scope and data-flow analysis, gap assessment, remediation planning, readiness, and assessment activities.

The goal is to start with what your environment actually does (not what an architecture diagram or assumption says it does) and build the PCI DSS approach from there.

If you are unsure where CHD or SAD exists in your systems, the next useful step is to map your payment-data flow and determine the PCI DSS scope and assessment approach that applies to your environment.

Ensure PCI DSS Compliance

Stay ahead of regulatory requirements with expert PCI DSS penetration testing and reporting. Secure your cardholder data environment today.

Contact Our Experts