What is PCI DSS?

What it covers

PCI DSS provides a baseline of technical and operational requirements to protect payment account data. The PCI Security Standards Council says it is meant for entities that store, process or transmit cardholder data or sensitive authentication data, or that could affect the security of the environment that holds it. That includes merchants, processors, acquirers, issuers and service providers. The council sets the standard, and acquirers and payment brands apply it through their agreements, so it is not a statute. This page reflects version 4.0.1 of the standard.

Two terms matter here. Cardholder data includes the primary account number (PAN). Sensitive authentication data (SAD) includes the card verification code printed on the card, such as the CVV2, CVC2 or CID, which exists to prove the card is in the payer’s hand.

What it requires

Requirement 3.2.1 asks that storage of account data be kept to a minimum through data retention and disposal policies, procedures and processes. Requirement 3.3.1 says SAD is not stored after authorization, even if it is encrypted. Cardholder data such as the PAN may be kept after authorization only where there is a business need and, for the PAN, only when it is rendered unreadable. SAD may not be kept.

The Council has applied this directly to calls. In FAQ 1210 it says that storing a card validation code in any digital audio recording, such as a .wav or .mp3 file, after authorization is a violation of Requirement 3.3.1. If such data is collected during a call, every effort must be made to prevent it from being recorded, and where technology exists to suppress or redact audio during data entry it should be enabled. If recording cannot be prevented, the data should be securely deleted immediately after authorization. Where deletion is not possible, compensating controls are the fallback. The FAQ also states that PCI DSS does not override local or regional audio retention laws.

What it means for a voice agent

A voice agent is a new place for card data to spread. Digits that a caller speaks, or keys in, can appear in call audio, a transcript, a prompt sent to an LLM, a tool call, a webhook payload, an analytics store and a vendor’s logs. Each copy raises the question of whether it falls inside your PCI scope.

Common approaches are to hand the caller to a payment flow that stays outside the agent, or to collect digits by keypad tones that are masked from the audio (DTMF), so the agent never hears or stores them. Whatever the design, check what call recording captures during the payment step and how the pieces are kept and deleted (data retention). A vendor’s SOC 2 report does not show PCI status. Ask for the vendor’s PCI attestation if it is in your card data path. For banking examples, see the guide on conversational AI in banking.

Questions to ask counsel

1. Do we store, process or transmit card data in this flow, or can we keep the agent out of scope?
2. Which assessment or attestation applies to us, and what do our acquirer and card brands require?
3. How do we prevent card digits from reaching recordings, transcripts, prompts and logs?
4. What do we do if a recording already holds a verification code?
5. Which vendors in the call path must give us evidence of their own PCI status?

Related terms

• Data retention
• Call recording
• DTMF
• Zero data retention
• SOC 2

Guides

• Conversational AI in banking: customer calls

Use cases

• Phone payments
• Financial services

Sources

• PCI Security Standards Council, PCI Data Security Standard (PCI DSS)
• PCI SSC FAQ 1210, Are audio/voice recordings permitted to contain sensitive authentication data?