What Is Cardholder Data Under PCI DSS?

The two categories at a glance

PCI DSS organizes payment data into two buckets. The first is cardholder data, which includes the primary account number and, when stored with it, the cardholder name, expiration date, and service code. The second is sensitive authentication data, which includes the full track data from the magnetic stripe or chip, the card verification value, and the PIN.

The defining rule is simple to state and critical to follow: cardholder data may be stored if it is protected, but sensitive authentication data must never be stored after authorization, even in encrypted form. Everything else about handling payment data flows from this distinction, which is why understanding it precisely is so important.

The primary account number (PAN)

The primary account number, or PAN, is the long number printed or embossed on a payment card — typically sixteen digits. It is the single most important data element in all of PCI DSS, because it uniquely identifies the cardholder account and is the linchpin that makes the rest of the data sensitive. Wherever the PAN is present, PCI DSS scope follows.

When the PAN is stored, it must be rendered unreadable through approved methods such as strong encryption, truncation, tokenization, or one-way hashing. The presence of the PAN is what pulls a system into scope in the first place, so controlling where it lives — and removing it where possible — is the most powerful lever you have over the size of your compliance effort.

Other cardholder data elements

Alongside the PAN, three other elements are considered cardholder data when they are stored together with it: the cardholder name, the card expiration date, and the service code (a value encoded on the card that defines acceptance and usage rules). These elements are less sensitive than the PAN on their own, but in combination with it they form the cardholder data set that the standard protects.

These elements may be stored, subject to PCI DSS protections, which is why they are grouped separately from sensitive authentication data. Still, the guiding principle of data minimization applies: you should store them only if you have a genuine business need, since every additional piece of retained data is something more to secure and account for.

Sensitive authentication data (SAD)

Sensitive authentication data is the information used to authenticate a cardholder at the moment of a transaction. It comprises the full magnetic-stripe or equivalent chip track data, the card verification value (variously called CVV, CVC, CID, or CAV2 depending on the brand), and the personal identification number or PIN block.

This data is extraordinarily valuable to criminals because it enables fraudulent transactions. For that reason, PCI DSS forbids storing it after a transaction has been authorized — full stop. It may be used transiently during authorization, but once authorization completes it must be securely deleted. There is no compliant way to retain it, no matter how strong your encryption.

The CVV question: can you store it?

The most frequently asked question in this whole area is whether a business can store the three- or four-digit card verification value to make future charges smoother. The answer is an unambiguous no. The CVV is sensitive authentication data, and storing it after authorization is one of the clearest and most serious PCI DSS violations there is.

This catches many businesses by surprise, particularly those building recurring-billing or one-click-checkout features. The compliant pattern is to use the PAN (suitably protected or tokenized) for subsequent charges and to rely on the payment brands' rules, which do not require the CVV for recurring transactions. Storing the CVV to avoid re-prompting is never acceptable.

How rendering the PAN unreadable works

When you do need to store the PAN, PCI DSS requires it to be unreadable to anyone who should not see it. The approved approaches each work differently: strong encryption scrambles the data so it can only be read with the key; truncation permanently removes a portion of the digits; tokenization swaps the PAN for a meaningless surrogate value; and one-way hashing converts it irreversibly.

Each method has trade-offs in usability and scope reduction. Tokenization is especially popular because the token can be used in your systems while the real PAN is held by a specialized provider, removing the sensitive data from your environment entirely. Choosing the right method is a key design decision in any compliant architecture.

Why these definitions drive scope

The reason these definitions matter so much is that they determine what is in scope. Any system component that stores, processes, or transmits the PAN — or sensitive authentication data during authorization — falls within your cardholder data environment and must meet PCI DSS requirements. Systems that never touch this data can be excluded, provided they are properly segmented.

This is why data minimization is the most effective scope-reduction strategy available. The less cardholder data you store, the fewer systems are in scope, the smaller your environment, and the cheaper and faster your compliance becomes. Knowing exactly what counts as protected data is the prerequisite for shrinking your footprint intelligently.

It also explains why so many compliant architectures push card data to specialized providers. If the PAN never enters your systems in usable form, the systems that would otherwise be in scope simply are not, because the protected data the standard cares about is not present. The definitions are therefore not academic; they are the rules that decide where your obligations begin and end.

Common mistakes with cardholder data

Several recurring mistakes trip businesses up. The most damaging is inadvertently storing the CVV — sometimes in application logs, database backups, or support tickets where card details were pasted. Another is retaining full PANs in places that were never meant to hold them, such as spreadsheets, email, or analytics systems. A third is failing to truncate or mask the PAN when it is displayed, exposing the full number to staff who do not need it.

These problems often arise not from bad intent but from a lack of awareness about where card data flows and accumulates. Regularly scanning your environment for unexpected stored cardholder data, and minimizing what you collect, prevents these mistakes from quietly building up into compliance failures.

How ISpectra helps you handle cardholder data correctly

Correctly classifying, minimizing, and protecting cardholder data is foundational to pci dss certification, and small missteps here cause outsized problems later. ISpectra Technologies helps businesses map exactly where cardholder data lives, eliminate prohibited storage of sensitive authentication data, and apply the right combination of encryption, truncation, and tokenization to shrink scope.

With free vulnerability assessment and penetration testing to surface hidden data-handling issues and a 10% discount when PCI DSS is bundled with SOC 2 or ISO 27001, ISpectra ensures your treatment of cardholder data is both compliant and as lightweight as your business model allows.