Most PCI DSS storage failures come from treating all card data the same, when the standard splits it into two classes with opposite rules: cardholder data may be kept if protected, and sensitive authentication data may not be kept after authorisation at all. This guide compares the two element by element, explains what happens before authorisation, and shows where sensitive authentication data leaks into logs, recordings, debug output and service account reach without anyone deciding to store it. It covers how tokens, truncation and hashing change scope, and what evidence an assessor will ask for. It is written for payment engineers, security architects, internal assessors and compliance leads working to PCI DSS v4.0.1, and draws only on PCI Security Standards Council public pages checked in November 2026.
Key takeaways
- Two classes, two rules. Cardholder data (the full PAN, plus name, expiry date and service code when present with it) can be stored for a documented need if it is protected; sensitive authentication data cannot be retained after authorisation, even encrypted.
- Before authorisation is not a free zone. PCI DSS sets no time limit for holding sensitive authentication data before authorisation, but it must be protected, and the payment brands decide whether it may be stored at all.
- Consent and encryption change nothing. A customer asking you to keep their card verification code, or encrypting it, does not make post-authorisation storage acceptable.
- Leakage beats design. Call recordings, application logs, crash dumps, message queues and analytics events are where sensitive authentication data usually survives authorisation, often written by service accounts nobody reviews.
- Scope follows reversibility. Truncated, hashed or tokenised values can sit outside scope only when the systems holding them cannot get back to the full PAN; the systems that create them stay in scope.
The short answer
PCI SSC's glossary defines account data as cardholder data and/or sensitive authentication data. Cardholder data is, at a minimum, the full primary account number (PAN), and may also include the cardholder name, expiration date and service code. Sensitive authentication data is security information used to authenticate cardholders or authorise transactions: card verification codes, full track data (from the magnetic stripe or chip), PINs and PIN blocks.
The practical rule follows from what each class is for. Cardholder data identifies an account, so a business can have a legitimate reason to keep it for refunds, recurring billing or reconciliation, and PCI DSS lets it do so under Requirement 3 protections. Sensitive authentication data proves that the card and the cardholder are genuine at the moment of authorisation. PCI SSC FAQ 1533 explains why keeping it is harmful: stolen verification codes or PIN data can be matched with PANs from other breaches, and a merchant that stores a verification code alongside a reusable token is effectively telling the issuer that the cardholder supplied the code on every later charge. Once authorisation completes, it has no further legitimate use for anyone except issuers and organisations supporting issuing services.
Element by element: the storage rules
| Element | Class | Store after authorisation? | Protection when stored or shown | Typical legitimate reason |
|---|---|---|---|---|
| Primary account number (PAN) | Cardholder data | Yes, only with a documented business, legal or regulatory need | Unreadable wherever stored (Requirement 3.5), masked on display, keys protected (3.6 and 3.7) | Refunds, chargebacks, recurring payments where no token is available |
| Cardholder name | Cardholder data (when with PAN) | Yes, within retention policy | Protected as cardholder data when stored with the PAN | Customer service, dispute handling |
| Expiration date | Cardholder data (when with PAN) | Yes, within retention policy | As above | Card-on-file updates |
| Service code | Cardholder data (when with PAN) | Yes, within retention policy, though rarely needed | As above | Seldom any outside issuing |
| Full track data (magnetic stripe or chip equivalent) | Sensitive authentication data | No (issuers excepted) | Protected before authorisation; securely deleted once authorisation completes | None after authorisation for merchants |
| Card verification code (three or four digits printed on the card) | Sensitive authentication data | No, including for card-on-file, recurring and concierge use | As above | None after authorisation for merchants |
| PIN and PIN block | Sensitive authentication data | No (issuers excepted) | Handled inside approved PIN entry devices and PIN processing environments | None after authorisation for merchants |
In PCI DSS v4.0.1 the prohibition sits in Requirement 3.3.1, with sub-requirements for full track data (3.3.1.1), card verification codes (3.3.1.2) and PIN and PIN block data (3.3.1.3). PCI SSC FAQ 1318 confirms that the standard sets no minimum or maximum period for keeping cardholder data: Requirement 3.2.1 instead requires a retention and disposal policy that limits storage to what legal, regulatory or business needs justify, with electronic storage protected under Requirements 3.5 to 3.7 and physical media under 9.4. The card verification code names vary by brand (the glossary lists CAV2, CVC2, CVN2, CVV2 and CID), so search and data discovery rules need all of them.
Two common confusions are worth settling. 3DS authentication values are not sensitive authentication data: PCI SSC FAQ 1603 says PCI DSS does not bar storing them after authorisation, though entities running 3DS components should check with the brands whether the PCI 3DS Core Security Standard applies. And a missing PAN does not legitimise stored verification codes: FAQ 1533 says the prohibition applies even in an environment with no PANs. See the PCI 3DS Core Security Standard.
Comparing the two classes in depth
| Dimension | Cardholder data | Sensitive authentication data |
|---|---|---|
| Threat model | Bulk theft of stored PANs for card-not-present fraud; exposure through backups, exports and reporting copies | Theft of verification codes, track or PIN data that defeat issuer authentication, enabling cloned cards or convincing card-not-present fraud |
| Where it lives by design | Payment databases, token vaults, billing systems, dispute tools | Payment pages, terminals and PIN entry devices, authorisation messages in transit, short-lived pre-authorisation queues |
| Where it lives by accident | Spreadsheets, support tickets, data lakes, test copies | Call recordings, debug logs, crash dumps, request tracing, message brokers, analytics and session replay |
| Main control | Minimise, then render unreadable and manage keys | Never persist after authorisation; protect and delete before |
| Encryption as a fix | Satisfies the unreadability requirement when keys are managed properly | Does not make post-authorisation storage acceptable (FAQ 1154, FAQ 1280) |
| Failure mode | Retention creep, key access too broad, unexpected copies | Silent persistence in telemetry; "temporary" pre-authorisation stores that never empty |
| Assessor question | Show me every location, the need, and how it is unreadable | Show me that it is gone after authorisation, everywhere |
Cardholder data: architecture and controls
The architecture to aim for is one authoritative store of PAN, usually a token vault or the payment processor's vault, with everything else holding tokens or truncated values. Where full PAN must be stored, Requirement 3.5.1 requires it to be unreadable, using keyed cryptographic hashes of the whole PAN (3.5.1.1), truncation, index tokens or strong cryptography with managed keys. Display is a separate control: the glossary distinguishes masking (hiding digits on screen or print) from truncation (removing digits from stored data). The PCI DSS Requirement 3 Key Management Guide covers 3.5 to 3.7 in depth, so this guide does not repeat the key lifecycle.
Worked scenario: a subscription business stores PANs for monthly billing. It moves to processor-issued acquiring tokens, which PCI SSC FAQ 1384 says can support card-on-file and recurring payments but cannot be used for new authorisations, and keeps only the first six and last four digits for customer service. The billing database leaves the cardholder data environment only if nothing it can reach can recover the PAN, which an assessor will test.
Sensitive authentication data: architecture and controls
The design aim is that sensitive authentication data passes through and is never written to durable storage after authorisation. In practice that means capturing it in a component you do not operate (a hosted payment field, a PCI PTS approved terminal, a validated software product), keeping any pre-authorisation buffer encrypted, short-lived and access-restricted, and treating every telemetry path as a possible store. PCI SSC FAQ 1154 notes that PTS approved devices and PCI validated payment software can support protection before authorisation.
Worked scenario: a contact centre takes card payments by phone. FAQ 1210 says verification codes kept in audio recordings after authorisation violate Requirement 3.3.1; entities should prevent recording (pause and resume or suppression where available), or delete securely once the transaction is authorised, and where neither is possible must apply compensating controls validated each year. The stronger design removes the agent and recorder from the data path entirely, for example through keypad entry that bypasses the recording platform.
Before authorisation: what is allowed
This is the most misread part of the standard. PCI SSC FAQ 1280 says PCI DSS does not prohibit collecting card verification codes before authorisation of a specific transaction, and FAQ 1154 says PCI DSS sets no specific period for holding sensitive authentication data before authorisation, as long as it is protected. What PCI DSS does not grant, the payment brands may withhold: FAQ 1154 states that each brand decides whether pre-authorisation storage is permitted and on what terms, and that several prohibit it without exception.
- Protect it like the most sensitive data you hold: in v4.0.1, Requirement 3.3.2 requires sensitive authentication data stored electronically before authorisation completes to be encrypted with strong cryptography; it became mandatory on 31 March 2025 with the other future-dated requirements.
- Bound it in time: include pre-authorisation data in the retention and disposal policy (3.2.1), with a defined trigger for deletion, such as authorisation result received or an abandonment timeout.
- Do not stretch "pre-authorisation": holding a verification code so that a later, separate charge can be authorised is post-authorisation storage for the first transaction. FAQ 1280 names recurring, card-on-file and concierge-style services, such as restaurant reservations, as uses where storage is prohibited.
- Check with the brands and the acquirer: FAQ 1154 points entities to the brands directly, with contact details in FAQ 1142.
Issuers are the exception. FAQ 1280 says only issuers, or companies supporting issuing services with a legitimate need, may store sensitive authentication data after authorisation, and the v4.0.1 announcement says the revision clarified Requirement 3 applicability notes for them. In v4.0.1, Requirement 3.3.3 requires that such storage be limited to a documented issuing need and secured. See the PCI Card Production and Provisioning guide for the issuing side.
Where sensitive authentication data leaks: logs, memory and service accounts
Few organisations choose to store verification codes. They end up stored because a component in the request path persisted the whole payload. Treat each of these as a storage location until proven otherwise.
| Leakage path | How it happens | Prevention | How to prove it |
|---|---|---|---|
| Application and web server logs | Request bodies or form fields logged at debug level; exception handlers dumping objects | Field-level allow-lists for logging; redaction in the logging library; debug logging off in production | Scheduled pattern scans of log stores for PAN and three or four digit code fields beside PANs |
| Tracing and observability | Distributed tracing and APM agents capture HTTP bodies or headers | Disable body capture on payment routes; attribute scrubbing rules | Sampled trace review on payment endpoints after every agent upgrade |
| Crash dumps and memory captures | Process memory holding card data written to disk or sent to a crash service | Disable or restrict core dumps on payment hosts; keep crash uploads off payment processes | Configuration evidence plus searches of dump locations |
| Message queues and retries | Authorisation requests held on a queue or dead-letter queue indefinitely | Encrypt and set short retention on payment topics; purge dead-letter queues | Retention settings and queue content sampling |
| Call and screen recordings | Agents read or type codes during recorded sessions (FAQ 1210) | Suppression, pause and resume, or out-of-band keypad entry | Recording samples and suppression configuration |
| Analytics, session replay and support tools | Front-end scripts capture form fields; customers paste card details into chat | Mask payment fields in replay tools; isolate payment iframes; chat redaction | Tool configuration and ticket searches |
Where identity fits
Every leakage path above is written and read by non-human identities: the logging agent's service account, the observability platform's API key, the backup job, the data pipeline that copies logs into a data lake. If any of them can read stores holding sensitive authentication data, those identities and the systems they reach are in scope, and the access itself becomes a route to the data. Inventory the service accounts and tokens with read access to log, trace and recording stores, apply least privilege, and include them in the scope review. The PCI DSS Requirements for Service Accounts and NHIs Guide (8.6) covers the account controls, and the PCI DSS Requirement 10 Guide covers logging that records events without recording card data.
Tokens, truncation and hashing: what changes scope
Substitutes for the PAN reduce scope only when the environment holding them cannot reverse them. They never apply to sensitive authentication data, which should not exist after authorisation to be substituted.
| Technique | What PCI SSC says | Stays in scope | Can leave scope |
|---|---|---|---|
| Truncation | FAQ 1091: keep no more than the first six and last four digits by default; some 16-digit brands allow first eight and any other four; 15-digit PANs first six and last four | The system performing truncation and its connected systems (FAQ 1117) | Segmented systems holding only truncated PANs and no other account data |
| Multiple truncation formats | FAQ 1091 and 1117: combining formats of the same PAN makes reconstruction much easier | Any environment where combined digits exceed the allowed count | Only with assessor-verified controls preventing correlation |
| Keyed hashing | FAQ 1089: whole PAN, strong cryptography, keyed hash under 3.5.1.1; deletion preferred if PAN is not needed | The hashing process, its output on the creating system, and the systems doing it | Hashed PAN moved to and stored in a separate environment is no longer cardholder data |
| Acquiring tokens | FAQ 1384: issued by acquirer, merchant or service provider; cannot be used for new authorisations | The token vault and de-tokenisation services | Systems holding only tokens with no de-tokenisation path, as validated by the assessor |
| Payment tokens | FAQ 1384: created by EMVCo-registered token service providers; merchant never receives the underlying PAN | Systems that still receive PAN elsewhere | Flows where the merchant only ever receives the payment token |
See the Tokenisation vs Encryption guide for the architectural trade-off, the Network Tokenisation for Payments Guide for payment tokens, and the PCI DSS Scoping and Network Segmentation Guide for how assessors confirm segmentation.
Decision guidance
- Do we need the PAN at all? If a processor token serves refunds and recurring billing, stop storing PAN; FAQ 1089 says deletion is preferable to hashing where the PAN need not be recovered.
- Do we need it recoverable? If yes, use encryption or a token vault with managed keys; FAQ 1089 says hashing is not appropriate where the PAN must be recovered.
- Is any sensitive authentication data persisted at all? If anything persists after authorisation and you are not an issuer, the answer is deletion and redesign, not encryption or compensating controls by default.
- Who captures the data? Small merchants usually gain most by moving capture to a hosted page or validated terminal so that sensitive authentication data never touches their systems (see the PCI DSS SAQ Types). Large merchants and service providers that run their own payment switch need the full leakage programme above.
- Phone payments? Prefer out-of-band entry over pause and resume, which depends on agent discipline.
How to implement
- Discover: run data discovery across databases, file shares, log and trace stores, recordings, queues, backups and SaaS tools for PANs and verification code patterns. Record each finding with owner, element type and reason.
- Classify each finding: cardholder data with a need (keep and protect), cardholder data without a need (delete), or sensitive authentication data after authorisation (delete and fix the source).
- Fix sources before cleaning: change the logging, tracing or recording configuration first, in a non-production environment with test card numbers, then confirm with a fresh scan that new data no longer appears.
- Delete securely: purge historic copies including backups on their rotation schedule, and record the method. Keep a rollback for configuration changes, never for deleted card data.
- Substitute: move remaining PAN uses to tokens or truncated values; document which systems can de-tokenise.
- Restrict identities: remove read access to card-bearing stores for service accounts and API keys without a need.
- Re-scope: confirm the cardholder data environment boundary with the assessor and update data-flow diagrams.
- Prepare to respond: define what happens when a scan finds PAN or sensitive authentication data where it should not be; v4.0.1 Requirement 12.10.7 expects incident response procedures for this.
Detection, measurement and assessor evidence
- Unexpected account data findings: count of discovery hits outside approved stores per month, trending to zero for sensitive authentication data.
- Time to remediate: median days from finding to deletion and source fix.
- Approved PAN locations: number of stores holding full PAN, which should fall as tokenisation spreads.
- Telemetry coverage: percentage of payment-path services with verified log and trace redaction.
- Identity reach: number of non-human identities with read access to card-bearing stores, reviewed each quarter.
Assessors typically ask for the retention policy covering both classes, data-flow diagrams showing where sensitive authentication data enters and is discarded, discovery scan results and their remediation, logging and recording configurations, key management records for stored PAN, and for issuers the documented business need. Have the evidence for "it is gone" as ready as the evidence for "it is protected".
Common failure patterns
- Storing the verification code for convenience: card-on-file and recurring flows keep the code "to improve approval rates". FAQ 1280 is explicit that this is prohibited, whatever the customer agreed.
- Encrypting instead of deleting: teams encrypt verification codes or track data and consider the matter closed; FAQ 1154 and FAQ 1280 say encryption does not change the post-authorisation prohibition.
- Pre-authorisation stores that never empty: a retry queue or abandoned-basket table keeps sensitive authentication data for weeks, with no deletion trigger.
- Debug logging left on after an incident: verbose logging enabled to trace a payment fault captures full request bodies and is never reverted.
- Several truncation formats for one PAN: receipts show one format, reports another, support tools a third, and together they rebuild the number (FAQ 1117).
- Hashes on the creating system: hashed PANs left where they were created keep that system in scope (FAQ 1089), and unkeyed hashes no longer meet 3.5.1.1.
Framework mapping
| Concern | PCI DSS v4.0.1 | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|---|
| Retention and disposal | 3.2.1 | SI-12, MP-6 | PR.DS-01 | A.8.10 Information deletion |
| No sensitive authentication data after authorisation | 3.3.1 to 3.3.3 | SI-12 | PR.DS-01 | A.8.10 Information deletion |
| Display masking and stored PAN unreadable | 3.4.1, 3.5.1 | SC-28 | PR.DS-01 | A.8.11 Data masking, A.8.24 Use of cryptography |
| Card data in logs and errors | 3.3.1, Requirement 10 | SI-11, AU-9 | PR.DS-10 | A.8.15 Logging |
| Service account reach | 7, 8.6 | AC-6 | PR.AA-05 | A.8.2 Privileged access rights |
Practitioner checklist
- Publish one table listing every account data element, its class, where it may live and its retention rule.
- Confirm with your acquirer and the brands whether any pre-authorisation storage is permitted for your model.
- Encrypt, time-bound and restrict any pre-authorisation buffer, and include it in the retention policy.
- Remove verification code storage from every card-on-file, recurring and reservation flow.
- Scan logs, traces, crash dumps, queues, recordings and support tools on a schedule, not once.
- Prevent sensitive authentication data in call recordings, preferably by taking it out of the agent's path.
- Replace stored PAN with tokens or one truncation format wherever recovery is not needed.
- Review the service accounts and API keys that can read card-bearing stores each quarter.
- Keep the evidence that sensitive authentication data is deleted, not only that cardholder data is encrypted.
Standards and references
- PCI SSC: Glossary
- PCI SSC: FAQ 1154, Can sensitive account data be stored before authorisation?
- PCI SSC: FAQ 1280, Card verification codes for card-on-file or recurring transactions
- PCI SSC: FAQ 1533, Why SAD may not be stored even without PANs
- PCI SSC: FAQ 1210, Sensitive authentication data in audio recordings
- PCI SSC: FAQ 1089, Hashing PAN and scope
- PCI SSC: FAQ 1091, Acceptable truncation formats
- PCI SSC: Just Published, PCI DSS v4.0.1
Related NHI Mgmt Group resources: PCI DSS 4.0 Guide · PCI DSS Requirement 3 Key Management Guide · PCI DSS Requirement 10 Guide · Tokenisation and Data Masking Guide