The short answer to a PCI DSS CVV test is that there is nothing to test for storage, because storing it is prohibited. A merchant or service provider may not retain the CVV, CVC, CAV, or CID after authorization, and the assessor's task is to prove that no application, log, queue, backup, or print stream holds it. The criteria that decide the outcome are the sensitive authentication data (SAD) requirements in PCI DSS, the evidence an assessor can actually sample, and whether the same answer survives a data discovery sweep. Those three points drive everything below.

CVV Test and PCI DSS Validation: What Merchants Must Prove

What the CVV test is really checking

In PCI DSS v3.2.1 the prohibition sat under Requirement 3.2. Version 4.0 moved it into Requirement 3.3, which states that SAD is not stored after authorization, even if encrypted. This is broader than the cardholder data rules. It applies to every system component that touches an authorization request or response, including switches, middleware, fraud tools, and call recording platforms.

cvv test compliance pci dss

The requirement is absolute rather than risk based. There is no compensating control that lets a business keep a CVV for chargeback defense, recurring billing, or customer service lookup. Tokenization, network tokens, and stored cardholder data without the verification code are the accepted substitutes.

more on this topic

The three SAD elements and where each one leaks

Assessors treat SAD as three distinct families, and each has its own leak paths:

cvv test for pci dss requirements

  • Full track data. Magnetic stripe or chip equivalent data, including the CVV1 value encoded on the stripe. It shows up in terminal debug logs, gateway request dumps, and old test fixtures.
  • Card verification codes. CAV2, CVC2, CVV2, and CID. The printed value on the card. It hides in order notes, agent desktop fields, exception queues, and support tickets.
  • PINs and PIN blocks. Captured at entry and during translation. It appears in hardware error traces, host security module logs, and ATM or POS diagnostic output.

Evidence an assessor collects

Sampling is where most findings originate. Expect requests for:

  • Application source, configuration files, and schema definitions for every component in the authorization path.
  • Log extracts, database queries, and backup inventories covering the assessment period.
  • Print spooler output, call recording samples, and email or chat templates.
  • Vendor attestations for hosted payment pages and any third party that handles SAD on your behalf.
  • Memory or process dumps when the assessor wants to show whether SAD persists at runtime.

Two ways to demonstrate the control

Automated data discovery and log scanning

  • Pros: covers large estates in days, catches forgotten test data and legacy directories, produces repeatable evidence across the assessment period.
  • Cons: pattern matching produces false positives on order numbers and phone fields, needs tuning before it is credible, and can miss custom encodings or truncated values.

Manual code, configuration, and log review

  • Pros: finds the logic that writes a field into a table or a message body, explains intent to the assessor, works for small or highly custom environments.
  • Cons: slow, sampling dependent, and easy to scope too narrowly to the checkout page alone.

Recommendation: run discovery and log scanning first to shrink the search space and produce artifacts, then use manual code and configuration review to confirm each hit and document the fix. Assessment teams accept the combination far more often than either method alone.

Common failure points

  • Card verification codes written into order history or agent notes during manual phone orders.
  • Full gateway request and response payloads retained in application logs or an observability platform.
  • Test or seed data copied from production that still contains real verification values.
  • Third party scripts on the payment page that receive the field before tokenization.
  • Backups and archives that outlive the retention policy stated in the assessment scope.

Fix these before the on site review. A failed CVV control is a scored finding, and in most programs it can push a merchant into a higher validation level for the following year.

Use case guidance

Small merchants using a hosted payment page should focus on log review and vendor attestations, since the SAD never enters their systems. Larger merchants with a call center, a custom checkout, or an in house gateway should invest in discovery scanning plus code review, because the write paths are theirs to control. Service providers should expect the assessor to test runtime memory as well as disk, and should be able to show that any SAD received in an authorization response is discarded in the same transaction.