A customer is halfway through a support call about a failed delivery when they decide to just pay the difference now, and they read their card number down the phone before anyone can stop them. Nobody asked for it. There is no payment flow in this call, no agent trained for it, no pause button pressed. The recording keeps running, and sixteen digits and a three-digit code are now sitting in your audio storage. That call took the same path as every other call: straight to disk, encrypted at rest, retained for ninety days. PCI compliance for call recording turns on exactly this moment, and nothing in your recording setup noticed it.
PCI compliance for call recording is the gap this exposes. If you ran a privacy review before switching recording on, it almost certainly did not catch this. Consent, redaction, residency, and retention are one regime, and the call recording compliance checklist covers it. Payment card data is a different one, with a different rule, and the difference is not a matter of degree.
Why is PCI compliance for call recording a different rule?
Most data protection questions are about handling: store it carefully, restrict who reads it, delete it on schedule. Answer those well and you are broadly fine. That is what a privacy checklist is for, and it is the right instrument for consent, identifiers, and retention.
Card data splits in two, and only one half behaves that way.
The card number itself — the PAN — can be stored, provided it is rendered unreadable and access is controlled and logged. Handling rules apply, and encryption is a legitimate answer.
The security code is not like that. The three or four digits on the card, along with full magnetic stripe data and PINs, are sensitive authentication data, and PCI DSS prohibits retaining them after the transaction is authorised. Not "retaining them insecurely". Retaining them. Encryption does not make it permissible, because the requirement is not about how well the data is protected — it is that the data should not still exist.
This is the part that surprises teams who have done everything else right. Every control you built for privacy is a handling control. You cannot handle your way out of a prohibition on possession.
How does card data get into your recordings?
Teams that think they are out of scope are usually thinking about the payment line only, which is the one place the risk is actually managed. The exposure is everywhere else.
- The unprompted read-out. As above: no payment was expected, so no control was armed. This is the most common route and the hardest to design against, because the customer does it before anyone can intervene.
- The agent-guided read-out on a call that was not a payment call. A billing query becomes a payment because it is convenient for everyone. The agent is being helpful, and the helpfulness is the incident.
- Keypad entry that was recorded anyway. Asking the customer to key the digits moves them out of speech and into DTMF tones — which, if your recorder captures the audio in-band, are trivially decodable back into the original numbers. Keypad entry only helps if the tones are actually suppressed or masked. Assume nothing here; verify it against a test recording.
Note what these have in common. None of them is a failure of the payment process. They are all calls that were never supposed to involve a card.
Where does PCI compliance for call recording break?
The standard control is to stop recording around the payment portion of a call. It works when it works. Two things routinely break it.
The first is that manual pause depends on an agent pressing a button while doing something else, on a call that may not have been flagged as a payment call at all. Any control that relies on a person remembering will fail at a rate you can predict but not reduce by asking people to try harder. Automatic pause, triggered by the payment application rather than the agent, removes the human from the loop and is worth the integration work.
The second is subtler and catches teams at audit. Having a pause-and-resume policy is not evidence that pause-and-resume happened. You are expected to be able to demonstrate it per call — that the gap exists, at the right point, on the specific recordings under review. If your system pauses but does not log the pause in a way you can produce and query afterwards, you have the control and not the proof, and at audit those are close to the same thing.
Recording stops when the payment application takes over, and the gap is logged per call so it can be produced at audit.
The customer reads the number out unprompted. No control was armed, because this was never classified as a payment call. Sixteen digits and a security code are now in storage, encrypted, and retained.
Redaction after the fact is not prevention
There is a tempting shortcut: keep recording everything, then run redaction over the transcript afterwards.
For privacy work this is often acceptable, and the existing Callix privacy checklist asks the right question about it — whether redaction happens before or after a human could read the transcript. For card data it does not clear the bar, for two reasons.
The transcript is not the recording. Redacting digits out of a text file does nothing about the audio, where the customer's voice is still reading the number aloud. The audio is the system of record here, and it is the thing that must not contain the data.
And after-the-fact means it was written first. If unredacted audio reached your storage, backups, or a vendor's processing pipeline before anything scrubbed it, it was retained — briefly, but retained, and usually in more than one place. Deleting it later is remediation, which is a good thing to be able to do and not the same as not having stored it.
The order matters more than the capability. Prevention happens before the write, or it is cleanup.
What should you actually do about it?
- 1Find out whether you have the problem before designing controls for it. Run the transcript search above, or ask us to run it with you. Most teams discover the exposure is real but narrow — a handful of calls a month on lines that were never meant to take payments — and that shape is much cheaper to fix than a general-purpose payment overhaul.
- 2Move payments off the recorded voice path entirely where you can. A payment link sent mid-call, or transfer to an automated line, is worth more than any amount of masking, because it removes the data from the channel instead of managing it there.
- 3Make pause automatic and triggered by the payment system, not the agent. Then check that the pause is logged per call and that you can retrieve the log for a named call in under a minute.
- 4Test DTMF suppression against a real recording rather than a settings page. Key a test card in, then pull the audio and confirm the tones are gone.
- 5Write the standing instruction for the unprompted read-out. Every agent should know exactly what to say when a customer starts reciting a card number on a non-payment call, and there should be a defined route for the recording that just captured it. This costs an afternoon and covers the most common case.
- 6Bound the blast radius. Shorter audio retention narrows the window in which an unnoticed capture can sit in storage, and the right period differs by the kind of operation you run, and it is the one mitigation that helps with the incidents you never detect.
PCI compliance for call recording is, in the end, a detection problem before it is a controls problem. The point of all this is not to become a payments company. It is that the calls creating your exposure are the ones nobody classified as payment calls, and those are found by looking rather than by policy. That search runs over every call you record, which is the only reason it is cheap.