PCI DSS v4 for US Contact Centers: A Practical Guide

Last updated: 27 May 2026

If you run a US contact center 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 — and that's the kind of thing your acquirer will eventually ask about.

This guide is for the people inside US contact centers — 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 US merchant 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 substantive new obligations everyone is now living with came in v4.0 itself, with effective dates of 1 April 2025 for the future-dated requirements.

The most consequential clarifications for contact centers 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 tokenization 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 program around it, v4.0.1 is a re-confirmation, not a re-architecture.

The future-dated requirements that bite hardest for US call centers#

The five future-dated requirements that became enforceable on 1 April 2025 are the ones every US contact center should have closed out by now. If you haven't, this is the order to work through them.

Requirement 6.4.3 — script integrity on payment pages. Any script loaded on a page that handles cardholder data has to be authorized, integrity-assured, and inventoried. The original intent was the e-commerce checkout page, but the language reaches further: any IVR self-service flow that renders a web view, any agent desktop that loads a payment overlay, any third-party tag that runs alongside a payment field is in scope. For a contact center that uses a hosted payment iframe or a click-to-pay widget inside a CRM, this is a real piece of work — you need a script inventory, a change-management process for adding new scripts, and a mechanism to detect unauthorized script changes.

Requirement 8.3.10.1 — MFA for all access to the cardholder data environment, including service-provider and vendor access. The headline change is that MFA isn't just for administrative access any more. Any account that can read, write, or export cardholder data needs MFA, with a specific carve-out for accounts authenticated via a single factor only if compensating controls are in place. For contact centers, this pulls in the agent desktop sign-in to the payment surface, the QA reviewer's access to recorded calls, the BI analyst pulling transaction reports. The practical migration is to push everything behind SSO with MFA at the IdP, which most US contact centers have done at least partially for other compliance regimes already.

Requirement 11.6.1 — phishing-resistant MFA for any administrative access to the CDE, with v4.0.1 clarifying language. Phishing-resistant means FIDO2, smart cards, or PKI-based authentication. SMS one-time codes and push notifications are out. TOTP authenticator apps are a grey area — defensible for non-administrative access, weaker for CDE admin. For a contact center the practical implication is a hardware-token rollout for telephony admins, security analysts, network engineers, and anyone with root on a system in the CDE.

Requirement 12.5.3 — a defined business-driven approach to scoping, documented and reviewed at least annually. The audit deliverable here is a written scoping methodology that explains why each system is in or out of scope, signed off by an accountable executive, and reviewed against any change in the environment. It sounds procedural and is. It's also one of the most commonly under-evidenced controls at audit, because contact centers tend to inherit the scope decisions made by whichever consultant ran the last engagement and never document the rationale fresh.

And the customised approach — v4.0's optional alternative to defined-approach controls — lets a mature security program design its own controls to meet the stated objective of each requirement, provided the QSA agrees the design genuinely meets the objective. Most US contact centers don't use the customised approach. The ones that do tend to be very large, with in-house QSAs and a long history of risk-based control design. For a typical mid-market contact center, defined approach is the right path — fewer judgment calls, faster audit, easier to demonstrate.

What v4.0.1 means specifically for MOTO payments#

MOTO — mail order/telephone order — is the channel category that captures every phone payment a US contact center processes. The relevant PCI guidance for MOTO sits in the SSC's Information Supplement on Protecting Telephone-based Payment Card Data, which v4.0.1 didn't update but which remains the canonical scoping document for telephone payments.

Three things matter for MOTO specifically. First, the telephony environment itself is in scope by default — the SBC, the SIP trunk, the recording platform, and any system connected to those. Second, agent-leg capture of card data brings the agent desktop, the CRM, the workforce-management platform, and any AI co-pilot into scope. Third, the IVR leg is in scope to the extent that it handles card data; an IVR that only takes account numbers and routes to an agent is out of CDE scope, but an IVR that takes a payment is squarely in.

The combined effect is that a typical US contact center processing MOTO payments without architectural separation has an in-scope footprint that includes essentially every system the contact center operates. v4.0.1 didn't change this, but the new MFA and script-integrity requirements made the cost of running that wide a scope materially higher than it was under v3.2.1.

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 American contact centers, 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. State attorneys general are increasingly active on data-security incidents under the wave of new state privacy laws (California's CCPA/CPRA, Virginia's VCDPA, Colorado's CPA, Connecticut's CTDPA, and the rest), and they don't view PCI gaps charitably when a breach lands on their desk. Late-adopter contact centers are sometimes solving the same control twice in two regimes, which is a clue the underlying architecture needs a rethink rather than another patch.

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 honoring 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.

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

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

Across the contact center programs 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 authorization. v4.0.1 is unambiguous: any recording that holds CVV, full magnetic-stripe data, or PIN data after the transaction is authorized 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 business case for it is laid out in our piece on how channel separation pays off for US businesses.

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 center 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 from 329 controls (SAQ D) down to 22 (SAQ A). The annual assessment effort shrinks. The blast radius of a worst-case breach — the thing your CFO actually loses sleep over, particularly with state-AG notification timelines hovering at 30-72 hours in most US jurisdictions — shrinks too. For the foundational explainer on why phone payments need a specific compliance posture in the first place, see our pillar on PCI compliance for telephone payments.

For US merchants taking phone payments at scale, 3DS2 also matters here. You're not required to use it the way European merchants are under PSD2, but most issuers will give you a liability shift on chargebacks if you do — and the OTP step needs to live somewhere the agent can read it without dropping back into PCI scope. A clean masking architecture handles the OTP through the same secure path as the card details, so the agent stays out of scope throughout.

The customised approach: when it's worth considering#

v4.0 introduced the customised approach as an alternative path to compliance for organizations with mature security programs. The idea is simple: instead of meeting a defined control word-for-word, you design your own control that meets the stated objective, document why it works, and get the QSA to sign off. The mechanism is genuine — but it's not for everyone, and most US contact centers are better off staying on the defined approach.

The customised approach is worth considering when you have a control environment that already exceeds the defined requirement and you'd rather not retrofit a duplicate control just to satisfy the letter of the standard. Large financial-services contact centers with internal red-team programs sometimes use it for vulnerability management. Large healthcare contact centers with strict HIPAA-driven access controls sometimes use it for access management. The common thread is in-house security maturity that produces a control story the QSA can validate without translating it back into the defined-approach language.

It's not worth considering when the control environment is built around inherited assumptions, the in-house security team is small, or the QSA relationship is new. The customised approach requires extensive documentation — a targeted risk analysis for each customised control, an objective-mapping document, evidence of the control's design and ongoing effectiveness, and a formal QSA review. For a mid-market contact center, the documentation overhead usually outweighs the savings versus simply implementing the defined control.

The practical recommendation: stay on the defined approach for v4.0.1's first full assessment cycle, build the evidence library and the relationship with the QSA, and revisit the customised approach in year two or three if there's a specific control area where it would materially help. The customised approach is a tool, not a shortcut.

What the transition timeline really looked like#

The transition from v3.2.1 to v4.x took place across three calendar windows, and the order of the deadlines matters for understanding why some contact centers are still catching up.

v4.0 was published on 31 March 2022, with v3.2.1 retired on 31 March 2024 — two years of overlap during which assessors could attest against either version. Most contact centers attested against v3.2.1 in 2023 and into early 2024, deferring the v4.0 work as long as the option was open. The future-dated requirements within v4.0 — script integrity, MFA expansion, phishing-resistant MFA, and the others — were initially flagged as "best practice" until 31 March 2025, after which they became fully enforceable.

v4.0.1 was published on 11 June 2024 and became the live version at the same 31 March 2025 deadline. A contact center that did its v4.0 work in 2024 and attested in early 2025 likely attested against v4.0.1; a contact center that delayed and attested mid-2025 attested against v4.0.1 by default. Either way, the 2026 assessment cycle is the first one where everyone is on the same standard with the same enforceable requirements. That's why audit findings tightened sharply in late 2025 and through Q1 2026 — assessors finally have a consistent benchmark.

How to read your scope under v4.0.1#

The annual scope review is the requirement most contact centers 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 center. 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.

What to ask vendors when buying for v4.0.1#

If you're evaluating a contact center 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, across $500M+ in processed card payments — 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 center 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 center architectures suit different patterns. A vendor that only offers one is forcing your architecture to bend round their constraints. The cloud-native platforms US merchants tend to deploy on — Five9, NICE CXone, Amazon Connect, RingCentral, Talkdesk, Zoom Contact Center — each have integration nuances worth checking up front. Our overview of cloud contact center solutions covers the platform-side considerations in more depth.

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 US financial services contact center is different to a retailer's. Paytia customers span retail, healthcare, financial services, insurance, education, and government — happy to share references on a call once we know what fits your shape. For healthcare-specific guidance, our piece on HIPAA-compliant credit-card processing covers the regulatory overlap.

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 umbrella pillar on the merchant-facing side, our solution page for the right way to take card payments over the phone, walks the architecture options end to end.

Worked example: v4.0.1 transition for a 200-agent US contact center#

Take a 200-agent US contact center processing around 8,000 phone payments a month for a national specialty retailer. Pre-transition, the environment ran SAQ D with pause-and-resume on the recording platform. The QSA engagement consumed roughly four weeks of internal time annually, ASV scanning ran quarterly across 40+ in-scope systems, and the agent-training program included a multi-hour PCI module per new hire.

The v4.0.1 transition added four specific work items. First, every administrative console — the contact center platform admin UI, the recording platform UI, the CRM payment-fields views, the BI tool's transaction tables — needed phishing-resistant MFA, which meant a FIDO2 hardware-token rollout to about 25 staff. Second, the scope review for 12.5.3 needed a written methodology document, executive sign-off, and a formal change-tracking process for new integrations. Third, the script-integrity work for 6.4.3 covered the hosted payment iframe on the customer portal and the click-to-pay overlay inside the agent CRM, both of which needed a script inventory and integrity monitoring. Fourth, the pause-and-resume workflow needed to be replaced with technical masking because the QSA had flagged the existing process as a residual risk in two consecutive years.

The combined cost of those four work items, done as a v4.0.1-only transition, came in around $180,000 in year one (consulting, FIDO2 tokens, integration work, masking vendor implementation, additional QSA time). The post-transition annual run-rate dropped from roughly $90,000 to roughly $35,000 because the SAQ moved from D to A and the in-scope footprint collapsed. Net payback inside two years, with the descoping work also unlocking remote-agent flexibility the contact center hadn't been able to offer under the prior architecture.

The control areas QSAs are testing hardest in 2026#

The shift from v3.2.1 to v4.0.1 also shifted what QSAs spend time on during the assessment. Three control areas are getting noticeably more attention in 2026 audits than they got under the prior standard.

Access governance is the first. Under v4.0.1, the QSA wants to see a documented joiners-movers-leavers process that covers every system in scope, with timestamps showing access was granted on the correct day, modified when role changed, and revoked on the leaver date. For a contact center with 30-50% annual agent attrition, the volume of access changes is substantial — and the audit gap is usually access that wasn't revoked promptly when an agent left. The fix is process-driven: tie access provisioning to the HR system, automate revocation on the termination event, and produce the audit-trail report from a single source.

Logging and monitoring is the second. Requirement 10 has always asked for log retention and review, but v4.0.1's emphasis on "tamper-resistant" logging pushes most contact centers toward a centralized SIEM or log-management platform with write-once storage. The QSA wants to see a sampling exercise: the assessor picks a transaction, asks for the logs across every system that touched it, and tests whether the picture is complete and consistent. Gaps in the log chain are flagged immediately.

Vulnerability management is the third. Requirement 6's reverted language on "critical, within 30 days" sounds permissive but isn't — the QSA wants evidence that you found the critical vulnerability, prioritized it, patched it, and verified the patch within the window. A contact center with a slow patch cadence on its telephony platform, its agent desktops, or its recording infrastructure gets pinged here, particularly if the QSA can find a publicly disclosed vulnerability that wasn't patched.

The remote-agent question under v4.0.1#

Remote and hybrid agent operations got harder under v4.0.1, not easier. The standard treats a home-working agent's environment as part of the cardholder data environment if the agent handles card data, which means the same physical-security controls (Requirement 9), access controls (Requirements 7 and 8), and logging requirements (Requirement 10) apply to the kitchen-table desk as to the office floor.

Three approaches exist in practice. The first is to ban remote payment-handling entirely and route every card transaction through on-site agents. That's the simplest from a compliance perspective and the worst from a recruitment and retention perspective — particularly in tight US labor markets where flexible working is increasingly a baseline expectation. The second is to invest heavily in remote-monitoring infrastructure: VDI, kernel-level screen-monitoring agents, mandatory background sound capture, periodic photo audits of the home workspace. The compliance posture is defensible but the agent experience is poor enough to drive attrition.

The third is to architect the environment so card data never reaches the agent in the first place. If the masking layer captures the card data and the agent only sees the last four digits on the gateway response, the agent's environment doesn't need physical-security controls for cardholder data because there's no cardholder data in it. The agent can work from anywhere. The compliance posture stays clean. This is the approach most US contact centers with substantial remote workforces have moved toward over the last two years, and it's the architectural answer to a problem v4.0.1 made meaningfully harder.

The interaction with US state privacy law#

v4.0.1 doesn't replace state privacy obligations — it sits alongside them. A contact center in California operates under both PCI DSS and the CCPA/CPRA framework. A contact center in Virginia operates under PCI DSS and the VCDPA. The same logic applies in Colorado, Connecticut, Utah, Texas, Oregon, Montana, Tennessee, Iowa, and the other states with active general-purpose privacy statutes as of 2026.

The interaction matters in two practical places. First, breach-notification timelines under state privacy laws are typically tighter than the operational windows most PCI incident-response playbooks assume — 30 days in some states, faster in others if the breach affects more than a threshold number of residents. A contact center running a forensic investigation under PCI requirements still has to meet the state notification deadline, which means the IR plan needs both regimes wired in from the start. Second, consumer rights under state privacy laws — access, deletion, correction — apply to any personal data the contact center holds, including transaction records and call recordings. A descoped architecture that doesn't retain card data alongside the recording makes both regimes meaningfully easier to operate.

For contact centers handling outbound payment collection calls, there's a separate overlay: TCPA compliance on the call itself. Our piece on TCPA compliance for payment calls covers the consent and dialing-mode requirements that sit upstream of any PCI architecture decision.

How the gateway choice affects v4.0.1 posture#

The gateway you authorize against — Stripe, Braintree, Authorize.Net, Cybersource, Adyen US, Worldpay (FIS), or a smaller specialist — sets the upper bound on what architectural patterns are available to you, and it sets the floor on how clean your descoping evidence can be.

Every major US gateway publishes its own AOC and supports tokenization, hosted payment fields, and direct API integration. The choice points worth checking are: does the gateway support the integration pattern the masking vendor uses (the answer is almost always yes for SIP/API integration, sometimes more nuanced for WebRTC), does it return a token that your CRM can store without bringing the CRM into scope, and does its AOC cover the geographic regions you operate in. The last point matters more for contact centers with international customer bases — a gateway that's Level 1 in the US but operates a different posture in the EU or APAC can complicate a multi-region descoping story.

The right mental model is: the masking layer is what keeps card data out of your environment, the gateway is what authorizes the payment, and the two need to play cleanly together. Vendors who have done dozens of integrations with each major US gateway will quote you a faster, more predictable implementation than vendors learning the integration on your project.

What sits behind a Paytia deployment#

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. Our New York office (447 Broadway) runs implementations across North America, and we've processed $500M+ in card payments for retailers, healthcare networks, and contact center operators since the company started. 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. Organizations 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 authorization 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 US contact center realistically remove?

A properly implemented DTMF masking architecture can take up to 96% of contact center 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.

What's the difference between the defined approach and the customised approach?

The defined approach is the standard, prescriptive path — meet each control as written. The customised approach lets you design your own control to meet the stated objective, with QSA agreement and documented evidence the control genuinely meets the objective. Most US contact centers use the defined approach; the customised approach is mainly used by very large organizations with in-house security maturity.

Does v4.0.1 affect IVR self-service payments?

Yes. An IVR that takes a payment handles cardholder data and is in PCI scope. The same masking architecture that descopes assisted calls also keeps the IVR's payment leg isolated from the rest of the contact center's environment. Our walk-through on IVR payments covers the customer-side experience and the security architecture.

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 US office on +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
• PCI Security Standards Council, Information Supplement: Protecting Telephone-based Payment Card Data
• NIST SP 800-63B Digital Identity Guidelines (authentication and lifecycle management)

Related reading#

• PCI Compliance for Telephone Payments: 2026 US Guide
• Channel Separation: How It Pays Off for US Businesses
• What Is an IVR Payment? The 2026 Plain-English Guide
• What Is Tokenization? A Plain-English Guide
• Cloud Contact Center Solutions: Features and Security Guide

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