PCI IVR, DTMF Masking and Call Recording: Taking Phone Payments Out of Scope

A PCI IVR or DTMF masking service takes card numbers off your agents and out of your systems. The caller keys the card number and security code on their phone keypad, the tones are hidden from the agent and the call recording, and the digits go straight to a PCI DSS compliant payment provider. Designed well, that takes agents, desktops, call recordings and screen recordings out of PCI DSS scope. Whatever you choose, card security codes must never stay in a call recording after authorisation, even encrypted.

This QSA guide covers the payment technology and the call recording rules. For home agents, outsourced centres and assessment preparation, see our guide to contact centre PCI compliance; small businesses should start with taking card payments over the phone.

What is a PCI compliant IVR?

A PCI compliant IVR is an automated payment line, run by a provider that has validated the service against PCI DSS, where callers enter card details by keypad without speaking to anyone. “PCI compliant” describes the provider’s validated service, shown on its Attestation of Compliance (AOC), not a badge on a product. An IVR you host yourself is not descoped at all: it is part of your cardholder data environment (CDE).

Three questions decide whether an IVR reduces your scope:

• Who runs it? A provider-hosted IVR covered by the provider’s AOC can take the payment step out of your environment. An in-house IVR keeps it in.
• How does the call reach it? If the call, with card tones in it, crosses your own telephony or network first, those systems stay in scope.
• What comes back? A payment result or token is fine; card numbers returned to your CRM bring it into scope.

IVR, DTMF masking or agent-assisted payment: which is which?

Phone payment methods differ in who hears or keys the card data, and that decides your scope.

DTMF masking keeps the agent on the line to help; an IVR suits routine payments; links suit callers who prefer their own device.

DTMF PCI compliance: is DTMF masking PCI compliant?

Yes, DTMF masking is an accepted way to keep card data from agents and recordings, but compliance depends on the deployment. DTMF (dual-tone multi-frequency) tones are the sounds a keypad makes. A masking service intercepts them, passes the digits to the payment provider and replaces the tones with flat tones, so the agent sees fields fill on screen without hearing the numbers.

Where the interception happens matters most:

Two operational points matter. Callers sometimes read their card number aloud anyway, so agents need a script that moves them back to the keypad. And outages need a documented fallback, because reverting to agent-keyed payments puts agents back in scope.

What leaves PCI DSS scope, and what stays in?

Descoping removes systems from the CDE, not your responsibilities. These stay with you:

• Scope evidence. Data flow and call flow diagrams, and your annual scope confirmation under Requirement 12.5.2.
• Connected systems. Anything that starts payment sessions with the provider or receives results, such as a CRM integration, can affect the security of card data.
• Provider oversight. A list of providers, written agreements, a record of which requirements each one manages and an annual check of their compliance status (Requirements 12.8.1 to 12.8.5).
• Access to provider portals. Accounts that can view transactions or change configuration need strong authentication.
• People and process. Security awareness training, incident response and checks for card data arriving through other routes, such as email or web chat.

Our PCI DSS scoping guide explains how to define the CDE and the systems connected to it.

PCI compliance and call recording: can recordings contain card numbers?

PCI DSS call recording rules treat card numbers and card security codes differently. A recording may contain the card number (PAN) only where there is a genuine business need, and it is then stored account data. Security codes cannot be kept at all after authorisation.

The PCI SSC’s FAQ 1210 on audio recordings (updated June 2025) says keeping security codes in any digital recording after authorisation breaks Requirement 3.3.1, even if the files are encrypted. Its order of preference: stop security codes reaching recordings, using suppression or redaction technology where it exists; if that is impossible, securely delete them immediately after authorisation. Only where deletion is not possible for technical or business reasons does it accept compensating controls: at minimum an annual risk assessment, protection of the stored data, controls that block access to the data and queries of the recordings, and full documentation, all examined at every annual assessment. Treat that as a last resort, not a design choice.

For recordings that legitimately hold PAN, the protection has to apply to the recordings themselves, for example file-level encryption: disk or partition encryption alone no longer meets Requirement 3.5.1 on non-removable storage (3.5.1.2, mandatory since 31 March 2025). Whatever call recording software you use, apply the same rules to screen recordings, transcripts, speech analytics and voicemail.

Is pause and resume PCI compliant?

Yes, pause-and-resume can keep security codes out of recordings, but it does not take agents out of scope. The agent still hears the card details and keys them, so the agent, desktop, telephony and workspace stay in the CDE.

• Manual pausing relies on the agent remembering every time, and one missed pause puts a security code in a recording.
• Automatic pausing, triggered when the payment screen opens and closes, is more reliable, but it must also cover screen recording and any secondary recorders, such as quality monitoring tools.
• Evidence. Your assessor will sample recordings to confirm pauses work in practice, so sample them yourself first.

The PCI SSC information supplement Protecting Telephone-Based Payment Card Data (in the PCI SSC document library) compares pause-and-resume with descoping methods in more detail.

What should you ask a PCI IVR or DTMF masking provider for?

Whichever PCI IVR solution you choose, ask for these before you sign, and every year after:

1. A current AOC for service providers that names the exact service you use and the locations it runs from.
2. A responsibility matrix showing which PCI DSS requirements the provider meets for you, which you meet and which are shared (Requirements 12.8.5 and 12.9.2).
3. A written agreement in which the provider acknowledges its responsibility for the card data it handles (12.8.2).
4. A data flow diagram and outage fallback design, so you can draw your own scope boundary.

What does a QSA test on a phone payment channel?

A QSA tests whether descoping works in practice. We would typically:

• Walk through call flows and data flow diagrams with the people who run them.
• Place test calls with test card numbers, watching the agent screen and then listening to the recording.
• Sample recordings, transcripts and CRM notes for card data, including from home or remote agents.
• Check the provider’s AOC covers the service in use, and compare the responsibility matrix with your own controls.
• Review the agent script for callers who read numbers aloud, and the outage fallback.

The result shapes your validation route. SAQ A covers mail and telephone order merchants that have fully outsourced account data handling to PCI DSS compliant providers, so a phone channel where card tones never cross your own systems may qualify. Agent-keyed payments into a provider’s virtual terminal may fit SAQ C-VT if every condition is met. Larger contact centres often complete SAQ D or a Report on Compliance. Your acquirer confirms which applies, and our free PCI compliance check gives you a first view before you ask.

Why Sovereign Secure

Sovereign Secure Ltd, established in Lancashire in 2012, is approved by the PCI Security Standards Council as a Qualified Security Assessor (QSA) company, a Qualified PIN Assessor (QPA) and a Card Production Security Assessor (CPSA), and is a member of the PCI SSC Global Executive Assessor Roundtable (GEAR) for 2026 to 2028.

This guide names no products, because scope depends on how a service is deployed, not whose it is. Our PCI DSS consultancy team can review a phone payment design before you commit, and we assess the result as part of a formal assessment. Advisory and assessment work are kept separate, as the PCI SSC expects of a QSA company.

Check your phone payment scope

Tell us how your calls are routed and which recording and payment tools you use. We will set out what is in scope today, what masking or an IVR would change and your likely validation route, with a fixed quote for any help. Contact our PCI team or call +44 161 523 5276.