PCI DSS Requirement 3 Key Management Guide: Protecting Stored Account Data

Encrypting stored card numbers is the easy part of PCI DSS Requirement 3; most findings come from the keys, who can reach them, where copies live, and whether anyone can show how they are generated, changed and destroyed. This guide covers PCI DSS v4.0.1 Requirement 3 with a focus on key management: storing as little account data as possible (3.2), never keeping sensitive authentication data after authorisation (3.3), masking (3.4), rendering PAN unreadable (3.5), securing keys (3.6) and the key lifecycle procedures in 3.7. It is written for security architects, key custodians, database and platform engineers and PCI programme owners. Requirement wording is summarised, not quoted, because the standard itself is published as a PDF in the PCI SSC Document Library; check every value against the current standard before relying on it.

Key takeaways

• The cheapest key is the one you do not need: 3.2.1 requires account data storage to be kept to a minimum through retention and disposal; tokenisation or not storing PAN removes most of Requirement 3.
• Hashes now need keys: 3.5.1.1 requires hashes used to render PAN unreadable to be keyed cryptographic hashes of the entire PAN, with key management under 3.6 and 3.7, which a PCI SSC FAQ also confirms.
• Disk encryption alone is not enough for non-removable media: under 3.5.1.2, disk or partition-level encryption must be complemented by another mechanism that meets 3.5.1.
• Keys are protected by people rules as well as technology: fewest custodians (3.6.1.3), fewest locations (3.6.1.4), split knowledge and dual control for manual cleartext operations (3.7.6) and written custodian acknowledgement (3.7.8).
• Every key has a cryptoperiod: 3.7.4 requires key changes at the end of the cryptoperiod defined by the vendor or key owner, based on industry guidance; the PCI SSC glossary points to NIST SP 800-57.

How Requirement 3 is structured

Requirement 3, "Protect Stored Account Data", has seven sections. Encryption of data in transit is Requirement 4, not 3. The standard as a whole is summarised in the PCI DSS 4.0 Guide, and the data elements (PAN, cardholder name, service code, track data, card verification code, PIN) in the Payment Card Data Elements page.

3.2 to 3.4: store less, store nothing sensitive, show less

• 3.2.1 minimise: define retention by business, legal and regulatory need for each data store, purge on a schedule, and find stray PAN with data discovery. Every copy you delete is a copy you no longer need to encrypt and key. See the Data Retention and Disposal Policy Template.
• 3.3.1 sensitive authentication data: full track data (3.3.1.1), the card verification code (3.3.1.2) and the PIN and PIN block (3.3.1.3) are not stored after authorisation, even if encrypted, and SAD received is rendered unrecoverable when authorisation completes. 3.3.2 requires SAD stored electronically before authorisation completes to be encrypted with strong cryptography. 3.3.3 adds conditions for issuers.
• 3.4.1 masking: PAN is masked on display so that only people with a legitimate business need see more than the limited part of the PAN the standard allows.
• 3.4.2 copy controls: with remote-access technologies, technical controls prevent copying or relocating PAN except for people with documented, explicit authorisation and a defined business need. In practice this means disabling clipboard and drive mapping in remote sessions to CDE systems by default.

3.5: rendering PAN unreadable

3.5.1 requires PAN to be rendered unreadable anywhere it is stored. The standard lists the acceptable approaches: one-way hashes of the entire PAN (keyed, under 3.5.1.1), truncation, index tokens, and strong cryptography with associated key management.

Hashed PAN and scope: a PCI SSC FAQ (updated March 2026) says the hashing process, its results and the systems that perform it are in scope; a hashed PAN moved to and stored in a separate environment is no longer cardholder data, but if it stays on the system that performed the hashing, that system remains in scope.

3.5.1.3 disk encryption management: where disk or partition encryption is used, logical access is managed separately and independently of native operating system authentication and access control, and decryption keys are not associated with user accounts.

For choosing between tokenisation and encryption products, see the Data Masking and Tokenisation Buyer's Guide and the Database and Storage Encryption Guide.

3.6: securing the keys

3.6.1 requires procedures that protect keys used for stored account data against disclosure and misuse. Apply them to key-encrypting keys as well as data-encrypting keys. The sub-requirements set specific expectations:

• 3.6.1.1 crypto architecture (service providers): a documented description of the cryptographic architecture, typically including algorithms, protocols and keys with strength and expiry, each key's usage, and an inventory of HSMs and other secure cryptographic devices. Merchants benefit from keeping the same document.
• 3.6.1.2 secure forms: secret and private keys that encrypt or decrypt stored account data are stored only in the secure forms the standard allows. In general terms these keep cleartext key material out of reach: wrapped under a separately stored key-encrypting key, held inside a secure cryptographic device such as an HSM, or split into key components or shares.
• 3.6.1.3 fewest custodians: access to cleartext key components is restricted to the fewest custodians necessary.
• 3.6.1.4 fewest locations: keys are stored in the fewest possible locations. Count backups, disaster recovery copies, configuration files, CI/CD variables and developer laptops, not only the production key store.

Strong cryptography: the PCI SSC glossary defines it as industry-tested and accepted algorithms with key lengths giving a minimum of 112 bits of effective key strength and proper key management, and recommends at least 128 bits for new implementations.

Where identity fits

In most modern environments nobody types a key: applications call a key management service or HSM using a service account, workload identity or API credential. That credential is, in effect, the key. Treat every identity with decrypt or detokenise permission as a key custodian for 3.6.1.3 purposes, limit those permissions to named workloads, rotate their credentials, and log every use under Requirement 10. See the PCI DSS Requirements for Service Accounts and NHIs Guide and the Secrets Management Guide.

3.7: the key lifecycle

Cryptoperiod: the PCI SSC glossary defines it as the time span during which a key can be used for its purpose, usually set by time, by the amount of ciphertext produced, or both, following guidance such as NIST SP 800-57. Our recommendation: document a cryptoperiod per key type (for example key-encrypting keys, data-encrypting keys, hash keys) with the reason, rather than one blanket period.

Split knowledge and dual control: the PCI SSC glossary defines dual control as two or more separate parties cooperating so that no single person can access or use materials such as a key, and split knowledge as two or more parties holding separate key components that individually convey no knowledge of the resulting key. These apply where people handle cleartext keys or components, for example HSM master key ceremonies or loading a key into a payment device. Fully automated KMS operations where no person sees cleartext key material do not involve manual cleartext operations. For HSM ceremonies in depth, see the HSM Deployment and Operations Guide.

Decision guidance

• Remove, tokenise, or encrypt: if a process does not need PAN, delete it. If it needs a stable reference, tokenise. Encrypt only where PAN must be recovered, because encryption brings the full 3.6 and 3.7 burden.
• Cloud KMS or dedicated HSM: a cloud KMS gives managed generation, storage, rotation and access logging; a dedicated or cloud HSM gives single-tenant control and supports manual ceremonies. Either can meet Requirement 3 if keys, custodians and access are documented. If you bring or hold your own keys, see the BYOK, HYOK and External Key Management Guide.
• Small merchants: outsourcing card storage to a payment provider's token service is usually far cheaper than running key management. Confirm in writing which Requirement 3 controls the provider covers; see the PCI DSS for Service Providers and Responsibility Matrix Guide.
• Large or multi-tenant service providers: keep a full crypto architecture document (3.6.1.1), separate key hierarchies per tenant or environment, and customer guidance where keys are shared (3.7.9).

How to implement Requirement 3 key management

1. Find the data: run data discovery across databases, file shares, logs, backups and analytics stores. Delete what 3.2.1 does not justify.
2. Choose a method per store: tokenise, truncate, keyed hash or encrypt, using the table above. Replace unkeyed hashes with keyed hashes (3.5.1.1).
3. Inventory keys: list every key protecting stored account data, its type, algorithm and length, location, custodians, accessing identities and cryptoperiod. This becomes the 3.6.1.1 document.
4. Consolidate: move keys into an HSM or KMS, remove copies from configuration files and scripts, and cut custodians and accessing identities to the minimum (3.6.1.3, 3.6.1.4).
5. Write lifecycle procedures: cover every 3.7 item, run one rotation and one retirement as a test in a non-production environment first, and keep the previous key version available for decryption so you can roll back if re-encryption fails.
6. Run ceremonies properly: for any manual cleartext operation, use split knowledge and dual control, scripted steps, witnesses and logs (3.7.6), and collect custodian acknowledgements (3.7.8).
7. Monitor: log every key use, administrative change and decrypt call, and alert on unusual volumes and new accessing identities.

Detection and measurement

Framework mapping

For a fuller treatment of key management outside PCI, see the Cryptographic Key Management Guide.

Common failure patterns

• Keys beside the data: the data encryption key sits in an application configuration file on the same server as the encrypted database.
• Disk encryption as the only control: transparent volume encryption on a database server, which does nothing once the operating system is running (3.5.1.2).
• Unkeyed hashes: plain SHA-256 of PAN, which can be reversed by enumerating the limited PAN space; 3.5.1.1 requires keyed hashes.
• Forgotten copies: keys in old backups, disaster recovery sites, CI variables or a developer's local test environment, breaking 3.6.1.4.
• No cryptoperiod: keys created years ago with no defined end of life and no rotation evidence (3.7.4).
• Over-broad decrypt rights: many service accounts and support staff can call decrypt or detokenise, making the encryption a formality.

Practitioner checklist

• Run data discovery and delete account data that 3.2.1 does not justify.
• Confirm no track data, card verification codes or PIN data are stored after authorisation (3.3.1).
• Choose and document a 3.5.1 method per store; replace unkeyed hashes with keyed hashes.
• Do not rely on disk encryption alone for non-removable media (3.5.1.2).
• Keep a key inventory and crypto architecture document (3.6.1.1).
• Store keys only in secure forms, in the fewest locations, with the fewest custodians (3.6.1.2 to 3.6.1.4).
• Write and test procedures for every 3.7 stage, with documented cryptoperiods.
• Use split knowledge and dual control for manual cleartext key operations and collect custodian acknowledgements (3.7.6, 3.7.8).
• Treat every identity with decrypt or detokenise rights as a custodian and log its use.

Standards and references

• PCI SSC: Document Library (PCI DSS v4.0.1)
• PCI SSC FAQ 1089: Hashed PAN and cardholder data
• PCI SSC Glossary: Strong Cryptography
• PCI SSC Glossary: Cryptoperiod
• PCI SSC Glossary: Dual Control
• PCI SSC Glossary: Split Knowledge
• NIST: SP 800-57 Part 1 Rev. 5, Recommendation for Key Management
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: PCI DSS 4.0 Guide, Cryptographic Key Management Guide, HSM Deployment and Operations Guide, PCI DSS Scoping and Network Segmentation Guide, PCI DSS Readiness Checklist. This guide summarises PCI DSS v4.0.1 Requirement 3 and is not legal or assessment advice.