PCI DSS Requirement 3 governs any payment card data you keep. In version 4.0 it comes down to five obligations. Store as little account data as possible, and for no longer than you need it. Never keep sensitive authentication data after authorization. Mask the primary account number (PAN) when it's displayed. Render stored PAN unreadable. Manage your cryptographic keys properly. Version 4.0 also adds several requirements that are future-dated to March 31, 2025, including keyed hashes for PAN, limits on disk-level encryption, and technical controls against copying PAN over remote access.
Here's what each part of Requirement 3 asks for, which items are new, and where organizations tend to get caught out.
What does PCI DSS Requirement 3 cover?
In PCI DSS 4.0, Requirement 3 is titled "Protect Stored Account Data". Account data has two parts:
| Cardholder data | Sensitive authentication data (SAD) |
|---|---|
| Primary account number (PAN) | Full track data (magnetic stripe or chip equivalent) |
| Cardholder name | Card verification code |
| Expiration date | PINs and PIN blocks |
| Service code |
PAN is the element that triggers most of the requirement. If you store it, the rules on rendering it unreadable apply. SAD is treated much more strictly: outside narrow exceptions for issuers, you can't keep it after authorization at all.
As with every principal requirement in 4.0, Requirement 3 opens with documented policies and procedures (3.1.1) and with defined roles and responsibilities (3.1.2). Both apply now in any 4.0 assessment.
Which Requirement 3 items are future-dated?
The following are best practices until March 31, 2025, when they become mandatory. Everything else in Requirement 3 applies as soon as you're assessed against PCI DSS 4.0. Version 3.2.1 remains available until it's retired on March 31, 2024.
| Requirement | What's new |
|---|---|
| 3.2.1 (one bullet) | Retention policies must cover SAD stored before authorization is complete |
| 3.3.2 | SAD stored electronically before authorization is complete must be encrypted with strong cryptography |
| 3.3.3 | Issuers: SAD storage limited to a legitimate issuing business need, secured, and encrypted with strong cryptography |
| 3.4.2 | Technical controls to prevent copying or relocating PAN when using remote-access technologies |
| 3.5.1.1 | Hashes used to render PAN unreadable must be keyed cryptographic hashes |
| 3.5.1.2 | Disk- or partition-level encryption limited to removable media unless PAN is also protected another way |
| 3.6.1.1 (one bullet) | Service providers: cryptographic architecture must prevent use of the same keys in production and test |
How long can you keep account data?
Requirement 3.2.1 expects data retention and disposal policies, procedures and processes that:
- Cover every location where account data is stored
- Cover SAD stored before authorization is complete (future-dated)
- Limit the amount of data stored, and how long it's kept, to what legal, regulatory or business requirements need
- Set specific retention periods backed by documented business justification
- Define how data is securely deleted or rendered unrecoverable when it's no longer needed
- Verify at least once every three months that data past its retention period has been securely deleted or rendered unrecoverable
The hard part is the first bullet. Card data turns up where nobody designed it to be: application logs, support tickets, spreadsheet exports, old backups, test environments copied from production, and cloud storage buckets set up for a one-off project. A retention policy only covers the locations you know about.
Run data discovery across your in-scope systems before you write or rewrite the policy, and repeat it regularly. PCI DSS 4.0 also adds Requirement 12.10.7, future-dated to March 31, 2025, which requires incident response procedures for when stored PAN is found anywhere it isn't expected.
What are the rules for sensitive authentication data?
Requirement 3.3.1 is unchanged in substance: SAD isn't retained after authorization, even if it's encrypted, and it must be rendered unrecoverable once authorization is complete. Sub-requirements 3.3.1.1 to 3.3.1.3 cover full track data, the card verification code and PINs or PIN blocks respectively. Issuers and companies that support issuing services have a limited exception where there's a legitimate business need.
Requirement 3.3.2 is new and future-dated. Some systems hold SAD for a short time before authorization completes, for example when transactions are queued and authorized later. Any SAD stored electronically in that window must be encrypted with strong cryptography. Your retention policy must also cover it under 3.2.1.
Requirement 3.3.3, also future-dated, applies to issuers and companies that support issuing services and store SAD. Storage must be limited to what a legitimate issuing business need requires, secured, and encrypted with strong cryptography.
How should PAN be masked when displayed?
Requirement 3.4.1 says that when PAN is displayed, it's masked so that only personnel with a legitimate business need can see more than the BIN and last four digits. PCI DSS 3.2.1 refers to the first six digits. Version 4.0 refers to the BIN instead.
Treat the BIN and last four as the most you're allowed to show, not a target. Many roles need only the last four digits, or no PAN at all. List the roles that genuinely need to see full PAN, document why, and configure your applications, reports and screens to match.
Masking is about what people see. It doesn't change what's stored. A masked display over an unprotected database column still fails Requirement 3.5.
How do you stop PAN being copied over remote access?
Requirement 3.4.2 is new and future-dated. When personnel use remote-access technologies, technical controls must prevent them from copying or relocating PAN. The only exception is personnel with documented, explicit authorization and a legitimate, defined business need.
PCI DSS 3.2.1 treats this as a usage policy under Requirement 12.3.10. Version 4.0 requires technical enforcement. Depending on how people connect, that can mean disabling clipboard sharing, drive mapping, printing and file transfer in remote sessions to in-scope systems. It can also mean using data loss prevention controls on remote endpoints. Keep the list of authorized exceptions short, and review it.
How do you render stored PAN unreadable?
Requirement 3.5.1 requires PAN to be unreadable anywhere it's stored, using any of these methods:
- One-way hashes of the entire PAN, based on strong cryptography
- Truncation, where hashing can't be used to replace the truncated segment
- Index tokens
- Strong cryptography with associated key-management processes and procedures
If you store hashed and truncated versions of the same PAN, or different truncation formats, you need additional controls so the versions can't be correlated to reconstruct the original number.
Why do hashes need to be keyed?
Requirement 3.5.1.1, future-dated, requires hashes used to render PAN unreadable to be keyed cryptographic hashes of the entire PAN, with key management that meets Requirements 3.6 and 3.7.
The reason is the small number of possible PANs. Card numbers have a known structure, a limited set of issuer prefixes and a check digit. An attacker who steals a table of plain hashes can often compute every candidate PAN and match them. A keyed hash, such as an HMAC, can't be reproduced without the secret key. If you use plain hashes today, plan the migration now, and remember that the hashing key has to be managed like any other cryptographic key.
When is disk-level encryption no longer enough?
Requirement 3.5.1.2, future-dated, says disk-level or partition-level encryption can render PAN unreadable only on removable electronic media. On non-removable media, you can still use it, but PAN must also be rendered unreadable by another method that meets 3.5.1.
Disk-level encryption protects against physical theft of the media. Once a system is running and the volume is mounted, anyone with logical access sees the data in the clear. Transparent encryption at rest on server and cloud storage volumes often works the same way, so confirm with your assessor how your specific setup will be treated.
Until the future date, disk-level encryption can still be used under Requirement 3.5.1.3. Logical access must be managed separately and independently of native operating system authentication and access controls. Decryption keys must not be associated with user accounts, and the authentication factors that unlock the data must be stored securely.
What does PCI DSS require for key management?
If you use encryption or keyed hashes, Requirements 3.6 and 3.7 apply to the keys.
Protecting keys (3.6)
Requirement 3.6.1 requires procedures that:
- Restrict key access to the fewest custodians necessary
- Make key-encrypting keys at least as strong as the data-encrypting keys they protect
- Store key-encrypting keys separately from data-encrypting keys
- Store keys securely in the fewest possible locations and forms
Requirement 3.6.1.2 says secret and private keys must be stored in at least one of three forms at all times. They can be encrypted with a key-encrypting key, held within a secure cryptographic device such as a hardware security module, or held as at least two full-length key components or key shares. Requirements 3.6.1.3 and 3.6.1.4 restrict access to cleartext key components and limit where keys are stored.
Service providers must also document their cryptographic architecture under Requirement 3.6.1.1, covering algorithms, protocols, keys, key strength, expiry and usage, and the secure cryptographic devices in use. The new bullet on not using the same keys in production and test is future-dated.
Managing the key lifecycle (3.7)
Requirement 3.7 requires documented and implemented key-management policies and procedures for each stage of a key's life:
| Requirement | Key-management activity |
|---|---|
| 3.7.1 | Generating strong keys |
| 3.7.2 | Distributing keys securely |
| 3.7.3 | Storing keys securely |
| 3.7.4 | Changing keys at the end of a defined cryptoperiod |
| 3.7.5 | Retiring, replacing or destroying keys when needed, such as when a key's integrity is weakened or compromise is suspected |
| 3.7.6 | Split knowledge and dual control for manual cleartext key operations |
| 3.7.7 | Preventing unauthorized key substitution |
| 3.7.8 | Key custodians formally acknowledging their responsibilities |
For cryptoperiods, NIST Special Publication 800-57 Part 1 is a widely used reference. Service providers that share keys with customers must also give those customers documented guidance on securely transmitting, storing and updating them (3.7.9).
Frequently asked questions
Can we store the card verification code if it's encrypted?
Not after authorization. Requirement 3.3.1.2 prohibits keeping it once authorization is complete, even encrypted. If your systems hold it briefly before authorization, it must be encrypted and covered by your retention policy under the future-dated 3.3.2 and 3.2.1.
Is full-disk encryption on our database servers enough?
For now, it can be, provided you meet 3.5.1.3's conditions for managing access separately. From March 31, 2025, disk-level encryption on non-removable media will only be acceptable if PAN is also rendered unreadable by another method, such as column-level encryption, keyed hashing or tokenization.
How often do we have to change encryption keys?
PCI DSS doesn't set a single interval. Requirement 3.7.4 requires you to define a cryptoperiod for each key type, based on industry guidance, and change keys at the end of it.
Next steps
- Run data discovery across in-scope systems and update your data inventory before you touch the retention policy.
- Check whether any system stores SAD before authorization, and plan encryption for it under 3.3.2.
- Review where full PAN is displayed and who can see it.
- Identify any unkeyed PAN hashes and any reliance on disk-level encryption for non-removable media. Both need migration plans before March 31, 2025.
- Test your remote-access setup to see whether PAN can be copied out of in-scope sessions.
- Compare your key-management documentation with 3.6 and 3.7, and confirm that every key has an owner, a cryptoperiod and a documented lifecycle.