Storing CVV: What Merchants Need to Know

The card verification code is the three- or four-digit number printed on the front or back of a payment card, used to check card-not-present transactions. Brands call it CVV2, CVC2, CID or CAV2. PCI DSS treats it as sensitive authentication data, and the rule on keeping it is short and strict. This article covers the rule, what it allows, where stored codes usually turn up, and what does not count as one.

The rule

• 3.3.1: sensitive authentication data is not stored after authorisation, even if encrypted. Everything received is made unrecoverable once authorisation completes.
• 3.3.1.2: the card verification code specifically is not stored upon completion of the authorisation process. The requirement is not eligible for the customised approach.

Encryption does not change this. Neither does business size: there is no merchant exemption. The only entities the standard exempts from 3.3.1 are issuers and companies that support issuing services with a documented business need, and they have their own conditions under 3.3.3.

The standard's reason is in the guidance: a stolen code lets someone run fraudulent internet and mail or telephone order transactions.

What is allowed before authorisation

The rule bites when authorisation completes, not before. The code can exist while a transaction is in progress, and the standard sets conditions on that:

• If it is stored electronically before authorisation completes, it must be encrypted with strong cryptography (3.3.2).
• Whether storing it before authorisation is allowed at all is decided by the payment brands and acquirers, and the applicability note tells entities to ask them.
• Any such storage has to be covered by the retention and disposal policy in 3.2.1.
• On paper, the guidance says the code should be made unreadable once authorisation completes, for example by cutting it off the form or covering it with an opaque marker that cannot be removed.

Where stored codes turn up

Few businesses mean to keep the code. It ends up stored as a side effect. The guidance to 3.3.1.2 lists the data sources an assessor examines:

• incoming transaction data;
• all logs, including transaction, history, debugging and error logs;
• history files and trace files;
• database schemas and the contents of databases and cloud data stores;
• memory and crash dump files.

Add the places people put things: order notes and free-text fields, emails and chat transcripts, call recordings, spreadsheets, and paper order forms. A call centre that records calls needs the recording paused or masked while the code is read out, or the recording is stored sensitive authentication data.

Recurring payments do not need it

A common reason given for keeping the code is recurring billing. The code is checked when the card is first used; later charges in a recurring series are authorised without it, and the card number itself can be replaced by a token from the payment provider. A provider that asks a merchant to keep codes for later charges is asking for something 3.3.1.2 forbids.

What is not a card verification code

Sensitive authentication data is three things only: full track data, the card verification code, and the PIN or PIN block. The Council's FAQ 1603 (September 2026) confirms that authentication values from a 3-D Secure transaction are not sensitive authentication data, and that PCI DSS does not prohibit storing 3-D Secure data after authorisation. The same logic applies to other values that are sometimes loosely called "dynamic CVVs": the rule is about the code printed on the card.

The full magnetic stripe, including the CVV1 value encoded in it, is covered separately by 3.3.1.1 as track data, and the PIN by 3.3.1.3.

If you find stored codes

1. Stop whatever is writing them: the form field, the log setting, the recording, the habit.
2. Delete what exists, including backups and copies, so it cannot be recovered.
3. Find how it happened and fix the cause, whether software, configuration or a procedure.
4. Treat it as a possible security incident under your incident response plan (12.10.1), which includes analysing any legal reporting obligations.
5. Check the other data sources on the list above; one leak often has company.

For staff who take card details by phone or at a counter, Front Office Payment Security covers what may and may not be written down, the security code included.