PCI DSS 3.3.3 (issuers): Any storage of sensitive authentication data
PCI DSS v4.0.1 control 3.3.3: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 3.3.
Requirement 3: Protect Stored Account Data › Section 3.3
Additional requirement for issuers and companies that support issuing services and store sensitive authentication data: Any storage of sensitive authentication data is:
- Limited to that which is needed for a legitimate issuing business need and is secured.
- Encrypted using strong cryptography. This bullet is a best practice until its effective date; refer to Applicability Notes below for details.
Summary
Issuers, and only issuers, may store sensitive authentication data after authorisation, and only what the issuing business genuinely needs, secured and strongly encrypted.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 3.3.3.a | Additional testing procedure for issuers and companies that support issuing services and store sensitive authentication data: Examine documented policies and interview personnel to verify there is a documented business justification for the storage of sensitive authentication data. |
| 3.3.3.b | Additional testing procedure for issuers and companies that support issuing services and store sensitive authentication data: Examine data stores and system configurations to verify that the sensitive authentication data is stored securely. |
Read the first line before anything else: this control applies to issuers and companies that support issuing services. If you are a merchant or a service provider that is not supporting issuing, it does not give you permission for anything, and 3.3.1 still forbids retaining sensitive authentication data after authorisation. This is the narrow exception that exists because an issuer has to be able to verify a card, and it is the control most often misread by entities it does not apply to. The encryption bullet was published as future-dated and became mandatory on 31 March 2025 along with the rest of the v4.x future-dated controls, so it is not optional now.
What to prepare
- The documented business justification for each element of sensitive authentication data retained, tied to a specific issuing function.
- Data-store configurations and encryption evidence for wherever that data lives.
- Evidence of your issuing role, since the assessor has to establish the control applies to you at all.
How to implement it
1. Justify each element separately. The procedure asks for a documented business justification, and "the platform stores it" is not one. Track data, card verification codes and PINs are different things with different justifications, and one of them usually turns out not to be needed.
2. Encrypt with strong cryptography, and be able to name the algorithm and key length. Secured and encrypted are tested as two things, so file-system permissions alone satisfy neither bullet.
3. Bound the retention. "Limited to that which is needed" is a volume and a duration, not only a set of fields.
Where this commonly fails
- A non-issuer citing this control as authority to retain sensitive authentication data, which is the single most common misreading in Requirement 3.
- A justification written for the system rather than for the data, so it explains what is stored and not why the issuing business needs it.
- Encryption present in the production database and absent from backups, exports or the test environment refreshed from production.
Related controls
Others in section 3.3:
| Control | What it requires |
|---|---|
| 3.3.1 | SAD is not stored after authorization, even if encrypted |
| 3.3.1.1 | The full contents of any track are not stored upon completion of the authorization process |
| 3.3.1.2 | The card verification code is not stored upon completion of the authorization process |
| 3.3.1.3 | The personal identification number (PIN) and the PIN block are not stored upon completion… |
| 3.3.2 | SAD that is stored electronically prior to completion of authorization is encrypted using… |
← 3.3.2 · All controls · 3.4.1 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it 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. Nothing here is a substitute for advice from a Qualified Security Assessor.