Cardholder Data (CHD): Definition & PCI DSS Rules

What cardholder data actually means

Cardholder data — usually shortened to CHD — is the term PCI DSS uses for the payment card information you're allowed to store, with conditions. It covers four specific data elements:

• The Primary Account Number (PAN) — the long number on the front of the card, usually 16 digits.
• The cardholder name.
• The expiry date.
• The service code — a 3-digit code in the magnetic stripe that tells the issuer how the card can be used.

The PAN is the load-bearing piece. If you store, process or transmit a PAN anywhere in your business, PCI DSS applies to that system and everything connected to it. The other three elements are only treated as cardholder data when they're stored alongside the PAN. On their own, a name or an expiry date isn't enough to require PCI controls.

CHD vs SAD: the difference that trips people up

PCI DSS splits payment card information into two buckets: cardholder data and sensitive authentication data (SAD). They're not the same thing, and the rules are very different.

SAD includes the full magnetic stripe contents, the CVV/CVC printed on the back of the card, and the PIN or PIN block. Under PCI DSS v4.0.1, SAD must never be stored after a transaction is authorised — full stop. No exceptions for "we'll just keep the CVV for refunds." You can hold SAD for the few seconds it takes to process an authorisation, then it has to go.

CHD is more forgiving. You're allowed to store the PAN if you protect it properly (encryption, tokenisation, truncation, or hashing — Requirement 3.5 of PCI DSS v4.0.1). You can store the cardholder name, expiry and service code without rendering them unreadable, but if they're in the same system as a stored PAN, they're in scope.

What PCI DSS v4.0.1 requires for CHD

PCI DSS v4.0.1 — the current version, with the March 2025 future-dated requirements now in force — sets out specific controls for any environment that touches cardholder data. The big ones:

Requirement 3: Protect stored CHD

Stored PAN must be rendered unreadable. The accepted methods are strong cryptography, tokenisation, truncation (showing only the first six and last four digits at most), or one-way hashing with a keyed function. Plain-text PAN in a database or log file is a finding waiting to happen.

Requirement 4: Protect CHD in transit

Any time PAN crosses an open or public network — including the public internet, wireless, and most third-party connections — it needs strong cryptography. TLS 1.2 or higher is the practical baseline; SSL and early TLS have been deprecated for years.

Requirement 9: Restrict physical access

If CHD lives on paper, USB sticks, backup tapes or hard drives, physical security applies. Locked cabinets, visitor logs, the lot.

Requirement 12: Policy and governance

You need a documented data retention and disposal policy. The principle: don't store CHD you don't need, and get rid of what you do store as soon as the business or legal reason for keeping it ends.

How CHD enters most contact centres

For phone payments, cardholder data normally arrives in one of three ways, and each carries a different scope footprint.

The traditional method is the agent typing the PAN into a payment screen while the caller reads it out. Everything in that path — the phone line, the call recording system, the agent's screen, the network behind it, sometimes the agent's memory — is handling cardholder data. That's a large in-scope environment and usually the most expensive to audit. We've written more about this trade-off in our piece on why traditional call recording creates PCI problems.

The second method is a payment link sent by SMS or email, where the caller pays on a webpage and the agent never hears the card details. That works for some flows but breaks others — particularly any payment that needs to complete on the call itself.

The third method is DTMF masking, which is what we build at Paytia. The caller keys their card number into their phone, the tones are intercepted and replaced before they reach the agent or the recording, and the PAN is routed straight to the payment processor. The agent stays on the call, but the cardholder data never enters their systems. That keeps the contact centre out of CHD scope entirely.

Keeping CHD out of scope

The single best way to reduce PCI cost and risk is to handle less cardholder data — or better, none at all. PCI DSS scope reduction has a few well-trodden techniques:

• Tokenisation — replacing the PAN with a token that has no value outside your payment processor's vault. Your systems hold tokens, not card data.
• P2PE (Point-to-Point Encryption) — for card-present transactions, encrypting at the terminal so the merchant never sees plain-text PAN.
• Outsourcing — using a PCI-validated service provider to handle the moments where CHD is actually exposed.
• Pause-and-resume call recording — better than nothing, but the consensus from QSAs is that it's a control with a lot of failure modes (agent forgets to pause, software glitch, etc.).

If you can architect a flow where the PAN never lands in your environment, the bulk of PCI DSS doesn't apply to you. You'll still need an SAQ A or similar to document that fact, but the audit burden is a fraction of what it would be otherwise.

Common mistakes with cardholder data

The pattern we see most often in compliance assessments isn't malicious — it's accidental retention. A few examples:

• PANs in CRM notes because an agent typed the card number into a free-text field.
• Full card numbers in call recordings because the pause-and-resume macro failed.
• Card details in customer emails forwarded to a shared inbox.
• Test card data in development databases that get backed up to the same place as production.
• Receipt logs that print the full PAN instead of a masked version.

All of these put systems in scope that the business never intended to be in scope. The fix is partly technical (masking, redaction, DLP scanning) and partly process (training, retention policies, regular discovery scans for stored PAN).

Why this matters commercially

PCI scope drives cost. A merchant with a small, well-segmented CHD environment might complete an SAQ A-EP or SAQ D in a few weeks and pay a few thousand pounds in QSA fees. A merchant with cardholder data scattered across CRM, call recordings, email and finance systems is looking at a full Report on Compliance (ROC), six-figure assessment costs and a much higher residual breach risk. The difference is mostly down to how much CHD they touch and where it ends up.