PCI DSS Encryption Requirements for Stored Card Data (Requirement 3)

PCI DSS encryption requirements for stored card data sit in Requirement 3: Protect stored account data. In short: keep as little card data as you can for as short a time as you can, never keep sensitive authentication data after authorisation, mask card numbers when they are displayed, and render every stored primary account number (PAN) unreadable using keyed hashing, truncation, index tokens or strong cryptography, with the keys properly managed. Two PCI DSS 4.0 encryption requirements that became mandatory on 31 March 2025 changed what many organisations had in place: hashes of PAN must now be keyed (3.5.1.1), and disk encryption on its own no longer counts for non-removable media (3.5.1.2).

This guide covers each part of Requirement 3 in PCI DSS v4.0.1, the evidence an assessor asks for and the gaps that commonly lead to findings. For the other 11, see our overview of the PCI DSS requirements, or take our free PCI compliance check to see your likely SAQ and where you stand across all 12.

What does PCI DSS Requirement 3 cover?

Requirement 3 covers account data at rest: cardholder data (the PAN, cardholder name, expiry date and service code) and sensitive authentication data (full track or chip data, card verification codes, PINs and PIN blocks). Our explainer on what counts as PCI data sorts each element into its category.

The requirement has seven sections. Items marked † became mandatory on 31 March 2025.

What card data can you store, and for how long?

Only what you have a legal, regulatory or business need for, and only for as long as that need lasts. Requirement 3.2.1 expects a written retention policy that names every location where account data is kept, sets a retention period with a justification, explains secure deletion, and includes a check at least once every three months that anything past its retention date has gone.

The weak point is usually the word “every”. Card numbers turn up in support tickets, inboxes, spreadsheets, application logs, backups and call recordings, so run a data discovery exercise before you write the policy. The smaller the footprint, the smaller your cardholder data environment: our PCI DSS scoping guide shows how deleting data shrinks what an assessor has to test.

Can you store sensitive authentication data?

Not after authorisation, even if it is encrypted. Full track data, the card verification code and the PIN or PIN block must be unrecoverable once authorisation completes (3.3.1.1 to 3.3.1.3). Since 31 March 2025, any sensitive authentication data held electronically before authorisation completes, for example in a payment queue, must be encrypted with strong cryptography (3.3.2). Only issuers and companies supporting issuing services may keep it longer, limited to a legitimate issuing business need and secured (3.3.3). For everyone else, a typical breach of this rule is a call recording in which the customer reads out the security code. Our guide to PCI compliance for call centres explains how to keep it out of call and screen recordings.

How must card numbers be masked on screen?

Requirement 3.4.1 limits any displayed PAN to the BIN and last four digits, unless a person has a documented business need to see more. Masking controls what people see; it does not protect the stored value, which is the job of 3.5.1. Requirement 3.4.2, mandatory since 31 March 2025, adds that remote desktop and virtual desktop tools must stop users copying or moving PAN, through the clipboard or local drives for example, unless they have documented, explicit authorisation and a defined business need.

What are the PCI DSS encryption requirements for stored card numbers?

PCI credit card encryption rules apply to the PAN wherever it is stored: in databases, files, backups and logs. Requirement 3.5.1 allows four ways to make it unreadable, and they behave very differently:

The PCI DSS glossary defines strong cryptography as industry-tested and accepted algorithms with at least 112 bits of effective key strength, plus proper key management. The rule covers every copy of the PAN, including backups, audit logs and troubleshooting logs. A merchant holding only its payment provider’s tokens may not store PAN at all. Our guide to PCI tokenisation compares tokens with encryption and explains what stays in scope.

Encrypting stored card numbers also helps with UK GDPR, which names encryption as an example of an appropriate security measure under Article 32. Our guide to GDPR and PCI compliance shows which PCI DSS controls evidence that duty.

Are hashed card numbers acceptable under PCI DSS?

Yes, but only keyed hashes. Since 31 March 2025, Requirement 3.5.1.1 says hashes used to render PAN unreadable must be keyed cryptographic hashes of the entire PAN, with the key managed like any other cryptographic key. A plain SHA-256 of a card number no longer qualifies.

The reason is arithmetic. Card numbers are short, their first digits identify the issuer and the last digit is a check digit, so an unkeyed hash can be reversed by trying every possible number. The same weakness drives the correlation rule: if a database holds a truncated card number and a hash of the full number, the missing middle digits can be found by trial. A secret key, held apart from the data, removes that shortcut.

Is disk encryption enough for PCI DSS?

Not on its own for fixed storage. Since 31 March 2025, Requirement 3.5.1.2 allows disk-level or partition-level encryption to be the only protection for PAN on removable media. On non-removable media, such as server disks, PAN must also be made unreadable by another 3.5.1 method, such as column-level or field-level database encryption, keyed hashing, truncation or tokenisation.

Disk encryption protects against theft of the disk. Once the system is running, data is decrypted for anyone who can log in and for any compromised process, which is how card data is usually stolen. Where disk encryption is used, 3.5.1.3 adds that access must be managed separately from operating system logins and that decryption keys must not be tied to user accounts. A useful test of any “encrypted at rest” claim: what protects the PAN from someone already logged in?

PCI database encryption is where 3.5.1.2 bites hardest, because “the database is encrypted” can mean very different things:

How must encryption keys be managed for PCI DSS?

Keys that protect stored account data must be protected (3.6) and managed through their whole lifecycle (3.7). Under 3.6.1.2, secret and private keys must always be held in one of three forms: encrypted with a key-encrypting key that is at least as strong and stored separately; inside a secure cryptographic device such as a hardware security module (HSM); or as at least two full-length key components or shares. Clear-text key components are restricted to the fewest custodians necessary, and keys are kept in the fewest possible locations (3.6.1.3, 3.6.1.4).

The lifecycle requirements in 3.7 cover generation, distribution and storage of keys (3.7.1 to 3.7.3); changing keys at the end of a defined cryptoperiod, set using guidance such as NIST SP 800-57 (3.7.4); retiring keys whose integrity is weakened or suspected compromised (3.7.5); split knowledge and dual control for manual clear-text key operations (3.7.6); preventing unauthorised key substitution (3.7.7); and written acknowledgement by key custodians (3.7.8). Service providers must also document their cryptographic architecture (3.6.1.1) and give customers guidance when keys are shared (3.7.9).

Developers designing field-level encryption will find the OWASP Cryptographic Storage Cheat Sheet a useful companion. Organisations that process PIN-based transactions or manage the keys that protect PINs, such as acquirers, processors and key injection facilities, are assessed against the separate PCI PIN Security Requirements, which our guide to PCI PIN compliance explains.

Does Requirement 3 cover encryption in transit?

No. Card data sent over open, public networks falls under Requirement 4, which requires strong cryptography and trusted certificates for PAN in transmission (4.2.1), an inventory of trusted keys and certificates (4.2.1.1), and protection for PAN sent through end-user messaging such as email or chat (4.2.2).

Why work with Sovereign Secure?

Sovereign Secure is a PCI SSC-approved Qualified Security Assessor (QSA) company, Qualified PIN Assessor (QPA) and Card Production Security Assessor (CPSA), and a member of the PCI SSC Global Executive Assessor Roundtable (GEAR) for 2026 to 2028. Because we also assess against the PIN Security and Card Production standards, where HSMs, key management and key ceremonies are central, we review Requirement 3 cryptography with that depth. We are ISO 27001 certified and have been a UK company since 2012. Where we both advise and assess, the two pieces of work are kept separate, as the PCI SSC expects of a QSA company.

Need a second opinion on how you store card data?

If you are unsure whether your hashing, tokenisation or encryption meets Requirement 3, our PCI DSS consultancy team can review the design before your assessment. The official requirement text and testing procedures are free from the PCI SSC document library. Contact us or call +44 161 523 5276 for a fixed quote.