If you record customer calls and you take card payments over the phone, the two activities collide in ways that can quietly put you out of PCI DSS compliance. The short version: PCI DSS allows call recording, but it prohibits recordings from containing card numbers, CVVs, or PINs. How you achieve that in practice is the interesting question — and the answer is a lot more architectural than most businesses realise.
PCI DSS 4.0.1 has been in force since 31 March 2025, and it sharpened the rules around call recording alongside several other contact-centre-relevant controls. This guide covers what the standard actually requires, what the common half-measures are missing, and five practical steps for getting call recording right.
Key takeaways
- PCI DSS allows call recording — but recordings must not contain primary account numbers, CVVs, or PINs in audio or any other form.
- Pause-and-resume recording is common, widely used, and widely broken in practice. Agents forget to pause, and every miss is a control failure.
- Technical masking architectures (DTMF Suppression, Channel Separation) prevent card audio from reaching the recording in the first place — agent behaviour doesn't matter.
- Access controls, encryption, and retention policies all need to cover the recording archive, not just live systems.
- Annual compliance validation isn't enough. The recording pipeline needs ongoing sanity checks, because one configuration change can silently break the whole thing.
Why this matters
Call recording serves real business purposes — quality assurance, training, dispute resolution, regulatory evidence. None of those are at odds with PCI DSS. What the standard prohibits is the specific combination of a recording system plus cardholder data appearing together in the archive. Sensitive Authentication Data (SAD) — the CVV, full magnetic stripe content, and PINs — cannot be stored after authorisation under any circumstances. Primary Account Numbers (PANs) can be retained only under strict controls and usually shouldn't be in audio at all.
A non-compliant recording setup doesn't just create a theoretical audit risk. When a recording breach happens, the whole archive becomes evidence in the incident — and archives can easily be thousands of hours deep. The remediation work for a single configuration drift on a recording system has, in several cases we've seen, stretched to months.
1. Keep card data out of the recording — at the audio level
The most reliable way to make a recording PCI compliant is to ensure card data never enters it. That's what the two standard architectures do:
DTMF Suppression intercepts the keypad tones as the customer presses digits and masks them before they reach the agent's audio stream or the recording. The recording captures a placeholder tone or silence for the duration of the payment. The agent stays on the line and can still talk the customer through the process — they just don't hear the digits.
Channel Separation splits the call during the payment step, routing the customer's audio on a separate channel to Paytia rather than to your telephony. The recording continues, but captures only the parts of the call that weren't the payment. A voice assistant guides the customer; the agent stays on the main call.
Either approach produces a recording that is, by design, PCI compliant. It doesn't depend on an agent remembering to do anything.
2. Don't rely on pause-and-resume
Pause-and-resume recording is the half-measure most contact centres have tried. The agent hits a button when the payment starts, hits another when it ends. On paper the card isn't in the recording. In practice, we've reviewed audit data where 4–7% of payment calls have the pause missing entirely, which means full card numbers sit in the archive.
Pause-and-resume also has a subtler failure mode: agents sometimes start the pause too late, catching the first digits of the card number on the way in. At that point the "pause" has still been triggered but the recording contains a partial PAN, which auditors treat as card data regardless. Manual controls depending on agent behaviour aren't a reliable basis for compliance with a 329-control standard.
3. Lock down the recording archive itself
Even with card data out of the audio, the recording archive still holds customer conversations that are personal data under UK GDPR. PCI DSS requires that access to systems handling cardholder data uses multi-factor authentication — and in 4.0.1, that expectation has tightened to cover admin consoles and workforce management tools that can view or export recordings.
Practical controls look like: role-based access with least-privilege defaults, MFA on recording admin interfaces, audit logging of every access event, and documented retention policies with automated deletion. If a QA analyst can pull a random payment call from six months ago without any access trail, that's a control failure even if the audio is clean.
4. Encrypt recordings at rest and in transit
PCI DSS requires strong encryption for stored payment data. Recordings that contain any cardholder data — including partial PANs that slipped past pause-and-resume — fall under this requirement. Encryption at rest (typically AES-256) protects the archive from a storage-layer breach; TLS 1.2 or higher protects recordings as they move between the recording system and the archive, or between the archive and a review tool.
This one is usually a technical ticket for your telephony vendor rather than something you configure yourself. But it's worth confirming, because older recording platforms sometimes store audio files on open SMB shares with no encryption at all. We've seen that in live environments more than once.
5. Test the controls regularly — not just annually
Annual compliance validation gives you a point-in-time picture. The problem with recording systems is that configuration drifts silently. A telephony platform upgrade changes how DTMF tones are handled; a QA tool update changes access permissions; a retention rule gets tweaked and suddenly old recordings linger longer than they should.
A practical testing cadence looks like: monthly functional testing of the masking or suppression mechanism (pick a random recent payment call and verify the audio is clean); quarterly access control reviews (confirm that people who left the business have had their recording access revoked); and annual formal compliance audits as part of your wider PCI DSS work.
Set up the test schedule as part of your compliance calendar and have someone actually do the checks. "We'll test when someone flags a problem" is how recording compliance breaks.
Common failure modes
A few patterns we see regularly:
Manual pause systems that rely on agents remembering. As above, this has a measurable failure rate.
QA tools with broad access. A quality team member who can pull any call from any agent from any date is a data protection liability, not just a PCI concern. Access should be scoped to what the role actually needs.
Undocumented retention policies. Recordings are kept "just in case" with no defined retention period. Under PCI DSS and UK GDPR, both require a justified retention period, not an indefinite default.
Unencrypted backup chains. Primary storage is encrypted but the nightly backup to a secondary system isn't. A breach of the backup is functionally a breach of the primary.
Staff who can export audio. Agents or supervisors with a "download recording" button have a data-exfiltration path. The button needs approval workflow or it needs to not exist for their role.
How Paytia handles this
Paytia's DTMF Suppression and Channel Separation both keep card audio out of your recording by design. The recording captures the whole conversation including the parts where the customer is entering the payment — just with the card audio replaced by a placeholder tone. The agent stays on the call throughout, so the conversation continuity that makes recordings useful for QA and dispute resolution is preserved.
Because the card data never reaches your telephony, your agents, or your recording infrastructure, the compliance footprint collapses. Most of our customers move from SAQ D (329 controls) to SAQ A (22 controls) as part of the deployment — and the recording pipeline is the single biggest contributor to that reduction.
If you'd like to walk through where your current recording setup sits against PCI DSS 4.0.1 — and what the practical steps look like for your specific telephony stack — get in touch. We can help you scope the gap before you commit to any architectural changes.
