What Card Data Are You Allowed to Store? SAD, Retention, and the Rules
Most PCI DSS conversations are about how to protect card data. This one is about a prior question the standard answers with unusual bluntness: which data you may keep at all. The rules draw a hard line through the contents of every card. On one side sits account data you may store if you protect it; on the other sits sensitive authentication data, which no merchant may retain after authorization under any circumstances, encrypted or not, for any reason. Breaches become catastrophes on the wrong side of that line, because stolen data that should never have existed converts directly into fraud. Here is the full map: what is storable, what never is, and the masking, truncation, and retention rules that govern the permitted side.
Quick answer: After authorization, merchants may store the primary account number (rendered unreadable), cardholder name, expiry date, and service code, and only as long as a documented business need exists. Sensitive authentication data may never be stored after authorization: full track data, the CVV2/CVC2/CID security code, and PINs or PIN blocks. The ban holds even when the data is encrypted.
Which data elements are storable, and which never are?
| Data element | Storage after authorization | Protection if stored |
|---|---|---|
| Primary account number (PAN) | Permitted with business need | Must be rendered unreadable (strong encryption, truncation, tokens, or keyed hashing) |
| Cardholder name | Permitted | Protect per requirement; no unreadability mandate |
| Expiration date | Permitted | Protect per requirement |
| Service code | Permitted | Protect per requirement |
| Full track data (magnetic stripe or chip equivalent) | Never | Not applicable: prohibited |
| Card verification code (CVV2, CVC2, CID) | Never | Not applicable: prohibited |
| PIN / encrypted PIN block | Never | Not applicable: prohibited |
The prohibited rows are what the standard calls sensitive authentication data, or SAD. The logic behind the ban is worth internalizing rather than memorizing: track data lets criminals manufacture counterfeit cards, the security code lets them pass card-not-present checks, and the PIN unlocks cash. Each element exists to prove the genuine card or cardholder is present; a stored copy is therefore a forgery kit. Storable elements, by contrast, identify the account without by themselves proving possession.
One scoping note: issuers (and companies supporting issuing services) operate under a narrow exception allowing SAD storage where a documented, legitimate issuing need exists, with strong protection. Merchants and ordinary service providers have no such exception.
What does “never” mean in practice?
- Not in databases, obviously, but also not in logs, crash dumps, call recordings, chat transcripts, spreadsheets, or email. The ban follows the data, not the system. These accidental stores are exactly what a data discovery program exists to find, and security codes in support tickets are among its most common catches.
- Not encrypted either. Encrypting SAD does not make retention lawful under the standard; the only compliant state after authorization is deletion. “We keep CVV encrypted for retries” is a finding, not a control.
- Before authorization is a different phase: data captured while a transaction is in flight is permitted to exist transiently, and PCI DSS 4.0 added an explicit requirement that even this pre-authorization SAD be protected with strong cryptography while it exists. Transient means transient; queues and temp files that outlive the authorization become storage.
- Recurring billing does not need the code. Card networks do not require CVV2 for subsequent stored-credential transactions; the correct architecture is a token plus the stored-credential framework, as covered in our guide to securing recurring billing. Any vendor claiming they must keep your customers’ security codes for rebilling is describing a design error.
How must a stored PAN be protected?
Requirement 3 offers four accepted techniques for rendering stored PANs unreadable, which we compare in depth in encryption, tokenization, and hashing under PCI DSS:
- Strong encryption with sound key management.
- Truncation: permanently removing digits, keeping at most the first six (or eight, under expanded BIN rules) and last four.
- Index tokens with securely stored lookup, the vault model.
- One-way hashing of the entire PAN, which 4.0 tightened to require keyed cryptographic hashes; plain unsalted hashes of PANs are brute-forceable in minutes and no longer acceptable.
A related trap: storing a truncated PAN and a hash of the same PAN side by side can allow reconstruction, so the standard requires controls ensuring the two cannot be correlated.
Masking is not truncation
The two are routinely confused. Truncation changes what is stored: the digits are gone forever. Masking changes what is displayed: the full PAN exists underneath, with asterisks painted over it for a given screen. Requirement 3.4 governs display, limiting visible digits to at most the first six and last four (frequently just the last four) unless a role has a documented business need to see more. A support tool that shows agents the full number on demand, or that “masks” in the browser while the full PAN sits in the page source or the API response, fails the point of both controls. Display less, to fewer people, and log who viewed what.
How long may permitted data be kept?
Only as long as a defined business, legal, or regulatory need exists, under a documented retention policy with a defined disposal process, verified at least quarterly in spirit and, under 4.0’s phrasing, enforced so that data exceeding retention is found and securely deleted. The honest implementation question is less about writing the policy than about making deletion real across primaries, replicas, exports, and backups. Retention is also where PCI DSS meets privacy law: GDPR’s storage-limitation principle points the same direction, a convergence we explore in GDPR and payment data. The cheapest compliant dataset remains the one you never kept, which is the entire argument for tokenizing with a provider and keeping no PANs at all.
Frequently asked questions
Can we store CVV2 if the customer consents?
No. The prohibition is absolute for merchants and is contractual through the card networks; customer consent does not create an exception.
Is keeping the last four digits compliant?
Yes. First six (or eight) plus last four is the truncation ceiling, and last-four alone is common and safe for receipts, support, and matching.
We found old CVV data from a legacy system. What now?
Securely delete it everywhere including backups, fix the process that captured it, and document both. If the data was exposed in an incident, its presence materially worsens brand consequences, so treat remediation with urgency.
Does storing expiry dates require encryption?
Expiry, name, and service code must be protected under the standard’s general controls but do not carry the PAN’s render-unreadable mandate. If stored alongside PANs, inherit the stronger handling.
Do these rules apply if a provider stores everything for us?
The obligations follow the data to your provider, and your duty becomes verifying their compliance, the discipline in our TPSP risk playbook. Your own systems still must not leak copies through logs, exports, or support workflows.
Every data element on a card is either an identifier or a proof. Identifiers can be guarded; proofs must not be warehoused. Keep that one distinction and the entire storage rulebook becomes predictable.