PCI Compliance and Call Recording: Complete Guide

US reader? See the US version of this guide with US-specific compliance detail (TCPA, NYDFS, CCPA, FedNow, US PCI scope guidance).

If you record phone calls and take card payments, you've got a compliance problem to solve. The call recording system and the payment process overlap in a way that PCI DSS doesn't handle gently — cardholder data that ends up in your recordings brings your entire recording infrastructure into scope, and everything that touches those recordings along with it.

This guide covers what the rules actually require, where businesses go wrong, and how to build a recording setup that won't cause compliance trouble later.

Call Recording PCI Requirements at a Glance#

If you're searching for "call recording PCI" or "PCI call recording requirements," here's the short version before we get into detail. PCI DSS treats a call recording that contains cardholder data exactly the same as any other storage system holding card numbers. The audio file is in scope. The server it sits on is in scope. The backup tape, the cloud bucket, the QA workstation, the email someone forwarded it to — all in scope.

The PCI call recording rules don't have their own section in the standard. They're applied through the general requirements for stored cardholder data, encryption, access control, and logging. That's why so many businesses miss them — there's no checklist called "call recording" to tick. You have to read Requirements 3, 4, 7, 8, 10, and 12 and work out how each one applies to your recording platform.

The shortest accurate summary of PCI call recording requirements:

• Don't record the card number or CVV. If you can avoid storing it, do. The standard prohibits storing the CVV/CAV2/CID/CVC2 after authorisation under any circumstances. A recording is storage.
• If you must record around payment, prove the sensitive data isn't captured. Pause-and-resume needs documented evidence on every call, not just policy.
• Encrypt recordings at rest with AES-256 or equivalent. TLS 1.2 minimum in transit.
• Restrict and log every access. Unique IDs, role-based permissions, audit trails for every playback and download.
• Retain only as long as necessary, then securely delete. Indefinite retention of recordings with card data is a finding waiting to happen.

We'll walk through each of these in detail, but if you're skimming for a one-page answer to "what does PCI DSS say about call recording," that's it. Now the detail.

What PCI DSS Requires When You Record Calls#

The Payment Card Industry Data Security Standard was built to protect cardholder data wherever it exists — and call recordings count. If a customer reads out their card number during a recorded call, that recording is now a cardholder data storage system. The same requirements that apply to your databases and payment terminals apply to that audio file.

Organisations that record calls containing payment data need to comply if they:

• Record phone conversations where cardholder data is spoken or entered
• Store recorded calls with payment card information on their systems
• Process card transactions during recorded calls handled by agents
• Run contact centre operations where agents take payments over the phone

The cardholder data that matters most is the Primary Account Number — the 13–19 digit card number. But the rules also cover the cardholder's name, expiry date, and service code if those appear in recordings. Any of these in an audio file triggers the same obligations as storing them in a database.

The Four PCI DSS Requirements That Hit Hardest#

Requirement 3: Protecting stored cardholder data

Any recording that contains cardholder data must be encrypted in storage using a strong cryptographic algorithm — AES-256 is the standard. The recordings can't just sit on a server; they need encryption at rest, proper key management, and a defined retention policy. Data that isn't needed should be deleted securely. PCI DSS is explicit that organisations should store cardholder data only for as long as there's a legitimate business reason, and no longer.

Requirement 4: Encrypting data in transit

When recordings move between systems — from recording server to archive, from local storage to cloud — they must be encrypted in transit. TLS 1.2 or higher is the minimum. This applies to cloud backups, remote access to recordings, and any sharing of call files with third parties. Sending an unencrypted call recording by email would be a clear violation.

Requirement 7: Restricting access to cardholder data

Not everyone in your organisation should have access to call recordings that contain payment data. PCI DSS requires that access is limited to people who have a genuine business need for it — quality assurance teams, compliance staff, managers reviewing specific disputes. Each person who can access recordings needs a unique user ID, and the system should support role-based permissions so that access is granted by job function, not by who asks.

Multi-factor authentication for any system holding sensitive recordings is now strongly expected under PCI DSS 4.0.

Requirement 10: Tracking and monitoring access

Your recording system needs to log who accessed what, when. Every playback, every download, every administrative action should generate an audit trail entry with a timestamp and user ID. Failed login attempts should trigger alerts. These logs need to be retained — PCI DSS sets a minimum of 12 months, with three months immediately available — and reviewed regularly.

Want to see this working in your setup? Book a working-demo call — we'll wire up your actual phone system and show you a live capture.

Where Businesses Get Into Trouble#

Many contact centres implement a "pause-and-resume" policy: agents are supposed to pause the call recording before asking for card details, then resume once payment is complete. In theory this keeps cardholder data out of recordings. In practice, it relies entirely on agents remembering to do this correctly on every single call, under time pressure, with no technical enforcement.

When this fails — and it does fail — the recording captures the card number. One missed pause in a thousand calls is enough to bring your entire recording history into scope. Pause-and-resume is recognised by PCI DSS as a valid approach, but the standard also requires strong controls and audit mechanisms. Without those, it's a liability rather than a solution.

Legacy recording systems without encryption

Older call recording platforms often store audio files without encryption, or with encryption that doesn't meet current standards. Many businesses don't realise this until they go through a PCI assessment and discover that years of recordings are stored in a way that fails basic requirements. Remediation at that point is expensive — both the technical work and the ongoing compliance overhead.

Overly broad access to recordings

It's common to find organisations where anyone with a manager login can access the full call recording archive. Under PCI DSS, access needs to be tied to specific job functions and limited accordingly. A broad "manager" permission that covers both routine QA and sensitive payment recordings doesn't meet this requirement.

No retention policy in practice

Recordings often pile up indefinitely because there's no automated process to delete them after the business retention period expires. Every recording containing cardholder data that's kept longer than necessary is a stored risk. The data that doesn't exist can't be breached.

PCI Call Recording Retention: How Long Can You Keep Recordings?#

This is one of the most-asked questions we get, and the answer isn't a fixed number. PCI DSS Requirement 3.1 says you must keep cardholder data only as long as required for legal, regulatory, or business reasons. There's no PCI-mandated retention period for call recordings — the standard tells you to define your own and stick to it.

In practice, retention windows vary by sector. Financial services firms in the UK typically keep call recordings for five to seven years to meet FCA requirements. Retailers often keep them for 30 to 90 days for dispute resolution. Insurers tend to keep them for the policy lifecycle plus a buffer. Whatever you pick, three rules apply:

• Write the policy down. A QSA will ask to see it. "We keep recordings as long as we need them" isn't a policy.
• Automate the deletion. Manual deletion gets skipped. Schedule it.
• Separate recordings with card data from recordings without. If your platform can tag the calls where payment happened, you can apply a shorter retention to those specifically and reduce your scope.

The cleanest answer to the retention question is the one we keep coming back to: if the recording never contained card data in the first place, the retention conversation only covers the operational reasons to keep it. You're not balancing PCI risk against QA value — you're just deciding how long QA needs the file.

Call Recording PCI Scope: What Gets Pulled In#

Scope is the word that decides how much PCI DSS work you're doing. Every system that stores, processes, or transmits cardholder data is in scope. Every system connected to those systems is in scope. Your auditor's job is to draw the line, and your job is to keep that line as small as possible.

When a call recording contains card data, the scope ripples outwards:

• The recording server itself
• The storage array or cloud bucket the recordings sit on
• The backup system that copies them
• The QA workstation that plays them back
• The network segments those systems sit on
• The identity provider that authenticates access
• The logging system that captures access events

That's a lot of infrastructure to harden, monitor, and prove compliant. For most contact centres, the recording platform is the single largest expansion of PCI scope they have. Shrinking it is the highest-use scope reduction work you can do.

The two ways to shrink it: stop recording during payment (pause-and-resume, with all its agent-dependency risks), or stop the card data from ever entering the call stream (DTMF masking and channel separation). The second approach removes the entire chain of dependent systems from scope, not just the recording itself.

What Changed in PCI DSS 4.0.1 for Call Recording#

PCI DSS v4.0 went live in March 2024, and v4.0.1 is the current version as of 2026. Most of the changes that affect call recording are tightenings of existing controls rather than brand-new requirements, but there are a few you should know about.

Stronger authentication for recording access. Multi-factor authentication is now required for all non-console administrative access to systems in the cardholder data environment, including recording platforms. Single-factor login for a manager who can play back card-data recordings doesn't meet v4.0.1.

Targeted risk analyses. v4.0 introduced the concept of a Targeted Risk Analysis — a documented assessment for any control where you're using a customised approach. If you're using pause-and-resume as your control, you now need a documented risk analysis explaining how you're managing the residual risk of agent error.

Continuous evidence. Several requirements moved from "check annually" to "verify continuously." Access reviews for recording systems, log reviews, and key rotation evidence all sit under the continuous bar now. A spreadsheet updated once a year isn't sufficient.

Stricter scoping of service providers. If you use a third-party recording platform, your contract needs to clearly assign responsibility for each PCI requirement. The shared responsibility matrix has to be specific to your setup, not a generic vendor template.

For the broader picture of what changed, see our PCI DSS 4.0 changes guide. The summary: the bar went up, especially around authentication, logging, and documented evidence.

UK and EU Considerations: Recording Consent and Card Data#

PCI DSS is global, but the rules around recording calls in the first place are local. In the UK and EU, call recording sits inside UK GDPR / EU GDPR, the UK Privacy and Electronic Communications Regulations (PECR), and — for financial services — the FCA's recording requirements under SYSC 10A.

The interaction with PCI gets interesting when card data appears in those recordings. Under GDPR, the card number is special category personal data when combined with the cardholder's name. Storing it in a recording without a lawful basis and without appropriate technical safeguards is both a PCI failure and a GDPR failure. Two regulators, two sets of fines.

The FCA's recording rules require firms to keep recordings of relevant calls for at least five years (longer if requested by the FCA, up to seven). That retention obligation collides head-on with PCI's "retain only as long as necessary" principle. The only clean resolution is to not capture the card data in the first place — meet the FCA retention rule with a recording that contains no PAN, no CVV, and no expiry date. PCI scope falls away.

For contact centres serving EU customers, the European Data Protection Board has been increasingly direct about the use of pause-and-resume as a control. The 2024 guidance on payment data in customer service essentially says: if you have technical means to keep card data out of the recording, use them. Manual pause is acceptable as a fallback, not as a primary control.

US Specifics: HIPAA, State Laws, and PCI Together#

For US readers — our US version of this guide covers the detail. The headline points for call recording PCI compliance in the US:

• State two-party consent rules in California, Florida, Illinois, Massachusetts, Pennsylvania and others require both parties to consent to recording. That's about recording at all — PCI then applies to what's in the recording.
• HIPAA-covered entities taking payment over recorded calls face a double burden: PHI in the recording is HIPAA's problem, card data is PCI's. Both need addressing.
• NYDFS Part 500 applies to financial services firms in New York and adds an additional layer of cybersecurity requirements on top of PCI for recording platforms.
• TCPA doesn't touch PCI directly but affects how you handle the consent record itself — which is often in the same recording system.

All of the controls above are legitimate ways to manage the risk of having cardholder data in call recordings. But there's a more effective approach: don't let card data into your recordings in the first place.

DTMF masking solves this differently. When Paytia handles the payment portion of a call, customers enter their card details using their phone keypad. The DTMF tones those keypresses generate are intercepted before they reach your recording system. The agent stays on the line, the customer never has to read out card data, and the recording captures the conversation without ever touching the payment digits.

From the recording's point of view, there's nothing to redact because there was never anything sensitive there in the first place. The recording infrastructure falls out of PCI scope because no cardholder data ever passes through it.

Comparing the Three Approaches#

Most businesses end up choosing between three options. Here's how they stack up on PCI scope, agent dependency, and operational cost.

Pause-and-resume

The cheapest to implement but the riskiest in practice. Recording infrastructure stays fully in PCI scope. Compliance depends on agents pausing correctly on every call. One missed pause can compromise an entire archive. Documentation overhead is high — you need policy, training records, exception logs, and audit evidence on every call.

Automated audio redaction

A middle path where software detects card data in recordings after the fact and bleeps or removes it. Better than relying on agents but still leaves the unredacted original somewhere in the pipeline. Recording infrastructure is still in scope while detection runs. Detection isn't 100% accurate, and the failure modes are silent.

Channel separation / DTMF masking

Card data never enters the recording stream. The recording captures the conversation, the payment system captures the payment, and the two are processed on separate channels. Recording infrastructure can sit outside PCI scope entirely. Agent dependency on PCI controls drops to near zero. Higher initial setup cost than pause-and-resume, lower ongoing compliance overhead by a wide margin.

For a deeper comparison see channel separation vs DTMF suppression — they sound similar but the technical architecture is different in important ways.

What This Looks Like in Practice#

A contact centre handling 50,000 calls a month with payments on roughly 30% of those calls is looking at 15,000 recorded payment interactions a month. Under pause-and-resume, every one of those is a potential PCI exposure. Even a 99.9% agent compliance rate means 15 recordings a month captured card data they shouldn't have.

With channel separation in place, that number is zero. The recording captures the customer's voice and the agent's voice, the keypad tones go to the payment processor, and the audit trail shows that no card data ever touched the recording platform. The recording system can sit outside the cardholder data environment, which removes it from quarterly vulnerability scans, annual penetration tests, and the bulk of PCI documentation work.

The Practical Compliance Checklist#

For organisations already recording calls and wanting to know where they stand, here's a starting point:

• Audit your existing recordings: do any of them contain cardholder data? If yes, where, and how is access controlled?
• Map your recording system into your network: what other systems can reach it? Are they in your PCI scope or has someone assumed they aren't?
• Check encryption: are recordings encrypted at rest with AES-256? Encrypted in transit with TLS 1.2 or higher?
• Review access logs: do you actually know who's been listening to what? Are those logs reviewed?
• Check retention: how long are recordings kept, and is that consistent with what your data protection policy says?
• Test pause-and-resume if you use it: pick 20 recent payment calls at random and verify the pause was triggered correctly.
• Plan scope reduction: what would it take to keep cardholder data out of recordings entirely?

That last point is where most of the real improvement comes from. Pause-and-resume can pass audit if it's documented and monitored, but it's a fragile control. The businesses that don't worry about call recording PCI compliance are the ones that designed the problem out of their workflow.

If you want to see what removing card data from the recording stream looks like for your specific setup, we run working demos against your actual phone system. We connect to your platform, run a test transaction, and show you the recording with no card data in it. The audit trail shows where the digits went instead. Most calls take 30 minutes.

Frequently Asked Questions#