PCI DSS 3.3.1.2: The card verification code is not stored upon completion of the authorization process
PCI DSS v4.0.1 control 3.3.1.2: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 3.3.
Requirement 3: Protect Stored Account Data › Section 3.3
The card verification code is not stored upon completion of the authorization process.
Summary
The card verification code is never kept once the authorisation is done.
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.1.2 | Examine data sources, to verify that the card verification code is not stored upon completion of the authorization process. |
The element of sensitive authentication data most likely to be captured by people rather than by systems, which makes it different from track data and PINs. It is the number a customer reads out over the phone, types into a form, writes in an email, or includes in a screenshot attached to a support ticket. So the search for it runs through call recordings, ticketing systems, mailboxes, chat transcripts and form submission logs, none of which are payment systems. The code exists only to prove the card was present at authorisation and has no purpose afterwards, which means there is never a business justification to weigh: unlike PAN, there is no retention argument to have.
What to prepare
- Call recordings and their retention, if the business takes payments by phone.
- Ticketing systems, mailboxes and chat archives.
- Web form and API request logging.
- Evidence of searching each, since the procedure examines data sources.
How to implement it
1. Pause or mask call recording during card capture. It is the standard answer for telephone payments and it is a configuration rather than a policy.
2. Strip it at the edge. Request logging that redacts the field before writing is the only reliable way to keep it out of form and API logs.
3. Tell the people who take calls and read tickets. They create this data, and 3.1.1 is where they learn not to.
4. Remember there is no justification to make. The code has no use after authorisation, so any instance found is simply removed.
Where this commonly fails
- Call recordings retained in full, including the seconds where the code is read aloud.
- Support tickets with screenshots of a completed payment form.
- Request logs capturing the full form body, including the code field.
- Searching payment systems only, when the code is usually somewhere else entirely.
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.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.3 | Issuers: Any storage of sensitive authentication data… |
← 3.3.1.1 · All controls · 3.3.1.3 →
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.