CVV Test for PCI DSS Steps: What Assessors Check

Answer

A CVV test for PCI DSS checks a system, not a card. The assessor confirms three things: the CVV2/CVC2/CID passes to the processor during authorization, no copy is written to disk, and no copy appears in logs, backups, or error traces. Test card numbers come from the acquirer or processor sandbox. Live card numbers are out of scope.

more on this topic

Where the CVV sits in PCI DSS

PCI DSS groups the CVV2/CVC2/CID with full track data and PIN blocks under sensitive authentication data (SAD). SAD is separate from the card number. A merchant may store the PAN if it is protected under Requirement 3.5. SAD has no such allowance. Requirement 3.3.1 states that SAD is not retained after authorization, even when encrypted.

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

Related sub-requirements extend the ban to storage media, backups, and logs, and to the case where the value is printed on the card and issued to the cardholder.

related article

Test steps

1. Draw the data flow. List every system that touches the authorization request: payment page, API gateway, application server, queue, processor connector. Mark where the CVV field enters and where it leaves.
2. Collect test PANs. Request sandbox PANs, expiry dates, and CVV values from the acquirer or processor. Record the source.
3. Run authorizations in the sandbox. Send approval, decline, and CVV mismatch cases. Capture the result codes.
4. Inspect storage. Query every database, cache, object store, and queue in the flow for the CVV field. Include archived tables and replica nodes.
5. Inspect logs. Search application logs, web server logs, WAF logs, APM traces, and error trackers for the test CVV, the full request body, and the CVV field name.
6. Inspect backups. Confirm backup jobs exclude or mask the CVV field. Check restore procedures.
7. Review code. Read the handler that builds the authorization request. Confirm the CVV is passed through and dropped, and that no debug branch writes it.
8. Check the browser side. Confirm the payment page does not place the CVV in local storage, session storage, or cookies, and that no page script reads the field.
9. Record evidence. Save configuration screenshots, query output, log excerpts, and code snippets with dates and system names.

What the assessor asks for

• Data flow diagram with the CVV path marked.
• Configuration setting that disables CVV storage.
• Query output showing zero rows for the CVV field.
• Log search results for the test CVV value.
• Backup policy showing the exclusion.
• Processor test results for approval, decline, and mismatch.

Common failures

Request bodies written to an error tracker. Full HTTP payloads in a WAF log. A queue message that keeps the whole authorization request. A payment page script that reads the CVV field for analytics. A test environment with production data copied in.

Each failure breaks Requirement 3.3.1 at the storage step. Fix the pipeline, then re-run the tests and re-collect evidence.

Test values

Use values from the processor sandbox. Acquirers and processors publish test PAN ranges and matching CVV values for certification. Do not use a card number from a live account in a test environment. Do not send CVV checks to an issuer to learn whether a number is valid. That activity is card testing, not PCI DSS testing, and it falls outside the standard.