No. PCI DSS Requirement 3.3.1 prohibits storing sensitive authentication data after authorization, even if it is encrypted. That covers full track data, card verification codes and PINs or PIN blocks. The only exception in the standard is for issuers and issuing service companies with a documented business need.
Cardholder data vs sensitive authentication data
PCI DSS splits account data into two groups. Cardholder data is the primary account number (PAN), cardholder name, expiration date and service code. Sensitive authentication data (SAD) is full track data from the magnetic stripe or chip equivalent, the card verification code, and PINs or PIN blocks.
The groups have different storage rules. Cardholder data may be stored if it is protected, with PAN rendered unreadable under Requirement 3.5.1. SAD may not be kept once authorization is complete.
What the council says about timing
The PCI Security Standards Council FAQ on this topic makes two points. After authorization, Requirement 3.3.1 prohibits SAD storage, including encrypted storage. Before authorization, the standard sets no specific limit on how long SAD can be held, but it still has to be protected under PCI DSS. PCI approved PIN transaction security devices and validated payment software can help protect it.
The FAQ adds a caution: each payment brand decides whether SAD may be stored before authorization and sets its own rules. Some brands prohibit it entirely with no exceptions. Check with your acquirer or the brands.
Where SAD sneaks into systems
The rule is easy to break by accident. Common leak points:
- Application logs and error traces that print request bodies.
- Support tooling, such as tickets or chat transcripts where customers paste a card number and code.
- Message queues and dead letter queues holding payment payloads for retry.
- Analytics and session replay tools that capture form fields.
- Database backups and snapshots taken while a table briefly held a CVV.
- Developer machines where a test run used a real card.
"Encrypted" does not help. The requirement is that SAD is not retained after authorization at all.
How to prove you are not storing it
- Map every place card data enters, moves and rests. Annual scope confirmation under Requirement 12.5.2 expects exactly this, including all locations where account data is stored, processed or transmitted. See scope categories.
- Add data discovery scans over databases, file stores, logs and backups to look for SAD patterns.
- Redact request bodies in logging libraries by field name, and test it.
- Add a payment page design that keeps card entry on the processor's side where possible. See the SAQ decision guide.
- Define a purge procedure for any SAD found, and record it.
The issuer exception
The applicability notes allow issuers and companies that support issuing services to store SAD where there is a legitimate, documented business need, and where the data is secured. Merchants and ordinary payment facilitators do not get this exception.
Quick check
Can I store the CVV if I encrypt it?
No. Requirement 3.3.1 prohibits SAD storage after authorization even if it is encrypted.
Can I hold card data while a payment is being authorized?
The standard sets no specific time limit before authorization, but the data must be protected and your payment brands may have stricter rules.
Sources
- PCI SSC FAQ: can sensitive account data be stored before authorization
- PCI DSS v4.0 SAQ D for Merchants, account data definitions and requirement 3.5.1
- Just Published: PCI DSS v4.0.1
Last reviewed: 19 October 2026.
