PCI Compliance for Call Centers and Phone Payments

Taking card payments over the phone puts your telephony, call recordings, agent desktops and the agents themselves in scope for PCI DSS. One rule is absolute: sensitive authentication data, including the card verification code, must not be stored after authorization, and that includes call recordings. Beyond that, compliance is mostly a question of scope. The less card data your agents hear, see and type, the less of your contact center you have to secure and assess.

This guide draws on the PCI Security Standards Council's (PCI SSC) guidance for telephone payments and maps the main points to PCI DSS v4.0.

Is a call center in scope for PCI DSS?

Yes, whenever card data passes through it. PCI DSS applies to every system component that stores, processes or transmits account data, and to anything connected to those components or able to affect their security. On a typical phone payment, that's a long chain:

• The phone line or SIP trunk carrying the caller's voice or keypad tones
• The phone system, call routing and any interactive voice response (IVR) system
• Call recording and quality monitoring platforms
• The agent's handset or softphone
• The desktop and application where the agent types the card number
• The networks connecting all of them

The PCI SSC's guidance is direct on the desktop point. When an agent hears card details and types them into a system, the endpoint where the data is entered is in scope.

What does the PCI SSC's telephone payment guidance cover?

The Council's Information Supplement: Protecting Telephone-Based Payment Card Data, version 3.0, was published in November 2018. It separates simple environments, such as a few phone lines and a standalone terminal, from complex ones such as call centers. It also distinguishes attended payments, where an agent stays on the call, from unattended ones handled by an automated system.

It covers call recordings, VoIP scope, scope-reduction technology, remote working and service providers. Because it predates v4.0, its requirement numbers follow v3.2.1, but its principles apply unchanged.

Can call recordings contain card details?

Card verification codes: no. Requirement 3.3.1 in PCI DSS v4.0 prohibits retaining sensitive authentication data after authorization, even if it's encrypted, and 3.3.1.2 applies that specifically to the card verification code. A recording of a caller reading out the three- or four-digit code is stored sensitive authentication data, whatever the file format.

The same goes for anything derived from a recording: transcripts, speech analytics output, quality review clips, backups and archives. If your existing recordings contain codes, finding and removing them is remediation work, not housekeeping.

The supplement discusses narrow cases where recordings can't be altered and sets strict conditions for them. Treat those as exceptions to agree with your assessor. The design goal should be recordings that never capture the code at all.

Card numbers in recordings are allowed, but they're stored cardholder data. That brings in the Requirement 3 protections for stored data, including retention limits and rendering the number unreadable wherever it's stored.

Pause-and-resume vs DTMF masking: which reduces PCI scope?

Manual pause-and-resume

The agent pauses the recording before the caller gives card details and resumes it afterwards. It's simple, but it depends on every agent remembering every time, and a missed pause captures the data. The supplement is clear that it doesn't reduce scope for agents, desktops or the wider phone environment. You'll also need regular checks of recordings to confirm pauses are happening.

Automated pause-and-resume

The recording pauses automatically, typically when the agent opens the payment screen. That removes human error from the pause itself. The agent still hears the card number and types it, though, so the agent, the desktop and the telephony stay in scope.

DTMF masking

With dual-tone multi-frequency (DTMF) masking, the caller enters card details on their phone keypad. The tones are intercepted and replaced with flat tones before they reach the agent or the recorder, and the digits are passed on for processing without the agent ever hearing them. The agent stays on the line to help but never sees the data either.

A well-designed and properly deployed masking solution can take agents, desktops, customer relationship management systems and recordings out of scope. You need to confirm that no card data reaches those systems in any form, including "DTMF bleed", where fragments of the original tones leak through. If the masking runs on your premises, the masking components and the telephony that carries unmasked tones to them stay in scope. If a service provider hosts it, much of the scope moves to them, and they become a service provider you manage under Requirement 12.8.

Transfer to an IVR or payment line

In an unattended model, the agent transfers the caller to an automated payment system and drops off or is muted. Run by a PCI DSS compliant provider, this gives scope benefits similar to masking. The trade-off is that callers who struggle get less help.

Are VoIP phone systems in scope for PCI DSS?

Yes, when they carry card data. The supplement states that where VoIP carries payment card data between a cardholder and an entity, the entity's systems and networks used for that transmission are in scope. That can include call control servers, voice gateways, session border controllers, recording servers, softphones and voice network segments.

The carrier's public network isn't part of your scope. Card data you send across public networks still needs strong cryptography, which is requirement 4.2.1 in v4.0.

In practice:

• Segment voice systems from the general corporate network.
• Harden, patch and monitor call control servers like any other in-scope server.
• Restrict and log administrative access to telephony platforms.
• Treat hosted telephony and contact center platforms as service providers: get their Attestation of Compliance and agree who is responsible for which requirements.

How should agent desktops be secured?

If agents type card data, their desktops are part of the cardholder data environment, and every applicable requirement follows. Key controls include:

• Masking card numbers on screen. Requirement 3.4.1 limits display to the BIN and last four digits unless a role has a documented business need to see more.
• A hardened, patched build with anti-malware running and settings users can't change.
• Unique accounts with strong authentication, and multi-factor authentication for administrative and remote access.
• Restrictions on copying, printing, screenshots and removable media where card data appears on screen.
• Separation between the payment application and general email and browsing where you can manage it.

What does a clean-desk policy look like on a contact center floor?

Card data can leave a call center without touching a system. A number written on a sticky note, photographed or read aloud across a desk is just as exposed, and insider misuse is a realistic concern wherever many people handle card data.

The supplement lists items to keep away from positions where card data is handled, including notebooks, pens, mobile phones, recording devices and memory sticks. A workable clean-desk policy includes:

• No paper, pens or personal phones at payment positions, with lockers provided.
• A defined fallback for system outages. If paper is unavoidable, it's secured as media under 9.4.1 and destroyed when no longer needed under 9.4.6.
• Screens angled away from walkways and set to lock automatically.
• Regular supervisor checks, with the results recorded.
• Security awareness training that covers these rules, under Requirement 12.6.

How do you keep remote agents PCI compliant?

At home, the physical controls and supervision you rely on in the office are gone. Other household members may see screens or overhear calls, and the network is outside your control. Controls to put in place include:

• Company-issued, managed devices only, with no personal computers.
• Security controls on devices that connect to both untrusted networks and the cardholder data environment, which users can't alter (requirement 1.5.1).
• Multi-factor authentication for all remote network access that could reach the cardholder data environment (requirement 8.4.3).
• Technical controls that stop card numbers being copied or moved through remote access tools (requirement 3.4.2), a best practice until 31 March 2025.
• A private workspace where calls can't be overheard and screens can't be seen.
• Signed policy acknowledgments and specific training for home working.

The strongest control is architectural. If remote agents never hear or see card data because of DTMF masking or an IVR transfer, most of these problems disappear.

Frequently asked questions

Can agents write card numbers down if they shred them afterwards?

Avoid it. A written card verification code must be destroyed as soon as authorization completes, and in practice notes linger. Design the process so agents never need to write anything down.

Does DTMF masking take our call center out of scope completely?

Not necessarily. It can remove agents, desktops and recordings from scope if it's properly designed and verified, but whatever handles unmasked tones stays in scope. You still have to validate compliance for the phone channel, so confirm the scope with your assessor.

Do we need to deal with old recordings that contain card verification codes?

Yes. Sensitive authentication data must not be kept after authorization, so existing recordings with codes need to be found and the data rendered unrecoverable, including in backups and archives.

Which version of PCI DSS should our next assessment use?

PCI DSS v3.2.1 retires on 31 March 2024, so your next assessment will most likely be against v4.0. Its future-dated requirements are best practices until 31 March 2025, when they become mandatory.

Next steps

1. Map every path a phone payment takes, from the carrier to the processor.
2. Search call recordings, transcripts and archives for card verification codes and remove any you find.
3. Decide whether to reduce scope with DTMF masking or an IVR transfer, or to secure the full environment.
4. Segment and harden VoIP systems that carry card data.
5. Lock down agent desktops and enforce a clean-desk policy on the floor.
6. Apply specific controls and training for remote agents.
7. Get Attestations of Compliance and a clear responsibility split from every telephony provider.