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. We've also written about the essential requirements for PCI compliant call recording.
This guide explains what the rules actually require, where businesses typically go wrong, and how to build a recording setup that doesn't create ongoing compliance headaches.
Key takeaways
- PCI DSS doesn't ban call recording — it bans recordings from capturing sensitive card data like full numbers and CVVs.
- Pause-and-resume is the most common approach but also the most common failure point — agents forget.
- Requirements 3, 4, 7, and 10 are the four PCI DSS clauses that directly affect call recording management.
- The most reliable approach is keeping card data out of the call environment entirely, so there's nothing to redact.
- Paytia's channel separation routes payment audio separately — card digits never appear in your recording.
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.
Where Businesses Get Into Trouble
The pause-and-resume failure
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.
The Better Approach: Keeping Card Data Out of Recordings Entirely
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.
This is where DTMF masking changes the picture. 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 suppressed before they reach your recording system — what gets recorded is silence or a neutral tone, not the card number. Your agent can't hear the digits, and your recording infrastructure never captures them.
Because no cardholder data enters your recording environment, your recording system isn't in scope for PCI DSS at all. The recording platform, the storage servers, the backup infrastructure, the staff with access to recordings — none of it falls within your PCI assessment boundary. That's a significant reduction in compliance complexity and cost.
Paytia is a PCI DSS Level 1 certified service provider, which means the payment processing side meets the highest tier of PCI requirements. The combination — Paytia handling payment data in its certified environment, your recording system capturing call audio with no payment data — is a clean architectural solution to the call recording compliance problem.
For the full story on why recording calls during phone payments gets messy, we wrote a separate post that walks through the common pitfalls.
If You Do Need to Store Recordings with Payment Data
There are circumstances where recordings containing payment information need to be retained — fraud investigations, dispute resolution, regulatory requirements in some sectors. In those cases, proper controls are essential:
Encryption at rest using AES-256 or equivalent, with key management processes that meet PCI DSS Requirement 3.6. This means documented key generation, storage, distribution, and rotation procedures — not just encryption turned on in your recording software.
Strict access controls tied to job function. Quality assurance staff reviewing agent performance should generally not have access to recordings that were flagged for fraud investigation. Separate roles for separate functions.
A tested retention and deletion policy. Recordings should be automatically flagged for deletion once the business retention period expires, and that deletion should be secure — overwriting or cryptographic erasure, not just removing a file pointer.
Detailed audit logging of all access to sensitive recordings, with alerts for unusual patterns such as large volumes of recording downloads or access outside normal business hours.
Technology Options for PCI-Compliant Recording
Businesses approaching this problem have several infrastructure routes:
Cloud-based recording platforms from established providers typically include encryption, access controls, and audit logging as standard features. The compliance burden shifts partly to the vendor, though you remain responsible for configuration and policy. Look for providers who are themselves PCI DSS certified as service providers — that certification means their infrastructure meets the standard, which simplifies your own compliance position.
On-premises recording gives you direct control over where data is stored and how it's protected, but all the compliance controls are your responsibility to implement and maintain. This works well for organisations with strong internal security capabilities and specific data sovereignty requirements.
Hybrid approaches — local recording infrastructure with cloud-based encryption, backup, and archiving — can combine the control of on-premises with the scalability of cloud. The compliance boundary needs to be carefully defined to ensure requirements are met at every point in the data flow.
The Compliance Case for Paytia's Approach
The most common question we get from contact centres working through their PCI DSS assessment is how to handle call recordings. The honest answer is that the easiest path is to remove the problem at source.
When we set up IVR payment flows or agent-assisted payments using Paytia's platform, card data goes straight to our secure, certified environment. Your call recording system captures the call — the agent greeting, the conversation, the payment confirmation — but not the card number. The DTMF tones are masked, and our system processes the payment separately.
Your QSA will ask what systems are in scope. The answer, for recording purposes, is: none that touch cardholder data. That's a much simpler assessment than trying to demonstrate that your recording platform's encryption meets PCI Requirement 3, that your access controls meet Requirement 7, and that your audit logging meets Requirement 10 — across every server and backup location where recordings might sit.
If you're going through a PCI assessment and call recording is flagged as a concern, talk to us. We can walk through how descoping works for your specific environment and what the implementation looks like.
Frequently Asked Questions
Does PCI DSS ban call recording?
No. PCI DSS doesn't prohibit recording calls where payment data is discussed. It requires that any recordings containing cardholder data are encrypted in storage, access-controlled, logged, and retained only for as long as necessary. The alternative is to prevent cardholder data from entering recordings in the first place, using DTMF masking.
Is pause-and-resume enough to achieve compliance?
It can be, if implemented with proper technical controls and audit mechanisms. PCI DSS recognises pause-and-resume as an approach, but relying on agents to remember without any automated enforcement is risky. A failed pause that captures a card number brings that recording — and everything that touches it — into scope.
How long do we need to retain call recordings?
PCI DSS Requirement 10 requires audit logs to be retained for at least 12 months, with the most recent three months immediately accessible. For recordings themselves, the retention period should be the minimum required for your business purposes — keeping recordings longer than necessary increases risk without benefit.
What does Paytia do that solves the call recording compliance problem?
Paytia uses DTMF masking to suppress card data before it reaches your recording system. Customers enter card details on their keypad, those tones are masked, and your recording captures silence rather than audible digits. The card data travels directly to Paytia's PCI DSS Level 1 certified environment, never entering your recording infrastructure.
