Requirement 3: Protect Stored Account Data

Requirement 3 has one governing idea: data you do not store cannot be stolen. Every control under it is either about storing less, or protecting what genuinely must remain.

PCI DSS v4.0.1 breaks this requirement into 7 sections containing 29 individual controls.

What this requirement is actually asking

The hardest line in the standard sits here. Sensitive authentication data (the full track, CVV, and PIN) must not be retained after authorisation. Not encrypted, not tokenised: not retained. The one exception is issuers and companies that support issuing services with a legitimate, documented business need, who must meet 3.3.3 instead. Logs count as storage: the standard lists transaction, debugging and error logs among the data sources to check.

3.5 requires PAN to be rendered unreadable wherever it is stored. Keyed hashes of the entire PAN (3.5.1.1), truncation, index tokens and strong cryptography are the four accepted routes, and they carry very different downstream obligations. Tokenisation can remove systems from scope entirely, while encryption drags key management (3.6, 3.7) along with it.

Does it apply to you?

If you never store account data, most of this requirement falls away, but you must be able to demonstrate that, which usually means data-discovery output rather than an assurance.

The controls

Requirement 3 contains 29 controls across 7 sections. Each links to its own page with the requirement in full and the testing procedures an assessor uses to verify it.

3.1: Governance for the protection of stored account data

Control	What it requires	Guidance
3.1.1	All security policies and operational procedures that are identified in Requirement 3…	Yes
3.1.2	Roles and responsibilities for performing activities in Requirement 3 are documented, assigned…	Yes

3.2: Store less: retention, and disposal when the business need ends

Control	What it requires	Guidance
3.2.1	Account data storage is kept to a minimum through implementation of data retention and disposal…	Yes

3.3: Sensitive authentication data is not retained after authorisation

Control	What it requires	Guidance
3.3.1	SAD is not stored after authorization, even if encrypted	Yes
3.3.1.1	The full contents of any track are not stored upon completion of the authorization process	Yes
3.3.1.2	The card verification code is not stored upon completion of the authorization process	Yes
3.3.1.3	The personal identification number (PIN) and the PIN block are not stored upon completion…	Yes
3.3.2	SAD that is stored electronically prior to completion of authorization is encrypted using…	Yes
3.3.3	Issuers: Any storage of sensitive authentication data…	Yes

3.4: Displays of full PAN, and restricting who can copy it

Control	What it requires	Guidance
3.4.1	PAN is masked when displayed…	Yes
3.4.2	When using remote-access technologies, technical controls prevent copy and/or relocation of PAN…	Yes

3.5: Rendering PAN unreadable in storage

Control	What it requires	Guidance
3.5.1	PAN is rendered unreadable anywhere it is stored by using any of the following approaches…	Yes
3.5.1.1	Hashes used to render PAN unreadable (per the first bullet of Requirement 3.5.1) are keyed…	Yes
3.5.1.2	If disk-level or partition-level encryption…	Yes
3.5.1.3	If disk-level or partition-level encryption is used…	Yes

3.6: Protecting the keys that protect the data

Control	What it requires	Guidance
3.6.1	Procedures are defined and implemented to protect cryptographic keys used to protect stored…	Yes
3.6.1.1	Service providers: A documented description of the cryptographic architecture is maintained…	Yes
3.6.1.2	Secret and private keys used to protect stored account data are stored in one (or more)…	Yes
3.6.1.3	Access to cleartext cryptographic key components is restricted to the fewest number…	Yes
3.6.1.4	Cryptographic keys are stored in the fewest possible locations	Yes

3.7: Key lifecycle: generation, distribution, rotation, retirement

Control	What it requires	Guidance
3.7.1	Key-management policies and procedures are implemented to include generation of strong…	Yes
3.7.2	Key-management policies and procedures are implemented to include secure distribution…	Yes
3.7.3	Key-management policies and procedures are implemented to include secure storage…	Yes
3.7.4	Key management policies and procedures are implemented for cryptographic key changes for keys…	Yes
3.7.5	Key management policies procedures are implemented to include the retirement, replacement…	Yes
3.7.6	Where manual cleartext cryptographic key-management operations are performed by personnel…	Yes
3.7.7	Key management policies and procedures are implemented to include the prevention…	Yes
3.7.8	Key management policies and procedures are implemented to include that cryptographic key…	Yes
3.7.9	Service providers: Where a service provider shares cryptographic keys with its customers for transmission…	Yes

Evidence your assessor will ask for

• Data-discovery scan results across all in-scope systems, including logs, backups and non-production copies
• A documented retention schedule with defined business justification, plus evidence of actual deletion
• Key management procedures covering the full lifecycle, and records of custodian acknowledgement

Where this commonly fails

• CVV captured in application debug logs or error-tracking tools. A log that keeps it is storage under 3.3.1.2
• Test environments seeded from a production dump
• Data-encrypting keys stored in clear text beside the data they protect, or a key-encrypting key kept in the same place, or the same backup, as the keys it protects

Terms

Glossary entries that name a control in this requirement:

• Account Data: 3.3.1, 3.3.2, 3.5.1
• Algorithm: 3.5.1, 3.5.1.1, 3.6.1.1
• Authorization: 3.3.1
• Card Verification Code (CVC)/Card Verification Value (CVV): 3.3.1, 3.3.1.2
• Cardholder Data: 3.4.1, 3.5.1
• Cleartext Data: 3.5.1, 3.6.1.2, 3.7.6
• Column-Level Database Encryption: 3.5.1, 3.5.1.2, 3.5.1.3
• Compromise: 3.7.5
• Cryptographic Architecture: 3.6.1.1
• Cryptographic Key: 3.6.1, 3.6.1.2, 3.6.1.3, 3.6.1.4, 3.7.1, 3.7.2, 3.7.3
• Cryptographic Key Generation: 3.7.1
• Cryptoperiod: 3.7.4, 3.7.5
• Data Encrypting Key (DEK): 3.6.1, 3.6.1.2
• Dual Control: 3.7.6
• Encryption: 3.3.2, 3.5.1, 3.5.1.2, 3.5.1.3
• Encryption Algorithm: 3.5.1, 3.6.1.1
• File Level Encryption: 3.5.1.2, 3.5.1.3
• Full-Disk Encryption (FDE): 3.5.1.2, 3.5.1.3
• Hardware Security Module (HSM): 3.6.1.1, 3.6.1.2
• Hashing: 3.5.1, 3.5.1.1
• Index Token: 3.5.1
• Issuer: 3.3.3
• Issuing Services: 3.3.3
• Key Custodian: 3.6.1, 3.6.1.3, 3.7.8
• Key Encrypting Key (KEK): 3.6.1, 3.6.1.2
• Key Management: 3.6.1, 3.7.1, 3.7.2, 3.7.3, 3.7.4, 3.7.5, 3.7.7, 3.7.8
• Key Management System: 3.7.1, 3.7.2, 3.7.3, 3.7.4, 3.7.5
• Keyed Cryptographic Hash: 3.5.1, 3.5.1.1
• Logical Access Control: 3.5.1.3
• Magnetic Stripe Data: 3.3.1, 3.3.1.1
• Masking: 3.4.1
• One-way Hash: 3.5.1, 3.5.1.1
• Operating System: 3.5.1.3
• PAN (Primary Account Number): 3.4.1, 3.4.2, 3.5.1, 3.5.1.1
• Personal Identification Number (PIN): 3.3.1.3
• PIN Block: 3.3.1.3
• Point of Interaction (POI): 3.6.1.2
• Remote Access: 3.4.2
• Removable Electronic Media: 3.5.1.2
• Sensitive Authentication Data (SAD): 3.3.1, 3.3.1.1, 3.3.1.2, 3.3.1.3, 3.3.2, 3.3.3
• Separation of Duties: 3.7.6
• Split Knowledge: 3.6.1.2, 3.6.1.3, 3.7.6
• Strong Cryptography: 3.3.2, 3.3.3, 3.5.1
• Tokenization: 3.5.1
• Track Data: 3.3.1, 3.3.1.1
• Truncation: 3.4.1, 3.5.1

Official source

The commentary on this page is our own. The requirement title, and the control text in the tables above (shortened where it ends in an ellipsis), are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. Each control's own page carries its requirement text in full. For the authoritative wording, including each testing procedure and the customized approach objective, download the standard from the PCI Security Standards Council document library.

PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site.