A CVV test under PCI DSS validation confirms that the card verification value travels only inside the authorization request and is discarded the moment that request finishes. PCI DSS classifies the CVV2, CVC2, CVV, and CID as sensitive authentication data, and it prohibits retaining them after authorization for any reason. A validation test is the evidence trail showing your checkout, gateway, logs, and staff never keep that value.
CVV Test for PCI DSS Requirements
Why the CVV is treated as sensitive authentication data
The CVV exists to prove the person entering the card number is holding the physical card. Because it is a shared secret between the issuer and the cardholder, it loses all value to a fraudster the second it is reused or compared against a stored copy. That is why the standard treats it differently from the primary account number. A PAN can be stored if it is protected, truncated, tokenized, or rendered unreadable. The CVV cannot be stored at all after the authorization response is received.
PCI DSS CVV Test Example Guide
Merchants sometimes assume this rule only applies to databases. It applies to every location where the value can appear: application logs, debug output, error messages, web session storage, email receipts, call center notes, and printed batch reports from point-of-sale terminals.
cvv test for pci dss requirements
Which PCI DSS requirements a CVV test maps to
- Requirement 3.3.1 states that sensitive authentication data is not stored after authorization, even if encrypted.
- Requirement 3.2.1 limits account data storage and retention time to what is required for legal, regulatory, and business needs.
- Requirement 4.2.1 requires strong cryptography to protect account data, including SAD, during transmission over open, public networks.
- Requirement 10.3 requires audit logs for access to system components, which means the environment must be built so the CVV itself never lands in those logs.
- Secure coding controls (Requirement 6.2.4 in PCI DSS v4.0) require development teams to prevent payment data from being written to debug output or error handlers.
How to run a CVV validation test
- Trace the data path. Start at the payment form and follow the CVV through the browser, the application server, the gateway integration, and the authorization response. Document every hop.
- Inspect browser behavior. Confirm the field is not cached, that autocomplete is disabled for the CVV input, and that nothing writes the value into session storage or local storage.
- Review application logging. Search source code and log configurations for request body logging, exception handlers, APM agents, and WAF payload capture. Any of these can retain the value without anyone noticing.
- Check transmission. Verify the checkout page and every downstream connection use TLS 1.2 or higher, and that no fallback to plain HTTP exists.
- Test with a live or sandbox transaction. Submit a card-not-present authorization, then search the database, log platform, and file system for the value you entered.
- Repeat after every release. A passing test today does not survive a new logging library or a gateway upgrade.
Common CVV test failures
- Full request bodies written to application logs during error handling.
- APM and real user monitoring tools capturing form fields by default.
- Gateway integrations that echo the submitted payload back in a webhook or reconciliation file.
- Customer service platforms that let agents paste the CVV into a note field.
- POS or terminal reports that print the verification value on a batch detail line.
- Tokenization projects that migrate the CVV along with the PAN.
Evidence to keep for a QSA or acquirer
An assessor rarely accepts a verbal assurance. Keep a written data-flow diagram, a source code review record, a configuration screenshot showing that logging is disabled for the CVV field, the query you ran against production logs, and a dated test result. If your environment uses a third-party gateway, request a current Attestation of Compliance or PCI SSC listing so responsibility for CVV handling is documented in the shared responsibility matrix. A complete CVV test and PCI DSS validation exercise ends with that paperwork, not with a green checkmark on a test script.
Does the CVV ever need to be stored?
No legitimate authorization or settlement process requires it. Recurring billing, refunds, chargebacks, and subscription renewals all run on the stored PAN, a network token, or a scheme token. If a business process claims it needs the CVV later, that process is the problem to fix, not the rule to bend.