Elements of Account Data and Storage Requirements

PCI DSS Table 3 exists to close that gap. It names every element of account data and tells you two things: can you store it, and if so, does it have to be unreadable.

Account data has two halves, and they're not the same thing

Cardholder Data (CHD):

• Primary Account Number (PAN)
• Cardholder Name
• Expiration Date
• Service Code

Sensitive Authentication Data (SAD):

• Full track data (mag-stripe data, or the chip equivalent)
• Card verification code (CVV2/CVC2/CID)
• PINs and PIN blocks

PAN is what makes cardholder data cardholder data. Strip the PAN out and a name or expiration date sitting alone isn't regulated the same way. Put it back next to the PAN, and now it is.

SAD is a different animal. It's not identity information, it's authentication material. It's what a criminal needs to actually use a stolen card, not just know it exists.

What you can store, and what you can't

Cardholder data

PAN is the only element on this list that has to be encrypted, hashed, truncated, or tokenized everywhere it lives. If it sits in a table next to a name and expiration date, only the PAN needs that treatment. The rest just need a business reason to exist at all.

Sensitive authentication data, and the CVV question people keep getting wrong

Here's the part worth slowing down for: CVV can be stored. Just not for long.

PCI DSS doesn't ban SAD storage outright. It bans storing it after authorization. Before that point, while the transaction is actually being processed, holding the CVV, the PIN block, or the track data in a protected data store is normal and expected. The moment the authorization response comes back, that data has to go. Encrypted or not.

Encryption doesn't buy you an exception here. A properly encrypted CVV sitting in your database six months after the transaction closed is still a violation. The standard isn't asking you to protect this data long-term. It's asking you to delete it on a deadline.

There's a carve-out for issuers and companies supporting issuing services, who have legitimate reasons to retain SAD under a separate, tighter set of rules. Everyone else: delete on authorization. And this applies even if you never touch a PAN at all. Not storing card numbers doesn't exempt you from the SAD rule.

Why the two halves get treated so differently

PAN storage usually can't be avoided. Merchants need it for recurring billing, refunds, chargebacks. So PCI DSS settles for minimize it, then lock it down hard.

SAD is different. Once a transaction clears, there is no legitimate reason left to have it. It did its job. Keeping it around doesn't protect the business, it just sits there as a liability waiting for someone to find it. That's why the rule for SAD isn't "protect it," it's "get rid of it."

How PAN actually gets rendered unreadable

Four accepted methods, per Requirement 3.5.1:

• One-way hashing of the full PAN
• Truncation, permanently dropping digits so the full number can't be rebuilt (you can't use hashing to reconstruct a truncated segment)
• Index tokens, swapping the PAN for a reference value that points to the real number stored elsewhere
• Strong cryptography with real key management behind it

One trap worth flagging: if you're storing both a hashed version and a truncated version of the same PAN in the same environment, you need controls preventing someone from cross-referencing the two to rebuild the original number. Each method alone is reasonably safe. Combined, without additional controls, they can leak more than either does on its own.

The short version, for whoever has to implement this

1. Know exactly which fields in your systems are PAN, name, expiration date, service code, and SAD.
2. Don't store what you can't justify. "Minimum necessary" is the standard, not "whatever's convenient."
3. Delete SAD the moment authorization completes. CVV, track data, PIN blocks. All of it. Encryption doesn't change the deadline.
4. Wherever PAN lives, render it unreadable. Databases, logs, backups, temp files, all of it.
5. If hashed and truncated PANs coexist anywhere, make sure they can't be correlated back to the original.