CVV Test for PCI DSS: Compliance Instructions

A CVV test for PCI DSS instructions should focus on one goal: proving that your payment environment does not store the card verification value after authorization. PCI DSS classifies CVV, CVC, and CID values as sensitive authentication data, so the test is about non-retention and evidence, not about generating, validating, or trading CVV numbers.

CVV Test for PCI DSS: A Comprehensive Guide

What PCI DSS requires for CVV data

PCI DSS Requirement 3 limits the storage of sensitive authentication data. The practical rule for most merchants and service providers is simple: do not retain the CVV after authorization, even if it is encrypted. If your business does not need the CVV after the payment decision, do not capture it in custom fields, notes, logs, analytics, or support tools.

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

• Do not store CVV after authorization. This includes databases, backups, queues, and data warehouses.
• Do not write CVV to logs. Error traces, debug logs, and application performance tools are common leak points.
• Do not copy CVV into business systems. Order notes, CRM records, chat transcripts, and email are out of scope only if they never receive the value.
• Do not use production card data in test environments. Use approved test card numbers from your acquirer or payment gateway.

What a CVV compliance test should check

A CVV test for PCI DSS is not a validity check on a card number. It is a verification that your people, processes, and systems do not retain the CVV. The review should cover the full card data flow from entry to authorization and settlement.

more on this topic

• Data flow: where the CVV enters, where it is transmitted, and whether it passes straight to the processor.
• Storage: databases, files, backups, message queues, logs, receipts, and reporting systems.
• Access: who can see sensitive authentication data and whether access is logged and approved.
• Third parties: gateways, call centers, fraud tools, chat vendors, and analytics platforms.
• Retention: purge schedules, masking rules, and deletion evidence.

How to run the test: step-by-step

1. Define scope and get approval. Identify the systems, vendors, and teams that touch card data. Coordinate with security, legal, and the payment processor.
2. Map card data flows. Draw the path from customer entry to authorization and settlement. Mark every point where CVV could be captured or copied.
3. Use approved test data. Use acquirer-provided or gateway-provided test card numbers in a sandbox. Never use real cardholder data in a test.
4. Inspect systems and logs. Review application code, database schemas, log files, backups, monitoring tools, and support tickets for CVV fields or values.
5. Review workflows. Check phone orders, chat, email, and manual payment entry. Confirm that staff cannot record CVV in free-text fields.
6. Record evidence. Keep redacted screenshots, query results, configuration exports, and interview notes. Evidence should show what you tested and what you found.
7. Fix and retest. Remove unnecessary fields, redact logs, update retention rules, and retest after any change to the payment flow.

Common failures

• CVV copied into order notes, CRM records, or support tickets.
• CVV exposed in debug logs, error messages, or monitoring dashboards.
• CVV retained in backups, data warehouses, or reporting extracts.
• CVV sent to analytics, chat, or marketing tools.
• Production card data used in development or QA environments.

Safe testing rules

Keep the test controlled and documented. Use only test cards from your acquirer or gateway, restrict access to the test environment, and redact evidence before sharing it with assessors. Do not attempt to validate random, stolen, or purchased CVV values. This guide is for legitimate PCI DSS compliance work and does not cover buying, selling, or validating cardholder data outside an approved payment environment.

Documentation that satisfies assessors

• Data-flow diagrams that show where card verification values enter and leave your environment.
• An inventory of systems, vendors, and teams that could touch sensitive authentication data.
• Query results or schema reviews showing no CVV storage fields.
• Log samples showing redaction and retention rules.
• Policies for access control, retention, and secure deletion.
• Remediation tickets and retest evidence for any issue found.