What counts as cardholder data, and what you must never store

PCI DSS draws a hard line between cardholder data and sensitive authentication data. One you may store under conditions. The other you must not keep after authorisation, at all.

PCI DSS uses two terms that sound similar and behave completely differently. Confusing them is the most consequential mistake available in the standard, because one category may be stored under conditions and the other must not be retained after authorisation under any conditions at all.

Cardholder data

The PCI SSC glossary defines it plainly: at a minimum, cardholder data consists of the full PAN. It may also appear as the full PAN plus any of the cardholder name, expiration date, or service code.

The PAN is the anchor. The other elements are only cardholder data in the PCI sense when they travel with it. A list of customer names and expiry dates with no card numbers is not cardholder data, though it may well be personal data under GDPR, which is a separate obligation with its own rules.

Sensitive authentication data

The glossary defines this as security-related information used to authenticate cardholders or authorise payment card transactions, including but not limited to card verification codes, full track data from the magnetic stripe or chip equivalent, PINs, and PIN blocks.

This is the category with the absolute rule. Sensitive authentication data must not be retained after authorisation, even if it is encrypted. Encryption does not create permission here. The requirement is that the data is not kept.

The three-digit code on the signature strip is sensitive authentication data. If it is in a support ticket, a call recording, or an email, it is being retained after authorisation.

Why this is a discovery problem

Nobody designs a system to retain sensitive authentication data. It arrives by accident, through channels that were never part of the payment flow:

• A customer emails their card details because the payment page failed.
• Support pastes a full PAN into a ticket to investigate a declined transaction.
• A call recording captures a card number and security code read aloud.
• A finance export includes an unmasked column nobody noticed.
• Someone screenshots a payment confirmation and saves it to a shared drive.

Each of these puts card data somewhere your cardholder data environment does not cover, which extends scope to whatever system now holds it. In the case of security codes and track data, it also creates a retention position the standard does not permit.

What to do about it

Three things, in order:

1. 1Find out whether it is happening. This is the step that gets assumed rather than checked, and the assumption is usually optimistic.
2. 2Remove what should not be there, and record that you did.
3. 3Close the channel that let it in, whether that is a form, a process, or a habit.

The order matters. Closing the channel without removing the existing data leaves the retention problem in place, and the existing data is the part an assessor will find.

How EmberHound fits

EmberHound scans enrolled company devices for stored card data and reports what it finds, with the file and device attached. Detection runs on the endpoint; each match produces a masked preview and a salted fingerprint, so the full number never leaves the machine it was found on.

That covers the local copies, exports and saved attachments that sit outside the payment flow. Mailbox scanning is an add-on for the email channel specifically.

This article is general information, not assessment advice. Your acquirer and your QSA determine what applies to you.