If you take card payments by phone and your next PCI audit is on the calendar, this is the year the questions get sharper. PCI DSS v3.2.1 retired on 31 March 2024, and the future-dated controls in v4.0 became mandatory in March 2025. The current version on the table is v4.0.1, published in June 2024 with small clarifications. There's no "transition window" left — your Report on Compliance or SAQ in 2026 is judged against v4.0.1 outright.
For phone payments specifically, three things changed in a way that catches teams out. First, the customised approach gives you a route to meet a requirement with a non-prescriptive control, but you have to prove it works through a targeted risk analysis. Second, access control tightened — MFA for any non-console admin access into the cardholder data environment, no shared accounts, no role-based passwords. Third, the script-integrity rules under Requirement 6.4.3 now bite even on self-service payment portals that embed third-party JavaScript.
This piece walks through a 2026-ready checklist — seven practical requirements an operator should be able to evidence on demand — plus the new v4.0.1 traps, the SAQ question, and a short FAQ. It's written from where we sit as a PCI DSS Level 1 service provider. If you want the wider pillar view first, our PCI DSS 4.0 contact centre guide covers the principles in more depth.
Requirement 1: Know your phone payment surface area#
Before a single control gets reviewed, you need an honest map of where card numbers can enter your environment by phone. That's a wider surface than most teams realise. There's the obvious inbound call to an agent, but there's also self-service IVR, scheduled callbacks where a customer hits 1 to be called back about an unpaid invoice, web chat that escalates to a phone call mid-session, and SMS-to-call flows where a marketing message drops a click-to-call link.
Each path needs a diagram tagged with how cardholder data flows through it. If your agents transfer to a third-party IVR for the payment leg, that transfer point matters. If a CRM screen pops with a "take payment" button that opens a phone-attached payment widget, that's another path. If your contact centre records the entire call including DTMF tones, that recording channel has to be either descoped or treated as in-scope.
The scope review under Requirement 12.5.2 is annual now, and it's the artefact your assessor will ask for first — a scope diagram with timestamps and sign-off, an inventory of every system in scope, and a written justification for anything you've excluded. The wider PCI compliance for telephone payments view spells out the common path-mapping mistakes.
Requirement 2: Take cardholder data out of call recordings#
Requirement 3.4 says stored PAN must be rendered unreadable wherever it lives — and a call recording with a Primary Account Number in the audio is storage. Most contact centres record everything by default for QA. Without a control on the payment moment, every recording becomes in-scope cardholder data the second a customer reads out their card number. The recording archive, the backup tape, the QA tooling, the transcription provider, the analytics dashboard — all dragged into your cardholder data environment by association.
The cleanest fix is to take the card data out of the audio path entirely. DTMF masking does this: the customer keys their digits, the tones are intercepted by a Level 1 service provider before they reach your agent's leg, and your recording captures silence or substituted neutral tones. The agent hears no digits, the recording has no digits, the QA listener has no digits. DTMF masking and PCI compliance covers the architecture in detail.
The alternative — pause-and-resume — relies on agents stopping the recording before card capture and starting it again afterwards. It works on paper. In practice, the failure rate is high enough that PCI assessors look at it with a sceptical eye. A single missed pause leaves a PAN in the archive. If you're shopping for a 2026 architecture, masking is the route that scales. Requirement 3.5 is the partner rule: even when PAN is stored, it must be protected with strong cryptography at rest. The shorter your storage list, the less surface area for 3.5 to bite. Our piece on channel separation business benefits covers the wider commercial impact.
Requirement 3: Control who can hear card details#
Requirement 8.3.6 under v4.0.1 sharpened access control for the cardholder data environment. MFA is now required for all non-console administrative access — no exceptions for trusted networks or internal subnets. Shared accounts are out. Generic agent logins with rotating passwords on a sticky note are out. Each person who can reach a system in scope needs a unique credential, MFA, and a logged access path.
For phone payments, this is where masking pays for itself a second time. If your agents never hear the card digits, the agent population isn't an in-scope user group for the payment system. You don't have to roll MFA out to a thousand contact centre seats because none of them have administrative access to anything that touches a PAN. The MFA scope shrinks to the handful of integration engineers, payment ops staff, and audit reviewers who maintain the masked-payment plumbing.
Without masking, the alternative is heavier. Every agent who can hear card digits is touching cardholder data — which means every workstation needs to meet the in-scope hardening standard, every account needs MFA, and every login to the recording archive needs the same treatment. The economics rarely work out at scale. This is the requirement where teams discover they've been running an informal SAQ D environment without realising it.
Requirement 4: Encrypt cardholder data in transit#
Requirement 4.2.1 says strong cryptography is required for cardholder data crossing open public networks. In practice, your payment platform's connection to the acquiring bank should be TLS 1.2 or higher. TLS 1.0 and 1.1 have been disallowed for a long time. If you're still seeing TLS 1.0 anywhere on a payment path in 2026, that's a finding before the assessor even asks a question.
The phone-payment wrinkle is the SIP and RTP traffic that carries voice between the telephony provider, the masking layer, and the contact centre. If a masking provider sits in the call path and DTMF tones are encoded as in-band audio, the audio leg between the customer and the masking layer must be protected. SIP over TLS plus SRTP is the standard pattern. Ask your masking provider exactly which leg they protect, where the decryption happens, and what their AoC says about transmission controls. A vendor who can't answer that crisply is a vendor whose AoC won't help you when your assessor reads it.
Requirement 5: Monitor and log#
Requirement 10 covers logging and audit trails. The big v4.0.1 shift is the daily review obligation — Requirement 10.4.1 says security event logs must be reviewed at least daily, not weekly. That's hard to meet by hand at scale, which is why most contact centres run a SIEM with automated alerts. The point isn't human eyeballs on every log line; it's that an automated correlation rule fires on the anomalies and a human acknowledges each one.
For phone payments, the logs that matter are the payment attempt records — every initiation, every authorisation request, every response code, every failure — plus the access logs for any system that handles them. If your masking provider hosts the payment leg, ask them how their logs reach you. Some ship structured events to your SIEM. Some give you a portal you can pull from. Either pattern is fine; what isn't fine is finding out at audit time that your provider's logs are six time-zones away in a format your team can't ingest.
Requirement 11.4.2 covers intrusion detection on the cardholder data environment perimeter. Internal scans run quarterly under 11.3.1.1; external scans need an Approved Scanning Vendor under 11.3.2. The catch in v4.0.1 is that internal scans now have to be authenticated — credentialed scans rather than the lighter unauthenticated sweeps that some teams used to get away with. Pull together a monthly evidence pack: log review attestation, scan results, an open-issue tracker with remediation timelines.
Requirement 6: Have a tested incident response plan#
Requirement 12.10 says you need a documented incident response plan, tested annually, with named roles and a clear escalation path. Under v4.0.1, the requirement is more specific about what "tested" means — a tabletop exercise with the named roles in the room, scenarios run end to end, and documented findings with remediations. A plan that lives on a shared drive and has never been opened in anger doesn't count.
For phone-payment incidents, the scenarios worth rehearsing are a confirmed card-data exposure in call recordings, a payment-platform outage during peak call hours, a credential compromise on an integration account, and a vendor incident at the masking provider with knock-on impact. The card-data exposure scenario triggers acquirer notifications under your merchant agreement and potentially regulator notifications under UK GDPR — both clocks start fast, so the playbook should be written down rather than improvised at 11pm.
Requirement 7: Manage your third parties#
Requirement 12.8 covers third-party service provider management. Every PCI-relevant vendor needs a written agreement that acknowledges their responsibility for the cardholder data they handle, you need their current Attestation of Compliance on file, and you need a list of which PCI DSS requirements are theirs versus yours under a clear responsibility matrix.
For a phone-payment stack, the typical service provider list runs to four or five names — the masking provider, the payment gateway, the contact centre platform, the acquiring bank, and sometimes a telephony carrier. Ask each one for their AoC every year. Cross-check it against your scope diagram. The mistake teams make is assuming "PCI Level 1 service provider" on a marketing page is the same as "covers the thing I need them to cover". It often isn't. A masking provider's AoC won't cover the agent UI you've built around it — that integration layer is yours.
What's new in v4.0.1 that catches teams out#
Three v4.0.1 changes trip up phone-payment operators most often. The first is the customised approach — alongside prescriptive "defined approach" requirements, you can meet a control through any equivalent measure as long as you document a targeted risk analysis, define the customised control, and have your QSA validate it. The upside is flexibility for unusual architectures. The downside is paperwork; every customised control needs its risk analysis, control description, and validation evidence.
The second is Requirement 6.4.3 on payment-page script integrity. It was written with e-commerce skimming attacks in mind, but it applies to any payment page that loads JavaScript. If your phone-payment vendor exposes a self-service portal or a hosted page that an agent or customer hits in a browser as part of the flow, every script on that page needs to be inventoried, justified, and integrity-checked.
The third is the authenticated internal vulnerability scan requirement under 11.3.1.2. Internal scans now have to log in and look at the system from a credentialed perspective. If your scanning tool was unauthenticated, you'll need to provision service accounts, agree the scope with the system owners, and rerun the baseline.
The SAQ question#
Which Self-Assessment Questionnaire applies depends on how card data flows through your environment, and that's where DTMF masking has its biggest paperwork impact. SAQ D is the full version — around 300 questions across all twelve requirements. It applies to merchants who store, process, or transmit cardholder data and don't fit a more specific scenario. A contact centre where agents hear card numbers and recordings capture them is squarely in SAQ D territory.
SAQ A is the shortest at around 22 questions. It applies where all card data functions are performed by a PCI DSS compliant third party and the merchant's systems never touch cardholder data. SAQ A-EP sits between them, for merchants whose systems redirect or partially handle the payment flow without storing data.
A properly implemented masking architecture can move a contact centre from SAQ D back to SAQ A or SAQ A-EP. If your agent's screen never displays PAN, your systems never store it, your recordings never capture it, and the masking provider runs the full payment lifecycle, you're typically in SAQ A territory. Always confirm with your acquirer or QSA — they own the call. The wider article on what "descoped" actually means is worth a read before you write the determination up.
Frequently asked questions#
When does PCI DSS 4.0.1 become mandatory?
It already is. PCI DSS v3.2.1 retired on 31 March 2024 and the v4.0 future-dated requirements became mandatory on 31 March 2025. The current version is v4.0.1, published June 2024 with small clarifications. Any audit or self-assessment in 2026 is judged against v4.0.1 — there's no transition window left.
Does PCI DSS 4 require DTMF masking?
No. PCI DSS doesn't mandate any specific technology — it sets outcomes the merchant has to achieve. You can be compliant without DTMF masking if you have other controls that keep card data out of your environment, such as fully transferring the payment leg to a hosted IVR. Masking is popular because the alternatives — pause-and-resume in particular — are unreliable at scale and a single failure creates a compliance breach.
Can we self-assess for phone payments?
Yes, if your merchant level allows it. Level 1 merchants always need a Report on Compliance from a QSA. Levels 2 to 4 can self-assess using the appropriate SAQ, with the choice driven by your data flow. Most phone-payment operators end up either at SAQ A (descoped via masking) or SAQ D (not descoped). Talk to your acquirer to confirm.
What changes for small merchants?
The requirements don't shrink for smaller operators — they apply in full. What changes is the validation path: smaller merchants self-assess rather than commission a QSA-led RoC. The biggest win for a small phone-payment operator is descoping through masking — it converts a heavy SAQ D into a short SAQ A.
How often is recertification?
Annually. A QSA-led Report on Compliance, an SAQ, or an Attestation of Compliance — whichever applies to your level — is valid for twelve months. Quarterly ASV scans run alongside, and an annual scope review under Requirement 12.5.2 has to happen before the certification is renewed.
What's the penalty for non-compliance?
The fines come from card schemes via your acquiring bank rather than from the PCI Council directly. Typical ranges run from a few thousand pounds a month for ongoing non-compliance to six- or seven-figure fines per breach incident, plus forensic investigation costs and card-reissuance charges. The reputational cost usually outruns the regulatory cost — a publicly disclosed card-data breach is the sort of event most operators only survive once.
Where to take this next#
If your next audit is on the horizon, work backwards from this checklist. Start with the scope diagram — if you can't produce one in an afternoon, that's the first thing to fix. Then walk through each of the seven requirements above and rate yourself honestly: green, amber, red. The amber and red rows are the work for the quarter. The bigger architectural question — whether to bring DTMF masking in to descope the call recordings problem — is the highest-use decision on the list, and it tends to make every other requirement easier rather than harder.
If you'd like to walk a real call flow through the checklist with someone who's done it before, we're a PCI DSS Level 1 service provider with ten years of contact centre integrations behind us. Have a look at our DTMF masking solution for the architecture, or get in touch and we'll talk through your specific path.
Pass your next PCI DSS 4 audit with less scope to defend
Paytia's DTMF masking moves agents, call recordings, and transcripts out of PCI scope. Most clients reduce from SAQ D to SAQ A. PCI DSS Level 1 certified service provider — our AoC is available on request and slots straight into your vendor management file.
