Last updated: September 12, 2026
This page describes a security standard and is not legal or assessment advice. Confirm every requirement number against the PCI DSS version your assessor works from.
What PCI DSS requires of a recorded payment call
Sensitive authentication data must not be stored after authorization, and the card verification code is sensitive authentication data. A recording is storage. Under PCI DSS v4.0.1 Requirement 3.3.1, a floor that records every call and takes card numbers by phone produces prohibited data by default, unless something stops the capture or deletes it on authorization.
Every other recordkeeping rule in the wider compliance set for a call center asks how long you have to hold the audio. This one runs the other way. Certain content is prohibited from surviving in the recording at all, and the clock it runs on is the transaction rather than the calendar.
That inversion is also why the rule gets broken quietly. A retention mistake turns up when somebody hunts for a call deleted early, while a verification code in a .wav file from last March waits for an assessor to ask where account data lives.
How sensitive authentication data differs from the card number
The standard splits account data in two. Cardholder data covers the primary account number, the cardholder name, the expiration date, and the service code. Sensitive authentication data covers full track data, the card verification code, and PINs or PIN blocks.
Which half a number falls in decides whether you may keep it. The account number can be stored, kept to a minimum under Requirement 3.2 and rendered unreadable under Requirement 3.5. Sensitive authentication data gets a flat prohibition once the transaction is authorized, even encrypted, and that holds even where no account number is present.
Requirement 3.3.1.2 describes the card verification code as the three or four digit number printed on the card, used to verify transactions where the card is not physically present. A phone order is exactly that, so the number gets asked for on every payment call.
Authorization completes when the merchant receives a transaction response, an approval or a decline. That lands mid call, with the recorder running and the caller still thanking somebody, so the prohibited state starts before the conversation ends.
Why a recording counts as storage
Requirement 3.3.1 reads that sensitive authentication data is not stored after authorization even if encrypted, and that all of it received is rendered unrecoverable once authorization completes. The standard marks that requirement ineligible for the customized approach, so no alternative design can be accepted in its place. Anything held before that moment is still stored data, and Requirement 3.3.2 wants it encrypted with strong cryptography.
Audio gets named twice, which surprises people who assume the standard is about databases. The scope section counts storage of account data in any format as a system component, with audio files among its examples, and the guidance beside Requirement 3.2.1 puts audio recordings among the storage locations most often overlooked.
PCI SSC FAQ 1210 addresses the audio case directly: storing card validation codes in any form of digital audio recording after authorization violates the requirement. Where technology exists to suppress or redact audio during data entry, turn it on, and securely delete the data on authorization where prevention failed. The FAQ also notes that PCI DSS does not override local or regional audio retention law, the one place two obligations genuinely pull against each other.
Transcripts inherit the problem and make it easier to exploit. The Council's telephone payments supplement treats anything a search tool can pull back as queryable, and says encryption alone does not fix that. A transcript in an index you can search by keyword is about as queryable as data gets, so the feature that makes quality review useful turns a missed card code into a two second lookup. Worth saying out loud on a page published by a company that sells transcripts.
Scope, and who ends up in it
The cardholder data environment covers the system components, people, and processes that store, process, or transmit account data, plus components with unrestricted connectivity to them. A recorder holding account data sits inside that boundary and drags its storage, its backups, and any vendor ingesting the audio in with it.
Prevention is worth real money for that reason. A properly implemented pause and resume setup can take the call recording and storage systems out of scope, according to the same supplement, while doing nothing for the agent, the agent desktop, or the rest of the telephone environment. The phrase "we descoped recording" is narrower than it sounds.
Answering services and outsourcers carry a version of this that belongs to somebody else, since you take payments in a client's name and their acquirer asks the questions. Retention rules sitting beside this one are on call recording retention by rule.
What an assessor asks
Six questions, roughly in the order they get asked.
| Question | What holds up as an answer |
|---|---|
| Where can a spoken card code enter your environment | A call flow naming every path, including transfers, voicemail, and your QA vendor |
| What stops it from reaching the recorder | The control, plus evidence it ran on a sample of real payment calls |
| What happens the day it fails | A documented secure deletion step and a record showing it ran |
| Does the transcript get the same treatment | Redaction applied to the text and to the search index behind it |
| Who can play back or export a payment call | Role scoped accounts and a log of what left the building |
| Which PCI DSS version are these answers written against | v4.0.1, with requirement numbers matching the version being assessed |
Requirement 3.2.1 adds a quiet one. Stored account data past its retention period gets verified as securely deleted at least once every three months, so somebody owns a recurring task rather than a policy.
Keeping card codes out of the audio
Three approaches show up in the field, and they hold up unevenly.
Manual pause and resume puts the control in an agent's hands. The supplement is blunt about the failure modes: forgetting to pause captures the data, and forgetting to restart loses the rest of the call and can break whatever recording obligation your client wrote into the contract. Manual setups also need a supervisor listening back to confirm the recorder stayed clean. This is the approach that fails, because it asks somebody reading a callback number back digit by digit with four calls in queue to hit a button at exactly the right second, twice, on every payment call of the day.
Automated pause and resume moves the trigger into the software, stopping the recording when the agent opens the payment screen and starting it again on submit. Effectiveness depends on how tightly it integrates with the workflow, since an agent who can work around the payment screen can work around the control. Detection and redaction after the fact is weaker again, because the data sat on disk until the cleanup ran.
Routing the payment away from the recorded channel holds up best, because the control stops depending on anyone's memory during a live call. The customer keys the digits and a masking layer replaces the tones with flat or random sounds before they reach the agent, or the call hands off to an IVR and comes back. Storing only suppressed tones can reduce how much of PCI DSS applies to you. Ask a vendor about detection lag, since some implementations let the leading edge of the first tone through, which the supplement calls DTMF bleed.
CallSniper scores recordings rather than redacting them, so prevention belongs in your telephony stack rather than in ours. What a review shows is whether the control actually ran, which most operators have never measured: a scored sample of your payment calls puts a timestamp on every call where a card code reached the audio, at a fixed pilot price.
Frequently asked questions
Can you record a call where the customer reads out a card number?
The account number may be stored under the minimization and unreadability rules in Requirement 3. Storing the verification code after authorization is prohibited outright, even encrypted, so a recording holding one has to be prevented or securely deleted.
Does PCI DSS say how long to keep call recordings?
No. It prohibits sensitive authentication data after authorization and wants account data storage kept to a minimum under a documented retention period. FAQ 1210 adds that the standard does not override local or regional audio retention law. Periods and citations sit on retention rules by industry.
Is a transcript treated the same as the audio?
Treat it as another copy. A transcript stored after authorization holds the same prohibited data as the .wav it came from, and a search index over it makes that data trivially retrievable, which the supplement describes as queryable.
Does pause and resume make you PCI compliant?
It is one control inside a much longer requirement set, and an assessor wants evidence it ran rather than a screenshot of the setting. Manual implementations draw the most scrutiny because they depend on the agent.
Sources
- PCI DSS v4.0.1, Requirements and Testing Procedures, June 2024. Requirements 3.2, 3.2.1, 3.3.1, 3.3.1.2, 3.3.2, and 3.5, Tables 2 and 3, and section 4 on scope. Read from the standard text on 2026-09-12. Verified.
- PCI Security Standards Council FAQ 1210, on audio recordings holding sensitive authentication data. Updated June 2025, retrieved 2026-09-12. Verified from the standards body.
- Information Supplement on protecting telephone based payment card data, version 3.0, November 2018, PCI Security Standards Council. Sections 5.2.5, 6.5.1, 7.2.6, and Appendix D, read 2026-09-12. Supplemental guidance that replaces no standard, and it predates v4.
- That v4.0.1 is the version in force for assessments in 2026. Secondary, from compliance industry summaries gathered 2026-09-12. Confirm with the assessor.
- Trinsic feature sheet and call notes, 2026-08-27 and 2026-09-03, for what CallSniper does with audio. Verified internally.