PCI DSS Requirement 3: protect stored account data
By Sam Rivera, Founder, SentinelPanda · August 6, 2026 · 3 min read · PCI DSS
The cheapest way to satisfy Requirement 3 is to not store account data at all. Everything else in this requirement is the price of deciding otherwise.
The bright line: sensitive authentication data
Requirement 3.3.1 is one of the few absolute prohibitions in PCI DSS. Sensitive authentication data — full track data from the magnetic stripe or chip, the card verification code (CVV2, CVC2, CID, CAV2), and the PIN or PIN block — must not be stored after authorisation, even encrypted. There is no compensating control that makes storing CVV acceptable.
This trips up teams who log raw request payloads for debugging. An application that logs the full authorisation request to a centralised log platform has just put SAD in that platform, brought it into scope, and created a violation that no amount of encryption resolves. Check your logging before your assessor does.
Store less, for less time
Requirement 3.2.1 requires account data storage to be kept to a minimum, with a data retention and disposal policy defining what is kept, for how long, and why — plus a process that actually deletes data when the period expires. Legal or business justification is required for anything retained.
A quarterly process that finds and securely deletes stored account data past its retention period is the practical implementation. Most organisations discover, the first time they run it properly, that they are storing considerably more than they thought — in database backups, exports, support tickets, and analytics pipelines.
Rendering PAN unreadable
- One-way hashes of the entire PAN using strong cryptography with an associated key (keyed hashing — plain unsalted hashes are inadequate given the small PAN keyspace).
- Truncation, where the removed segment cannot be reconstructed from a retained segment.
- Index tokens with securely stored pads, or tokenisation via a service.
- Strong cryptography with associated key management processes under Requirements 3.6 and 3.7.
- Note the disk-level encryption caveat: full-disk encryption alone is not sufficient for non-removable media unless it is implemented with a mechanism separate from the native operating system authentication.
Masking and key management
Requirement 3.4.1 governs display: PAN is masked so that only personnel with a documented, legitimate business need see more than the first six and last four digits. Support tooling is the usual offender — an internal admin console showing full PAN to every support agent is both a finding and an insider-risk problem.
Requirements 3.6 and 3.7 cover cryptographic key management: restricting access to keys to the fewest custodians necessary, storing keys securely in as few locations as possible, defining key lifecycles including rotation and retirement, and preventing unauthorised substitution. If you use a managed KMS, much of this is inherited from the provider — but the key custodian roles, access restrictions, and documented procedures remain yours.
Tokenisation is worth serious consideration here. Replacing stored PAN with tokens from a validated provider removes most of Requirement 3 from your environment, and typically shifts you to a smaller SAQ.