PCI DSS v4.0.1: 2026 Contact Centre Buyer's Guide

Last updated: 29 May 2026

If you run a contact centre and you take card payments, the practical question in 2026 isn't "are we ready for v4.0.1?" any more. It's "how do we keep operating compliantly now the deadline's gone?" Version 4.0.1 of the PCI Data Security Standard has been the live version since 31 March 2025. By April 2026, anyone still running pause-and-resume on the agent leg, leaving DTMF tones unmasked, or finishing last year's annual scope review isn't transitioning. They're non-compliant.

This guide is for the people inside contact centres — compliance leads, heads of customer service, IT and telephony owners. They need the real change list, an honest read on how it lands on a phone payment, and a buyer's checklist they can hold up against any vendor pitch. We've held PCI DSS Level 1 service-provider status since 2016 and we've written this the way we'd brief a new customer in their first compliance meeting.

What changed in PCI DSS v4.0.1 (and what didn't)#

The first thing worth being clear about: v4.0.1 added no new requirements. The PCI Security Standards Council published it on 11 June 2024 as a clarifying release, not a substantive expansion. What it did do was tighten language where v4.0 had left interpretation gaps, fix typos and formatting errors, and — in one case worth flagging — revert a clause back toward the v3.2.1 wording.

The most consequential clarifications for contact centres sit in three places. Requirement 6 rolled the vulnerability-patching language back to "critical vulnerabilities, within 30 days," which is what most security teams had assumed v4.0 still meant. The broader "high-risk" framing v4.0 introduced had created confusion about how to triage a backlog. Requirement 8 clarified that multi-factor authentication applies to all personnel with administrative access, with explicit emphasis on phishing-resistant mechanisms; if your telephony admin console or workforce-management tool isn't behind phishing-resistant MFA, you've got a gap. Requirement 3 clarified that hashed PANs have to use keyed cryptographic hashing — HMAC-SHA256 or equivalent — which is small but worth knowing if you handle any tokenisation in-house.

What v4.0.1 didn't do is change the geometry of the standard. The 12 high-level requirements are unchanged. Scope obligations are unchanged. The customised approach option v4.0 introduced still exists. If you read v4.0 carefully and built a programme around it, v4.0.1 is a re-confirmation, not a re-architecture. The v4 standard itself hasn't moved; v4.0.1 just tidies the corners.

Why the patching language matters more than it sounds

The Requirement 6 revert isn't cosmetic. Under v4.0 as originally written, security teams had to justify a "risk-based" patching window for vulnerabilities classed as "high" but not "critical." That's a lot of operational judgement to defend to a QSA. In a contact-centre context — where you've got agent desktops, telephony servers, recording platforms, CRM integrations and a payment intermediary all interlocking — the "high but not critical" bucket can include hundreds of CVEs in any given quarter. v4.0.1 reduces that to "critical, within 30 days," which is the same line most platform owners had been running internally anyway. It removes a paragraph of defensible policy you would otherwise have to write and review.

MFA for admins: what "phishing-resistant" actually means

SMS one-time codes don't clear the v4.0.1 bar for administrative access. Neither do TOTP codes from an authenticator app if the authenticator runs on the same device as the browser session being authenticated. The phishing-resistant factors that QSAs accept today are FIDO2/WebAuthn hardware keys, platform authenticators bound to the device (Windows Hello for Business, Apple Passkeys with attestation), and certificate-based authentication with hardware-protected keys. If your telephony admin console only supports SMS or email codes, raise it with the vendor — that's now a v4.0.1 conformance issue, not a "nice to have."

HMAC hashing for stored PANs

Most contact centres don't store PANs themselves, which is the point of using a Level 1 service provider. But if you've got any local tokenisation, any test data sets that ever held real PANs, or any legacy database column that used unkeyed hashing, v4.0.1's clarification on HMAC-SHA256 (or equivalent keyed cryptographic hashing) needs to land in your remediation plan. The risk it closes is rainbow-table reconstruction of card numbers from leaked hashes — small for any one PAN, large across a leaked database.

The 31 March 2025 deadline — and what it means in 2026#

The hard transition date — when the future-dated v4.x requirements all became enforceable and v3.2.1 was retired — was 31 March 2025. v4.0 sunset on 31 December 2024, which means the formal answer to "are we still allowed to operate on v4.0?" is no.

For most contact centres, the 2026 reality is honest but uncomfortable: technically signed off on v4.0.1 by an assessor, but with one or two control areas still being tidied up. The two we see most often are the call-recording question and the admin-MFA question, both of which are below. The Information Commissioner's Office's wider guidance on payment data security overlaps with PCI DSS scope here — particularly around how long you keep customer call recordings and how you justify it under UK GDPR. Late-adopter contact centres are sometimes solving the same control twice in two regimes, which is a clue the underlying architecture needs a rethink rather than another patch. (For the full picture on tier obligations, see PCI compliance levels 1 to 4 explained.)

If you're still running pause-and-resume on the agent leg, the honest assessment is straightforward. That approach isn't enough on its own any more. It depends on the agent remembering to pause, on the recording system honouring the pause cleanly, and on no one capturing the audio anywhere else in the chain. v4.0.1's clarifications around what counts as captured sensitive authentication data — including CVV — turn this into an architectural conversation, not a process one.

What QSAs are pushing back on in 2026

From the assessments we've supported this year, three questions come up in almost every QSA conversation. First: show me the documented annual scope review with dates and signatures. A spreadsheet from 14 months ago doesn't pass. Second: walk me through what happens to the audio between the customer keying card digits and the recording being written to storage. If there's a "the agent presses pause" step in there, expect the assessor to test it. Third: show me the MFA factor being used by your telephony admin, captured live. Screenshots from policy documents aren't enough; QSAs are asking to see the actual authentication flow.

UK GDPR overlap nobody talks about

The ICO's payment-data guidance and PCI DSS aren't the same regime, but they collide on call recordings. UK GDPR requires you to justify how long you retain personal data, and a call recording with card details is both personal data and (until you remove the SAD) cardholder data. We've seen contact centres land in awkward positions where their PCI assessor accepts a 12-month recording retention because of dispute-handling needs, while their DPO wants 90 days under data-minimisation. The clean answer is to remove the cardholder data from the recording at source so the only thing retained is non-sensitive call audio plus tokenised transaction metadata. That gives both regimes the same answer.

The "late adopter discount" myth

Some vendors are still pitching that there's a soft enforcement window for contact centres that missed the deadline. There isn't. Acquirers and card schemes set the consequences, and what we're seeing in 2026 is straightforward: non-compliance fines starting around £4,000 a month for smaller merchants, scaling sharply for breach events, and acquirer-mandated remediation timelines of 30 to 90 days. If your bank is asking for a fresh AoC you don't yet have, "we'll get there" isn't an answer that holds the line.

Comparing options? Book a 15-minute demo — we'll show you a live capture and quote a real number for your call volume.

Where contact centres usually fail v4.0.1 (the four big ones)#

Across the contact-centre programmes we've assessed for v4.0.1 readiness over the last two years, four failure patterns repeat.

The first is call recordings that capture sensitive authentication data after authorisation. v4.0.1 is unambiguous: any recording that holds CVV, full magnetic-stripe data, or PIN data after the transaction is authorised is a control failure. Pause-and-resume processes that miss a pause — even occasionally — fail this requirement.

The second is agent-leg DTMF capture. If the customer reads their card number aloud, the agent hears it. If the customer keys it in with no masking on the line, the DTMF tones are still there. Either way the data is in scope. The fix is technical, not procedural — the audio or the tones have to be removed before they reach the agent leg or any recording point. DTMF masking is the architectural pattern that does this cleanly.

The third is administrative consoles without phishing-resistant MFA. Telephony admins, workforce-management tools, recording-platform consoles, CRM payment-fields views — anywhere a person can configure or extract payment-related data needs MFA, and v4.0.1 points specifically at phishing-resistant factors. SMS one-time codes don't clear the bar.

The fourth is scope creep from new integrations. Every new CRM connector, every new IVR menu, every new agent tool added since the last assessment is a candidate for changing your in-scope footprint. v4.0 made the annual scope review a hard requirement; v4.0.1 didn't soften it. If you can't show a documented scope review for the last 12 months that includes the new integrations, you've got an audit issue waiting to happen.

Failure pattern detail: housing associations

UK housing associations are a recurring case. They take card payments for rent, service charges and arrears over the phone, often through a contact centre that also handles tenancy queries, repairs and complaints. The same agent will handle a damp report and then take a £600 rent payment. We've seen housing-association contact centres where the recording platform is recording every call by default for safeguarding reasons, the agents are using pause-and-resume by training rather than by enforced workflow, and the CRM has a "payment notes" free-text field where agents sometimes type the last four digits "for the customer's reference." Every one of those is a v4.0.1 finding.

Failure pattern detail: insurance brokers

Insurance brokers run into a different version of the problem. Their compliance regime under FCA rules already mandates full call recording for advised sales. They can't simply stop recording, and a pause-and-resume window in the middle of a payment leg leaves an obvious gap in the call narrative that compliance auditors then ask about. The architectural answer here is masking that doesn't break the recording — the audio continues, the DTMF tones are intercepted before they hit the recording, and the resulting file plays back as continuous speech with the card-digit segment naturally silent. FCA gets its complete call, PCI gets its zero-SAD recording.

Failure pattern detail: FX bureaux and money services

FX bureaux taking card payments over the phone for currency orders run into Requirement 8 hardest. The platforms they use are often multi-tenant, with admin access shared across operations, treasury and reconciliation teams. Phishing-resistant MFA on a shared admin login isn't really MFA — it's MFA at the door but a shared password behind it. v4.0.1 wants individually attributable admin access with phishing-resistant factors per person. That's a configuration project, not a procedural one.

Failure pattern detail: outsourced contact centres

If your contact centre is delivered by a BPO, the v4.0.1 obligations don't move to the BPO. You're still responsible for the cardholder data unless the contract explicitly puts the BPO in scope as a service provider — and if it does, you need their AoC, their scope statement and a documented shared-responsibility matrix. The four failure patterns above apply whether the agents are on your payroll or someone else's.

What "compliant" looks like for telephone payments#

The architectural pattern that takes care of all four failures in one move is technical masking on the agent leg. The customer keys their card details into their own keypad during a live call. The DTMF tones get intercepted before they reach the agent or the recording. The agent never sees or hears the data. The call recording carries no sensitive authentication data — there's nothing to pause around because there's nothing capturable in the audio.

The downstream effect is the one that usually wins the budget conversation: a properly implemented DTMF masking architecture can take up to 96% of your contact-centre operations out of PCI scope. The card data flow ends at a Level 1 service provider's environment; your agents, recordings, CRM and local network sit outside the cardholder data environment. The SAQ shrinks. The annual assessment effort shrinks. The blast radius of a worst-case breach — the thing your CFO actually loses sleep over — shrinks too. Our PCI DSS Level 1 attestation is the formal evidence behind that.

One financial-services customer in the UK put it like this in their FeaturedCustomers review: "peace of mind for me as a business owner and my customers, knowing that card information is safely stored." That's the outcome buyers are buying. It isn't a technology, it's an architectural change to the scope conversation.

How the call flow actually works

Walk through it from the customer's perspective. They ring your contact centre, get to an agent the normal way, talk through whatever they're calling about, and reach the point of paying. The agent says something like "I'll start a secure payment now — you'll hear a short prompt, then key your card details on your phone keypad." The agent's screen shows a payment form with fields that fill in as the customer keys digits, but instead of the actual digits the agent sees asterisks plus the last four. The audio of the DTMF tones doesn't reach the agent's headset and doesn't reach the recording. When the customer's done, the agent confirms the total and the transaction goes through to the acquirer. The whole thing takes 45 to 90 seconds depending on how much the customer needs to read out from their card.

Where the card data actually goes

The DTMF tones get intercepted by the masking platform — in our case, in our PCI Level 1 environment. The platform decodes the digits, builds the authorisation request, sends it to the acquirer, and returns a token plus the transaction result. The token gets handed back to your CRM or order management system, which is what the agent sees on their screen. The actual PAN never crosses your network at any point. If a forensic investigator looked at every byte that touched your contact centre infrastructure during the payment, the worst they'd find is a token and a last-four. That's the architectural change PCI DSS v4.0.1 rewards.

Comparison with the standard pause-and-resume model

The model most contact centres started with — pause the recording, take the card details by voice, resume the recording — has three failure modes that v4.0.1 makes harder to defend. First, the agent has to remember to pause every time. Even at 99% reliability, on 50,000 calls a year that's 500 recordings with SAD in them. Second, even when the pause fires correctly, the agent has still heard the card number; the agent is now in scope as a person who can capture cardholder data, and that brings their workstation, their headset, the air around them and (in some interpretations) the office Wi-Fi into scope too. Third, the audit story is fundamentally a process-control story rather than a technical-control story, which is a weaker position when something goes wrong. Technical masking sidesteps all three.

What this looks like in a CCaaS environment

If you're on a modern CCaaS platform — Genesys Cloud, Five9, NICE CXone, Talkdesk, RingCentral, 8x8, Avaya OneCloud, Amazon Connect — masking sits as an integration alongside your existing call flow rather than replacing it. The agent stays in the CCaaS UI. The screen-pop happens through a CTI integration. The masking platform handles only the payment leg and hands a token back. Your CCaaS provider doesn't need to be a PCI Level 1 service provider for this to work, because your CCaaS environment never sees the card data.

How to read your scope under v4.0.1#

The annual scope review is the requirement most contact centres under-invest in, partly because it sounds procedural. It isn't. Done properly, the scope review is the document that tells you which control changes you actually need to make this year — it's the upstream input for everything else.

The questions it has to answer cover several areas. Which systems store, process or transmit cardholder data; which systems are connected to or could affect those systems; which people have access to any of them; what changed in the last twelve months; and what the documented justification is for the boundary you've drawn. v4.0.1 doesn't change those questions, but it does insist on documenting that the review was done. An undocumented "we looked at it" isn't a defensible answer any more.

The reason DTMF masking matters here is it lets you draw the boundary much further out from your contact centre. If the audio leg never carries the card data, the recording platform isn't in scope for SAD. If the agent never sees the digits, the CRM isn't in scope for PAN storage, and the workforce-management tool isn't in scope for any of it. You go from arguing about which of your systems are in scope to demonstrating most of them aren't, which is a categorically easier conversation with a QSA.

The three scope categories worth remembering

The PCI SSC's segmentation guidance breaks systems into three buckets. CDE systems store, process or transmit cardholder data — those are fully in scope. Connected-to or security-impacting systems can affect CDE systems even if they don't touch cardholder data themselves — they're also in scope, sometimes called "in scope by association." Out-of-scope systems can't affect the CDE and don't process cardholder data. The scope review's job is to put every system in your contact centre into one of those three buckets and justify the placement. Masking is a tool for moving systems out of the first two buckets and into the third.

Documenting connected-to systems

The category contact centres most often get wrong is connected-to. A CRM that the agent uses during a payment call is connected-to even if it doesn't store PANs, because if compromised, an attacker could pivot from the CRM into the agent's session and observe a payment. Putting masking in front of the payment leg breaks that pivot path: the agent's session never sees the PAN, so a compromised CRM can't observe it. That's how you legitimately move the CRM from "connected-to and in scope" to "out of scope" in your annual review.

The segmentation-test obligation

If you claim segmentation between your CDE and the rest of your network, v4.0.1 requires you to test that segmentation at least every 12 months for merchants and every 6 months for service providers. The test has to be a positive demonstration that you can't reach the CDE from outside, not just a network diagram. For contact centres that have descoped via masking, the segmentation test is straightforward — there's no CDE on your network to reach. For contact centres still hosting card data internally, this is one more reason to think about descoping seriously.

What to ask vendors when buying for v4.0.1#

If you're evaluating a contact-centre payment vendor — first time, or as part of a v4.0.1-driven re-tender — these are the questions worth asking. None are trick questions. Vendors that struggle to answer any of them are telling you something useful.

Ask whether the vendor is itself a PCI DSS Level 1 service provider, and whether they hold their own valid Attestation of Compliance for the current version. Level 1 is the highest tier and it's required of any service provider handling more than six million card transactions per year. Ask to see the AoC, not just hear about it.

Ask how they handle ongoing certification through standard revisions. v4.0.1 won't be the last clarifying release. A vendor that's held Level 1 across multiple versions — Paytia has held it since 2016, for example — is telling you something different to one that achieved it once and then went quiet.

Ask which integration patterns they support. There are seven viable patterns for inserting a payment intermediary into a contact-centre call flow. The options are network-level divert, PBX-level divert, IVR menu, agent transfer or conference, PSTN outbound via the vendor, vendor WebRTC capture inside a browser-based agent, and SIP trunk integration. Different contact-centre architectures suit different patterns. A vendor that only offers one is forcing your architecture to bend round their constraints.

Ask what happens to call recordings. Specifically: does the architecture remove SAD from the recording at source, or does it depend on a software pause that has to fire correctly every time? The first passes v4.0.1 with no operator dependency; the second is a process control wrapped round a recording flow that still has the data in it.

Ask for customer references in your sector. The buying logic for a regulated financial-services contact centre is different to a retailer's. Paytia customers including British American Tobacco, Warby Parker and AllClear span the range, and they're happy to talk to prospective buyers. NatWest and Lloyds sit on the financial-services side specifically.

Finally, ask for a realistic descoping estimate based on your current architecture, not a marketing number. Up to 96% scope reduction is a typical outcome for a properly-implemented DTMF masking deployment, but the right vendor will walk through your specific environment before quoting a number.

The integration-pattern questions that matter

If you're running on-premise PBX, ask specifically about SIP trunk integration and whether the vendor can sit between your trunk provider and your PBX without you having to change your numbering plan. If you're cloud-CCaaS, ask about pre-built integrations with your specific platform — Genesys AppFoundry listing, Five9 partner directory, NICE CXone DEVone, that kind of thing. If you're on a hybrid setup, ask about transfer-based patterns where the agent warm-transfers the customer to the masking platform for the payment leg and the customer comes back to the same agent after. Each pattern has trade-offs around call quality, abandonment risk and reporting, and a vendor who can explain those trade-offs honestly is worth more than one who claims their single pattern fits everyone.

The reporting questions agents actually care about

The compliance team buys the masking; the contact-centre operations team has to live with it. Ask how transactions appear in agent reporting, whether average handle time changes (it usually drops, because the customer keying their own card is faster than reading it aloud), whether wrap-up codes for payment outcomes flow into your existing reporting, and whether refunds and recurring transactions can be initiated from the same UI as the original capture. The wrong answer here can mean a compliant solution your agents quietly route around.

What "free trial" actually means in this market

Don't accept a vendor demo as the same thing as a trial. A demo runs against the vendor's reference architecture; a trial runs against your real telephony, your real CRM and your real agents. Ask for a 30-day pilot on a single team or a single queue before you sign anything that locks you in for years. The vendor should be willing to support that pilot at near-production quality. If the answer is "we can't do that," they're telling you their architecture isn't flexible enough to integrate with yours without significant project work.

The Paytia approach in one paragraph#

Paytia sits inside a live phone call and intercepts the customer's card details before they reach the agent or the recording. We've held PCI DSS Level 1 service-provider status since 2016, through every revision of the standard including v4.0.1. Customers including British American Tobacco, Warby Parker and AllClear use Paytia to take card payments while keeping their contact centres outside the cardholder data environment. NatWest and Lloyds are among the institutions that have endorsed the approach. If you'd like to talk through how this would work for your own architecture, our consultations are free and run by people who do this every day.

Frequently asked questions#

When did PCI DSS v4.0.1 become mandatory?

PCI DSS v4.0.1 has been mandatory since 31 March 2025. v4.0 sunset on 31 December 2024. Organisations operating beyond those dates without a v4.x assessment are non-compliant and need to remediate, not just plan to.

What's actually new in v4.0.1 compared to v4.0?

Nothing was added or removed. v4.0.1 corrected typographical errors and clarified existing requirements — most consequentially around MFA scope under Requirement 8 and PAN protection under Requirement 3. It also reverted Requirement 6's vulnerability-patching language to "critical, within 30 days," which is closer to the v3.2.1 wording.

What does v4.0.1 mean for telephone payments and call recording?

Any recording that captures sensitive authentication data — including CVV — after authorisation is a control failure. Pause-and-resume recording, which depends on agents remembering to pause, isn't adequate any more where card digits are spoken aloud. Technical masking architectures such as DTMF masking are the reliable way to keep call audio out of scope.

Do we need to redo our annual scope review now that v4.0.1 is in force?

The annual scope review obligation predates v4.0.1, but v4.0 made it explicit and v4.0.1 didn't soften it. If you can't show a documented review covering the last 12 months — including any new CRM, IVR or agent-tool integrations — you've got an audit gap. Use a v4.0.1-readiness review as the trigger to refresh the documentation, not just the scope itself.

How much PCI scope can a contact centre realistically remove?

A properly implemented DTMF masking architecture can take up to 96% of contact-centre operations out of PCI scope. The card data flow ends at the masking provider's PCI Level 1 environment; agents, recordings, CRM and local network sit outside the cardholder data environment. The exact number depends on your starting architecture and which integration pattern you choose.

Does v4.0.1 apply to small contact centres or just the big ones?

It applies to anyone accepting card payments, regardless of size. What changes by size is the assessment route. Smaller merchants typically complete a self-assessment questionnaire (SAQ) rather than a full Report on Compliance, but the underlying control requirements are the same. A 12-seat contact centre running pause-and-resume is in the same non-compliance position as a 500-seat one. The size only affects how the non-compliance gets discovered — usually by an acquirer query or a breach, in the smaller-centre case.

Can we still use pause-and-resume if our recordings are encrypted at rest?

Encryption at rest doesn't change the answer. v4.0.1 treats stored sensitive authentication data as a control failure full stop — the standard explicitly says SAD must not be stored after authorisation, regardless of encryption. Encryption protects against one threat (storage compromise) but doesn't satisfy the requirement, because the requirement is to not store the data at all. The architectural fix is to keep SAD out of the recording in the first place.

How long does a DTMF masking deployment take?

For a single-team pilot on a modern CCaaS platform, two to four weeks is realistic. For a full contact-centre rollout across multiple sites and integration with an on-premise PBX plus a legacy CRM, six to twelve weeks is more typical. The variable is integration complexity, not the masking platform itself. Plan the scope-review refresh and the QSA conversation in parallel with the technical rollout so you're not paying twice for the same calendar time.

Find out what your descoping picture looks like#

If you'd like a 30-minute walk-through of how DTMF masking would change your specific PCI DSS v4.0.1 footprint, talk to us. You'll get an honest estimate of the scope reduction available. You can also look at how we handle PCI DSS v4 in detail. The consultation is free and runs against your real environment, not a generic deck. Visit our contact page or call our UK office on +44 20 7183 3536 (US: +1 628 295 2250).

For a buyer-side checklist on choosing a phone-payment platform, see our telephone payment security buyer's guide.

References#

• PCI Security Standards Council, "Just Published: PCI DSS v4.0.1" (11 June 2024)
• PCI Security Standards Council, Document Library — PCI DSS v4.0.1 PDF and supporting guidance
• PCI Security Standards Council, PCI DSS v4.x Resource Hub
• Information Commissioner's Office, security guidance under UK GDPR
• NIST SP 800-63B Digital Identity Guidelines (authentication and lifecycle management)

Related guides in this cluster#

For the product side, see our PCI DSS v4 compliance solution.

Comparing options? Book a 15-minute demo — we'll show you a live capture and quote a real number for your call volume.