PCI Compliance for Telephone Payments: 2026 Guide

Last updated: 29 May 2026

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

If your contact centre takes card payments by phone, PCI DSS applies to you. v4.0.1 has been mandatory since March 2025, and a year in, the bar for "compliant" has moved up sharply. Three questions come up on almost every prospect call I take — what does the standard actually require for a phone payment, why is pause-and-resume recording suddenly being challenged, and which architecture choice keeps the audit small without rebuilding the contact centre? This piece works through all three.

I'm writing from inside a PCI DSS Level 1 service provider that's held that certification every year since 2016, so the focus here is what works in production, not what reads well on paper. We see this from the inside on hundreds of UK contact centres a year — housing associations, insurance brokers, debt-collection agencies, FX bureaux, charities, NHS trusts, parking-fine processors. The pattern repeats. The teams that get to a small, defensible audit are the ones that picked an architecture that takes the cardholder data out of their environment entirely. The teams that struggle are the ones who tried to harden the environment around the data instead.

What PCI compliance means for telephone payments#

PCI DSS — the Payment Card Industry Data Security Standard — applies to any organisation that stores, processes, or transmits cardholder data. There's no exemption for telephone channels. There's no exemption for "we just take the card details once and put them straight into the gateway." From the moment a customer reads their PAN aloud, your agent's headset, the call recording, the desktop, any screen-share session, the network the call traverses, and every system any of that touches are all in scope. That's the bit most teams underestimate the first time round.

Two things matter in 2026. v4.0.1 has been mandatory since 31 March 2025 — a limited revision of v4.0 with corrections and clarifications, several of which bite hardest in contact-centre environments. And the SSC's Information Supplement on Protecting Telephone-based Payment Card Data is still the canonical scoping reference. It's explicit that telephone environments are PCI scope, that pause-and-resume recording on its own isn't a complete control, and that the cleanest path to limited scope is a technical architecture that keeps cardholder data out of the agent leg.

The regulators behind PCI in the UK

PCI itself isn't a regulator — it's a contractual standard the card schemes enforce through your acquiring bank. But in the UK, three statutory bodies sit behind it and turn a card-data incident into a regulatory event quickly.

The ICO is the obvious one. Cardholder data is personal data under UK GDPR, so any breach involving card numbers triggers a 72-hour notification obligation under Article 33. The ICO's fining powers are material — up to 4% of global turnover or £17.5 million, whichever is higher — and the published decisions show they take inadequate technical controls seriously. The Marriott decision, the BA decision, the Interserve decision: all three turned on insufficient hardening of the systems that processed personal data.

The FCA's operational resilience regime applies if you're regulated. The 2022 rules require firms to identify "important business services" and prove they can recover within agreed impact tolerances. For a firm where phone-based card collection is the primary cash-in channel, that's an important business service almost by definition. A PCI breach that takes payments offline for a fortnight is exactly the scenario the FCA wrote those rules for.

UK Finance sits alongside the regulators as the trade body, and its guidance on contact-centre fraud (revised in 2024) explicitly references DTMF masking and IVR as the channel-separation patterns members should be moving to. It's not a rule, but acquirers read it.

The schemes and the acquirer's role

The card schemes themselves — Visa, Mastercard, American Express, Discover, JCB — enforce PCI through your acquiring bank. The acquirer is who issues your annual SAQ or asks for your AOC, who raises your transaction fees if you fall out of compliance, and who passes through scheme fines after a breach. Penalties for non-compliance show up as scheme fines (typically £5,000 to £100,000 per month of non-compliance), raised transaction fees, and, after a breach, mandatory forensic-investigation costs that routinely run six figures before a single consumer is contacted.

The 2025 enforcement pattern we're seeing is acquirers asking for a fresh AOC or a current SAQ at renewal, not just at onboarding. If you were on SAQ-D in 2023 and your acquirer hasn't asked since, expect the question this year.

How card data leaks on a phone call#

Before the architecture conversation, it helps to be specific about the threat model. Card data on a phone call leaks in four places, and any control regime has to close all of them.

The agent leg

The agent is the obvious one. The agent hears the digits, can write them down, can repeat them back, can mention them on a personal call later in the day. Human-error data loss is the largest single source of confirmed contact-centre incidents in the public record — nothing close. Most published breaches we've reviewed in the last 18 months started with a single agent writing a PAN on a notebook, photographing it, or sending it via personal messaging. Background checks, agent training, monitored desktops — they all help. But they're probabilistic controls in a regime that has to be deterministic.

The call recording

The call recording is the second. If full PAN, expiry, or CVV ends up in a recording, the recording itself becomes scoped data. Every backup, every QA platform, every supervisor's desktop that ever opens the file gets pulled in too. This is the hidden cost teams miss when they cost up "a quick pause-and-resume add-on." The retained recording library is typically the largest single repository of scoped data in a contact centre, and the one no one wants to audit.

v4.0.1's clarification on SAD makes this worse, not better. Sensitive authentication data — CVV, full magnetic stripe, PIN data — must not be retained after authorisation under any circumstance. A recording that captures a customer reading their CVV2 is a v4.0.1 failure the moment storage starts. There's no encryption argument that fixes it; the data category isn't allowed to persist at all.

The desktop and screen-share

The desktop and any screen-share is the third. Screen recording, supervisor whisper, screen pop, AI co-pilot overlays — if the agent types the PAN into a CRM field, all of those layers can capture it. We've seen this come up most often where a contact centre has bolted on a transcription or coaching tool without thinking through what it's recording. The Microsoft Teams or Zoom Phone call quality tooling, the Calabrio QM platform, the Salesforce Service Cloud screen recording — all of them are scoped the moment a PAN crosses the screen.

The AI co-pilot category is the new one. Sentiment analysis, live transcript, next-best-action prompts — these all read the audio stream or the desktop in real time. If they retain transcript fragments, even temporarily, they're a new scoped system that didn't exist 24 months ago.

The network leg

The network leg is the fourth. Voice paths carry the digits across SBCs, SIP trunks, recording infrastructure, and increasingly cloud telephony. Each hop is a potential capture point and an audit-scope boundary. A control regime that covers three of these four isn't compliant. It's a regime with a known hole.

The hosted CCaaS shift makes this question sharper. If your telephony lives in Genesys Cloud, Five9, NICE CXone, Talkdesk, RingCentral, 8x8 or Amazon Connect, the audio passes through media servers you don't operate. The vendor's AOC covers their infrastructure. It doesn't extend to the call recording that your tenant produces, or the storage bucket those recordings sit in, or the QA seat that listens back. Those remain yours, and they remain scoped.

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.

What v4.0.1 specifically asks for in a phone payment environment#

The full standard runs to twelve top-level requirements and several hundred sub-requirements. Five of them disproportionately matter for phone payments, and they're the ones I'd start with if I were doing this for the first time.

Requirement 3 — stored cardholder data

Requirement 3 covers stored cardholder data, and the v4.0.1 clarification that hits hardest is on sensitive authentication data. SAD — full magnetic-stripe data, CVV/CVC, PIN data — must not be retained after authorisation, even encrypted. That includes call recordings. If a recording captures a customer reading their CVV and your retention policy keeps the file for any length of time, that's a control failure. It's the most common audit finding we see in pause-and-resume environments.

For the PAN itself, v4.0.1 tightens the cryptographic expectations. Strong cryptography means a known good algorithm with a key of appropriate length, managed under a documented key-management procedure. Reversible encryption of a recording library at rest, with the keys held by the recording platform vendor, doesn't typically meet the bar on its own — and even if it did, the SAD problem remains.

Requirement 8 — authentication everywhere

Requirement 8 broadened MFA expectations to cover access to any system that can view or export payment data. In a contact centre, that pulls in the telephony admin console, the workforce-management tool, the recording platform's QA UI, and any AI co-pilot that surfaces transcript fragments. Plenty of organisations had MFA on the CRM and stopped there. v4.0.1 closes the gap on the layers behind it, and our v4.0.1 walk-through goes through each requirement in detail.

The phishing-resistant MFA expectation (FIDO2, WebAuthn, PIV-style hardware tokens) is best practice rather than a hard mandate at this point, but it's where the auditor's questions are moving. SMS-based MFA still passes — for now — but assume it won't by v4.1.

Requirement 9 — physical access including home working

Requirement 9 is physical access. Open-plan floors with paper notebooks, sticky notes on monitors, and casual visitor traffic are scoped. Home-working agents are scoped too, and v4.0.1 expects the same physical-security controls on the kitchen-table desk as on the office floor. That catches most remote-agent expansions by surprise.

The post-2020 shift to hybrid contact centres made this a much bigger issue than the standard's authors anticipated. If you've got 200 agents working from home three days a week, your scoped physical environment is now 200 kitchen tables. The only credible answer to that question is an architecture where the card data never reaches the agent's environment in the first place — at which point the physical control problem disappears.

Requirement 10 — logging and monitoring

Requirement 10 is logging and monitoring. Every system that touches scoped data has to produce tamper-resistant logs, retained for a year — the SBC, the recording platform, the IVR, the gateway, the CRM, and any DTMF capture solution. The audit will sample those logs and check that an event in one system can be correlated with the corresponding event in another. If your SBC says a call connected at 14:02:11 and your payment gateway says a card was authorised at 14:02:47, the auditor wants to see both records, with matching call IDs, with synchronised clocks, with tamper-evidence on the storage.

v4.0.1 added an explicit expectation around automated log review. Manual log review at "regular intervals" used to satisfy the requirement. Now the language nudges firmly toward SIEM-based alerting. A SOC reviewing scoped events daily is the working definition.

Requirement 12 — security policy, training, and incident response

Requirement 12 is your security policy. A documented information-security policy that covers telephone payments specifically, with annual review, sign-off, and demonstrable awareness training for every agent. A generic IT-security policy doesn't pass. The auditor will ask to see the training records — date, content, attendees — and will sample agents to confirm they actually remember what they were taught.

The incident-response sub-requirement is the one that tends to be weakest. A documented IR plan that hasn't been exercised in 12 months is a documented IR plan with no evidence of effectiveness. v4.0.1 expects the plan to be tested annually, with a written outcome. Tabletop exercises count; full simulated breaches count more.

At QSA review the auditor walks through a real call, asks where the digits go second by second, and tests whether the answer at every step is verifiable from logs and architecture. The contact centres that pass cleanly are the ones whose answer at every step is "the digits never enter our environment in the first place."

Why pause-and-resume isn't enough on its own anymore#

Pause-and-resume — the agent presses a button to stop the recording while the customer reads the card number, then presses it again to resume — is the control most contact centres started with. It still gets a mention in the SSC's guidance, and you'll still find vendors selling it as a tick-box solution. The honest read on it in 2026 is that it depends on a human executing the control correctly on every call, every time. In a busy contact centre running thousands of payments a day, the failure rate isn't zero, and it's not negligible.

What goes wrong in practice

The agent forgets to press the button. The agent presses it late, after the customer's already started reading the card. The integration between the recording platform and the agent desktop fails silently — the agent thinks they've paused, the recording carries on. The customer reads the number before the agent's prompt, while the agent is still mid-greeting. The button pauses the audio recording but not the screen recording. The agent has paused the recording for the call but not the supervisor whisper that's also live.

None of these are theoretical. We've seen all of them at sites that thought their pause-and-resume control was working. The QSA finding tends to be the same — "the control depends on consistent manual execution and the firm has not demonstrated 100% effectiveness across the sample period."

The audit consequence

The audit consequence is that a pause-and-resume environment effectively forces the QSA to assume the control fails some percentage of the time, and to scope accordingly. Every recording in retention has to be treated as if it might contain SAD. That pulls the recording platform, the storage, the QA tooling, and every operator who ever touches the file into scope. The licence cost of pause-and-resume is small. The audit cost it generates is what makes it a false economy.

The compounding cost is breach risk. A recording library you've assumed contains no card data, but actually contains a small percentage of recordings with full PAN and CVV captured before the agent paused, is a category of breach that's hard to detect proactively and expensive to remediate once disclosed.

What the SSC's supplement actually says

It's worth reading the SSC's Information Supplement directly. The relevant section doesn't ban pause-and-resume outright — it says the technique can reduce risk but is not a complete control on its own, and that firms relying on it need additional compensating controls and have to scope the recording environment accordingly. That's a defensible reading. It's also a much smaller commercial proposition than the marketing claim that pause-and-resume "removes" recordings from scope.

The alternative is a technical control that strips the digits out of the audio path before they ever reach the recording. That's what DTMF masking does, and it's what gets you to the next section.

The architectures that work for phone payments#

You've really got four options that meet v4.0.1 cleanly, and each fits a different call type. None of them are exotic — they're all in production at hundreds of UK and US contact centres today.

DTMF masking — the headline architecture

DTMF masking, sometimes called DTMF suppression, is the headline. The customer enters their card number on their phone keypad. The tones are intercepted in the live audio stream, replaced with flat tones in everything the agent and the recording can hear, and the original digits are routed straight to the payment gateway. The agent stays on the line, the customer stays on the line, the conversation continues — the agent just never hears the number, the recording never captures it, and the desktop never sees it. This is the architecture that produces the largest scope reduction for assisted calls, and it's our flagship technology.

In our deployment the customer's audio is split at the SBC. One leg is masked and goes to the agent's headset and the recording. The other leg goes to the payment processor over a TLS-encrypted path that never touches the contact-centre environment. The agent sees only the last four digits of the PAN on their screen, written back from the gateway after authorisation. That's a tokenised confirmation, not the live card number, so the desktop stays out of scope.

IVR self-service

IVR self-service is the second pattern. For repeat collections, premium payments, parking-fine settlement, and any "I just need to pay an amount I already know" workflow, an automated IVR menu is the cleanest path. The customer talks to the IVR; no agent is ever in the path; the call leg that handles the card data is fully isolated from the contact-centre environment. We cover this under IVR self-service payments.

The economics here are usually compelling. A debt-collection agency that puts 60% of its inbound payment volume through an IVR drops 60% of its agent minutes, 60% of its card-handling training overhead, and 60% of its breach exposure on the same channel. The remaining 40% — disputes, hardship discussions, payment plans — still needs an agent, and that's where DTMF masking covers the gap.

Agent-assisted with secure capture

Agent-assisted with secure capture is the third. For complex assisted sales — insurance applications, account changes, multi-product orders — the agent stays on the call, walks the customer through everything, and triggers a secure capture step at the point of payment. We connect to a contact centre via any of seven integration patterns (network divert, PBX divert, IVR transfer, conference, outbound, WebRTC, SIP), so the architecture fits whatever telephony stack is already in place. See agent-assisted phone payments.

The detail that matters at audit is that the secure capture step is delivered by a Level 1 service provider whose AOC covers the architecture you've bought. The agent triggers the capture and is still on the line. The customer enters the digits on their keypad. The flow returns to the agent once authorisation is in. The agent never sees, hears, or types the PAN. The recording never contains it. The desktop is never in scope.

Channel separation as the underlying principle

Channel separation is the principle running underneath the other three. The PCI-scoped data flow and the contact-centre flow share a customer and an outcome, but they don't share a system. Channel separation is what auditors are testing for when they walk the call.

The right choice depends on your call profile. High-volume repeat collections lean toward IVR. Complex assisted sales lean toward DTMF masking. Most contact centres end up with a mix — IVR as the primary route, DTMF masking for the agent-handled balance, and the same AOC covering both.

How the scope reduction actually works#

Scope reduction is the economic argument for any of the architectures above. The mechanism is simple. PCI DSS scope is defined by the systems that store, process, or transmit cardholder data, plus any system connected to those. If the cardholder data never enters your telephony environment, your CRM, or your recording platform, none of those systems are scoped. The audit shrinks from a full SAQ-D — the longest of the self-assessment questionnaires — to a shorter SAQ A or SAQ A-EP, which is what an organisation that outsources card handling to a Level 1 service provider can typically attest under.

SAQ-D vs SAQ A — what changes at audit

An SAQ-D has 329 controls to evidence. SAQ A has 22. The difference is the practical translation of channel separation into compliance work. A QSA-led SAQ-D engagement at a mid-sized UK contact centre typically takes six to twelve weeks of internal effort, evidence-gathering, control testing, and remediation. An SAQ A self-attestation is a half-day exercise once the architecture is in place.

The wider point is what disappears alongside the questionnaire. Quarterly external scans of the contact-centre estate, annual internal penetration tests of the telephony layer, formal change-control on every CRM release, segmented network zones for the payment systems, agent-by-agent training records — none of it goes away entirely, but the scope of who needs it and what they need it for collapses dramatically.

The 96% figure and what's behind it

The 96% figure that appears in our customer outcomes is the proportion of contact-centre systems that drop out of scope when DTMF masking is implemented properly. It tracks closely with the SSC's own scope-reduction principle. Translated into a board-level number, the audit cost difference is real: a full SAQ-D engagement at a mid-sized UK contact centre is typically a £35,000 to £90,000 annual exercise. SAQ A is a fraction of that, and the residual operational overhead — agent training, retention reviews, breach drills — falls in proportion.

The 4% that remains in scope is the path between the customer's phone and our environment, plus the small confirmation flow back into yours. That path is covered by our AOC, refreshed annually, available on request to your auditor.

Why the percentage is the wrong headline

The percentage isn't really the point. The point is that compliant phone payments stop being an expensive ongoing programme and become a configuration choice you make once. That's the difference contact centres at British American Tobacco, Warby Parker, and Allclear describe when they talk about the change. None of them rebuilt their telephony stack to get there. They added a layer.

The 2026 board conversation isn't "should we be PCI compliant" — that question's settled. It's "what does the next twelve months of compliance cost us, and what's the breach-risk profile we're carrying alongside it." Channel separation answers both at the same time.

A practical 2026 implementation order#

If you're starting from a typical contact-centre environment that takes card payments today, here's roughly the order of decisions that gets you to a defensible v4.0.1 posture. None of them are quick wins on their own. Together they're a programme.

Step 1 — Profile your calls

Start with the call profile. Count the calls, classify them by type — assisted sale, repeat collection, complex application, refund — and decide which architecture fits each. The data lives in your contact-centre platform's reporting layer; if it doesn't, that's the first thing to fix. You need to know what percentage of card-taking calls are amenable to IVR self-service and what percentage genuinely need an agent.

Step 2 — Walk a real call with your auditor

Then identify scope today. Walk a real call with your QSA or your internal audit lead and document where the digits go, second by second. Most teams find at least one path they hadn't realised was scoped — a screen recorder no one remembered installing, a transcript fragment in the QM tool, a workforce-management screenshot, a supervisor whisper that wasn't pausing. The walk-through is uncomfortable, and it's the cheapest piece of due diligence you'll do.

Step 3 — Pick the architecture per call type

From there, pick the architecture per call type. IVR for repeat collections, DTMF masking for assisted, channel separation across the lot. Pick a Level 1 service provider with a current AOC and verify it's been issued in the last twelve months and covers the architecture you're buying. Ask for the AOC document, not just a marketing claim — we'll send ours over without being asked twice.

Step 4 — Tighten the controls that stay yours

Then put MFA on every admin console that can see payment data — telephony admin, recording, WFM, QA, AI co-pilots. Lock down recording retention. SAD must not survive authorisation in any retained recording, and the only way to be sure is to sample. Update the security policy and re-train every agent. Documented, signed off, repeated annually, demonstrable.

Step 5 — File the SAQ that fits your new scope

And then schedule the v4.0.1 SAQ — aim for SAQ A wherever the architecture allows it. Your acquirer will tell you which questionnaire applies based on your transaction volume and channel mix; the architecture choice is what makes SAQ A available to you. If the acquirer pushes back, the AOC from your service provider is the document that resolves the conversation.

For US contact centres the same checklist applies, with state breach-notification readiness and FTC-aligned incident response added on top. The US guide linked at the top of this page covers the differences.

Common implementation traps#

A few patterns come up often enough in the first 90 days of a deployment that they're worth flagging in advance.

The recording library you didn't realise you had

Most contact centres have a primary recording platform and at least one secondary one — a QM tool, a sentiment-analysis tool, a coaching platform, a compliance archive that copies recordings off to a separate bucket. The PCI scoping exercise has to find all of them. The architecture change only moves you out of scope if all the downstream copies stop receiving the cardholder data too.

The remote-agent home-network question

Home-working agents who take card payments are in scope under Requirement 9, and their home networks are arguably in scope under Requirement 1. The clean answer is the architecture answer — if the card data never reaches the agent's headset or desktop, the home network never carries it either. Trying to scope a home network as a PCI segment is not a road we'd recommend anyone go down.

The CCaaS migration timing

Plenty of contact centres are in the middle of moving from on-premises telephony to a cloud CCaaS platform. The temptation is to wait until that migration is done before changing anything about payment handling. The better order is the reverse — put channel separation in place first, on whatever telephony stack is live today, then migrate. The DTMF masking architecture sits between the customer and your contact centre, so the migration from one CCaaS to another doesn't disturb it.

The audit calendar

If your annual SAQ is due in September and you start the architecture change in July, you'll be evidencing controls that have only been live for a few weeks. Auditors typically want three to six months of operational evidence. Plan the architecture change so the new control regime has time to accumulate logs and incidents (or, ideally, the absence of them) before the audit window opens.

Make the audit small#

Telephone payments aren't the hard part of running a contact centre in 2026. The wrong architecture, though, makes them disproportionately expensive — in audit cost, breach risk, and operational drag. The right architecture lets the customer experience the caller expects sit alongside the compliance posture the board expects, at the same time. If you'd like to see what that looks like in your environment, you can read how we remove 96% of PCI scope or book a demo. We've held PCI DSS Level 1 certification every year since 2016, and the same people who built it will be on the call.

Author: Curtis Nash, founder and CEO of Paytia. Curtis has worked in payment security for over 15 years and has led Paytia through every PCI DSS revision since the company's founding in 2016. Paytia is a PCI DSS Level 1 service provider trusted by contact centres at British American Tobacco, Warby Parker, and Allclear, and endorsed by NatWest and Lloyds.

Related guides in this cluster#

For the product side, see our Take card payments over the phone solution.

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.