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. This is the finding that most often turns into an incident, because it is usually discovered in application logs nobody thought of as storage.

3.5 requires PAN to be rendered unreadable wherever it is stored. Truncation, tokenisation, and strong cryptography are all acceptable 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. The single most common serious finding
• Test environments seeded from a production dump
• Encryption keys stored beside the data they protect, or in the same backup

Official source

This page is original commentary. It cites requirement identifiers and the official requirement title, and does not reproduce the text of the standard. For the authoritative wording, including each testing procedure and the customized approach objective, download PCI DSS v4.0.1 (June 2024) 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.