CVV Test for PCI DSS: An Overview of Rules and Methods

A CVV test for PCI DSS is a control check that proves your payment environment collects the card verification value during authorization and never retains it afterward. PCI DSS classifies the CVV2, CVC2, CAV2 and CID as sensitive authentication data (SAD), so storing any of them after authorization, even in encrypted form, fails the standard.

cvv test for pci dss steps

The confusion around the term is worth clearing up first. A card CVV check is an issuer decision made during authorization. A PCI DSS CVV test is something your own team runs against your systems to show the value is not landing in databases, log files, queues, caches or support tools. The guide below covers the second meaning.

cvv test for pci dss information

What a CVV test is meant to prove

PCI DSS does not ask whether a card's verification value was correct. That is the issuer's job and it happens inside the authorization message. The standard asks whether your environment keeps that value after the transaction is approved, declined or abandoned. A CVV test produces evidence for that question.

how to cvv test for pci dss

• No CVV value is written to a database, data warehouse or backup set.
• No CVV value appears in application, web server, gateway or WAF logs.
• No CVV value is echoed in API responses, error messages or debug traces.
• No CVV value reaches analytics, CRM, chat or ticketing platforms.
• No CVV value is held in browser storage, mobile SDK caches or session replays.
• No CVV value is captured in call recordings, chat transcripts or agent notes.

The PCI DSS requirements that drive the test

Several requirements shape how the test is scoped and what counts as a pass.

• Requirement 3 covers storage of account data. Requirement 3.3 and its sub-requirements state that sensitive authentication data is not retained after authorization. This is the core rule the CVV test measures.
• Requirement 3.2 sets data retention limits, which means unused payment fields should not be present in the first place.
• Requirement 4 requires strong cryptography for account data in transit, which applies to the authorization message carrying the CVV.
• Requirement 6 covers secure development, so the test should confirm that payment forms and APIs do not collect or forward fields they do not need.
• Requirement 10 requires logging, and the same test must verify that logs exclude the CVV while still recording the event.
• Requirement 11 covers security testing, including penetration testing that often surfaces leftover CVV capture points.
• Requirement 12 requires documented policies and a defined scope, both of which your test evidence should support.

How a compliant CVV test runs

A practical test follows the payment data flow rather than the org chart. The sequence below works for a web checkout, a mobile app and a call center flow.

1. Map the flow. Trace the CVV field from the entry point to the processor request and confirm where it terminates.
2. Build a test matrix. Cover approved, declined, timeout, retry, refund and chargeback scenarios, since error paths often leak fields that the happy path does not.
3. Use sandbox credentials. Run everything against acquirer or gateway test PANs. Live cardholder data is never needed to prove the control works.
4. Instrument the environment. Capture logs, inspect database tables and query the message queue while a test transaction passes through, looking for the field name and the value.
5. Inspect the client. Check local storage, IndexedDB, cookies, mobile keychain and any session replay or analytics payload.
6. Review third parties. Confirm which vendors receive the field, whether they need it, and what their own attestation says.
7. Record the result and retest. Each finding needs a fix, a retest and a dated piece of evidence.

Findings that show up most often

Most failed CVV tests are not deliberate design decisions. They come from debugging that stayed in production, a form field that was added for a promotion and never removed, or a vendor SDK that collects the full card entry when it only needed a token. Verbose server error pages, request body logging at the edge, and support tools that display the raw authorization request are the usual suspects.

Tokenization removes most of this exposure. When the processor returns a token instead of the card data, the CVV never enters your environment and the test scope shrinks to the point of capture.

What the evidence should look like

An assessor will look for a defined procedure, a list of systems in scope, the test transactions used, screenshots or query output showing the field absent, and a remediation log for anything found. A short document with dated results is more convincing than a large one with no dates.

One caution is worth stating plainly: nothing in this guideline involves obtaining real card numbers. The tests described here use sandbox data supplied by your acquirer or gateway, and they exist to keep verification values out of your systems rather than to capture them.

Where the test fits in validation

Depending on your merchant level and channel, the CVV test supports a self-assessment questionnaire or a report on compliance. It also feeds your annual scope confirmation, because any system that touches the CVV is by definition in scope. Running the test before that scope exercise saves rework later, and it turns an abstract requirement into a set of concrete checks your engineers can repeat.