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 — who 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.
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 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.
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.
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 — not a technology, an architectural change to the scope conversation.
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 are: 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; 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.
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: 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 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, with NatWest and Lloyds 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, clarified existing requirements — most consequentially around MFA scope under Requirement 8 and PAN protection under Requirement 3 — and 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.
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 — and an honest estimate of the scope reduction available — talk to us. 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).
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)
