What Is Cardholder Data? PAN, PCI DSS, and Protection Rules

Cardholder data is any information tied to a payment card that can identify the account or the person who holds it, with the Primary Account Number at its center. When a PAN is present, everything stored or transmitted alongside it — the cardholder’s name, the expiration date, the service code — becomes regulated data under the Payment Card Industry Data Security Standard (PCI DSS). Businesses that store, process, or transmit any of it are bound by specific rules on how it must be protected, and the current standard, PCI DSS v4.0.1, brought a set of tightened requirements that became mandatory on March 31, 2025.¹

The Primary Account Number Is the Anchor

The Primary Account Number, or PAN, is the long number printed on the front of a payment card. Under ISO/IEC 7812, a PAN can run from 10 to 19 digits, though most cards you’ll see use 15 digits (American Express) or 16 (Visa, Mastercard, Discover).² The first several digits identify the issuing financial institution — historically six, though Visa and others have expanded to eight for new cards.³ The last digit is a Luhn check digit that catches typos before a transaction reaches the bank.

Everything else in the cardholder data world hinges on this number. A customer’s name sitting alone in a database is just personal information. Store that same name next to a PAN and it becomes cardholder data subject to strict handling rules. That is why businesses spend so much effort finding every place a PAN might live: a forgotten spreadsheet or an old email backup can pull an entire system into PCI DSS scope.

What Else Counts as Cardholder Data

Several other fields become regulated when they appear alongside a PAN:

The cardholder name as it appears on the card.
The expiration date.
The service code, a three- or four-digit value on the magnetic stripe that tells processing systems what the card can do — international use, ATM access, or narrower conditions.

On their own, none of these are particularly sensitive. An expiration date without an account number is useless to a fraudster. Paired with a PAN, they form a profile that could authorize a transaction. PCI DSS allows these elements to be stored after a transaction is authorized, but only with proper protections and only for as long as a legitimate business need exists.⁴

Sensitive Authentication Data Is a Separate Category

Sensitive Authentication Data, or SAD, is a narrower and more dangerous set of fields. It covers:

Full magnetic stripe or chip data, often called track data, which contains the complete encoded account details from the stripe or EMV chip.
Card verification codes: the three-digit CVV2/CVC2 on the back of Visa, Mastercard, and Discover cards, or the four-digit CID on the front of American Express cards. These prove the person initiating the transaction has the physical card.
PINs and PIN blocks used to authenticate debit and ATM transactions.

The line that separates SAD from the rest of cardholder data is absolute: SAD must never be stored after a transaction is authorized, even in encrypted form.⁵ The rule applies even in environments where no PAN is present. A business may have a valid reason to keep a PAN on file for recurring billing, but there is no scenario in which keeping a CVV2 or full track data after authorization is acceptable.

The reasoning is practical. An attacker who breaches a system holding PANs and names gets account numbers, which are damaging but limited without verification codes. If the same system also held CVV2 codes and track data, that attacker could clone cards or push through card-not-present purchases at scale. Destroying SAD once authorization completes removes the most potent fraud tools from what a breach can produce.

How Stored Cardholder Data Must Be Protected

The elements that may be retained — PANs, cardholder names, expiration dates, and service codes — require specific protections. The ones that trip up businesses most often involve how PAN data is displayed, how it’s stored, and whether it needs to be stored at all.

Masking the PAN on Display

Whenever a PAN appears on a screen, receipt, or report, it must be masked so no more than the first six and last four digits are visible. Middle digits get replaced with asterisks or similar characters, and only personnel with a documented business need should ever see the full number.⁴ Some card brands enforce stricter masking on point-of-sale receipts, so the PCI DSS rule is a floor, not a ceiling.

Encryption and Tokenization

Stored PANs have to be rendered unreadable everywhere they live. The two most common approaches are strong encryption and tokenization. Encryption scrambles the PAN using a cryptographic key; without the key, the data is useless. Tokenization replaces the PAN with a random surrogate value that has no mathematical relationship to the original. The real PAN sits in a secure, centralized token vault, and the merchant’s own systems only ever touch the token.⁶

Tokenization is particularly useful for recurring transactions. Rather than storing a customer’s PAN to charge them each month, the merchant stores a token. If the database is breached, the attacker gets tokens that are worthless outside the tokenization system that issued them. Properly implemented, tokenization can meaningfully reduce the number of systems that fall inside PCI DSS scope, though it does not eliminate the need for compliance.⁶

Not Storing It in the First Place

The simplest protection is to not store cardholder data at all. PCI DSS requires that payment card data not be stored unless it’s genuinely necessary for business, legal, or regulatory purposes.⁴ Every business handling card data should keep a written retention policy that defines what is kept, where it lives, and when it gets deleted. The fewer places a PAN sits, the smaller the attack surface and the lighter the compliance burden.

How Cardholder Data Must Be Destroyed

When retention periods run out, cardholder data has to be destroyed in a way that prevents reconstruction. PCI DSS specifies different methods by medium.

For paper — printouts, receipts, handwritten notes containing PANs — acceptable methods include cross-cut shredding, incineration, and pulping. Strip-cut shredders are not sufficient because the strips can be reassembled. Before destruction, paper records have to be held in secure storage to prevent unauthorized access.⁷

For electronic media — hard drives, USB drives, backup tapes — the data must be rendered unrecoverable or the media itself physically destroyed. Acceptable methods include secure wiping consistent with industry standards, degaussing, and physical destruction like grinding or shredding.⁷ NIST Special Publication 800-88 lays out detailed media sanitization guidance and is widely referenced in the industry. For modern solid-state drives, cryptographic erasure — securely deleting the encryption key so the remaining data is unreadable ciphertext — is an increasingly common approach.⁸

Who Has to Follow These Rules

PCI DSS applies to every organization that stores, processes, or transmits cardholder data, regardless of size or transaction volume.⁹ A single-location coffee shop and a multinational retailer are both merchants under the standard; what differs is how they validate compliance. Card brands assign merchants to one of four levels based on annual transaction volume, with Level 1 (over 6 million transactions per year) requiring an annual on-site assessment by a Qualified Security Assessor and smaller merchants typically validating through a Self-Assessment Questionnaire. Exact thresholds vary slightly between card brands, so merchants should confirm their level with their acquiring bank.¹⁰

Companies that handle cardholder data on behalf of other businesses — payment gateways, hosting providers, managed security firms — are service providers under PCI DSS. They have their own compliance validation requirements and must be able to demonstrate their status to the merchants and banks that rely on them.

PCI DSS itself is not a federal law. It’s a set of technical and operational requirements maintained by the PCI Security Standards Council, founded by Visa, Mastercard, American Express, Discover, and JCB International.⁹ Enforcement runs through the contractual agreements merchants sign with acquiring banks and processors when they begin accepting cards.

What Happens If a Business Doesn’t Comply

Because PCI DSS is contractual, penalties flow through card brands and acquiring banks rather than a government regulator. Card brands can impose monthly fines on acquiring banks, which then pass those costs to the non-compliant merchant. The exact amounts aren’t publicly standardized. Industry sources commonly cite a range of $5,000 to $100,000 per month depending on compliance level and how long the violation persists, but those figures come from intermediaries rather than official card brand publications.

The more serious consequence is losing the ability to accept card payments at all. For most businesses, that is existential. Large-scale breaches have also produced lawsuits in which courts held that companies had a duty of care to follow PCI DSS, with settlements reaching tens of millions of dollars in restitution to banks and affected consumers.

Federal agencies can enter the picture when a security failure also violates a federal statute. The Federal Trade Commission uses Section 5 of the FTC Act to act against companies whose lapses qualify as unfair or deceptive practices.¹¹ Financial institutions covered by the Gramm-Leach-Bliley Act face an added duty: the FTC’s Safeguards Rule requires them to report breaches affecting 500 or more consumers within 30 days of discovery.¹² Every state also has its own breach notification law, so a single incident involving cardholder data can trigger obligations under PCI DSS, the federal Safeguards Rule where applicable, and the notification statutes of each state where affected consumers live.

1
PCI Security Standards Council. Now is the Time for Organizations to Adopt the Future-Dated Requirements of PCI DSS v4.x
2
International Organization for Standardization. Changes to the Issuer Identification Number (IIN) Standard
3
Visa. 8-Digit BIN Industry Change
4
PCI Security Standards Council. PCI Data Storage Dos and Donts
5
PCI Security Standards Council. Frequently Asked Question – Sensitive Authentication Data After Authorization
6
PCI Security Standards Council. Information Supplement – PCI DSS Tokenization Guidelines
7
Western University. Payment Card Industry Data Security Standard Requirements and Testing Procedures Version 4.0
8
NIST. Guidelines for Media Sanitization – NIST Special Publication 800-88 Revision 1
9
PCI Security Standards Council. PCI Security Standards Council – Standards Overview
10
PCI Security Standards Council. Merchant Resources
11
Federal Trade Commission. Privacy and Security Enforcement
12
Federal Trade Commission. Safeguards Rule Notification Requirement Now in Effect