What changed in v4.0.1
PCI DSS v4.0.1 is technically a minor revision of v4.0 — the version that replaced v3.2.1 in March 2024. The changes between v4.0 and v4.0.1 are clarifications and corrections, not new requirements. The bigger shift is between v3.2.1 and the v4 family.
The 13 future-dated requirements that were recommended best practice under v4.0 became mandatory on 31 March 2025 under v4.0.1. These are the ones that catch out contact centres most often:
- Requirement 6.4.3— payment page scripts must be inventoried, justified, and integrity-checked. Many contact centres pulling card details into a hosted payment page hadn't done a script inventory before; now they must.
- Requirement 8.6.2— interactive login by application accounts must be limited to legitimate uses, with strong authentication. Tellingly applicable to agent-assisted payment flows where the agent's terminal initiates the capture.
- Requirement 11.6.1 — change-and-tamper detection on payment pages, with alerts on unauthorised modification. This is partially the scope-creep that pushed many contact centres to look at descoping rather than continuing to extend their CDE.
- Requirement 12.3.1 — targeted risk analyses, documented and reviewed at least annually, for each requirement that allows flexibility.
- Requirement 12.10.7— incident response procedures must include detection of and response to PAN being stored where it shouldn't be.
There are eight more in the same bucket. The pattern is the same: things contact centres had been told for years they should do are now things they must do, with documentation and evidence.
What this means for contact centres specifically
Contact centres taking card payments over the phone sit in one of three categories under v4.0.1:
Category 1 — agents hear card data.The worst position to be in. The agent's headset is in scope. The call recording is in scope. The agent's workstation is in scope. The contact-centre LAN is in scope. The IVR is in scope. Most of the call-leg infrastructure is in scope. The targeted risk analysis required under 12.3.1 has to cover all of it.
Category 2 — agents stay on the line, but card data is masked or removed before it reaches them. This is what DTMF masking technology does. The customer keys their card details on their handset; the tones are intercepted before they reach the agent's audio leg. Agents do not hear card data and recordings do not capture it. The card-data environment shrinks dramatically — typically by around 96 per cent in scope volume.
Category 3 — fully self-service IVR, no agent involvement. Card data never touches an agent at all. Scope reduction is similar to Category 2 but the customer experience is more transactional. Suits high-volume scenarios like utility bills.
Most UK contact centres operate a mix of Category 2 and Category 3, with DTMF masking on agent-assisted calls and IVR for out-of-hours self-service. Category 1 operators are increasingly rare among regulated buyers, but pockets remain in healthcare and SME insurance.
Where DTMF masking fits in v4.0.1
PCI DSS v4.0.1 does not mandate DTMF masking by name. It does, however, accept the principle behind it — that the most reliable way to remove a system from the cardholder-data environment is to ensure cardholder data never enters it.
This is why DTMF masking sits well with the v4.0.1 emphasis on documented scope reduction. The targeted risk analysis required under Requirement 12.3.1 is much shorter when there is genuinely nothing to risk-analyse, because the agent leg, the recording, and the contact-centre LAN do not see card data at all.
Paytia has been PCI DSS Level 1 since founding — the highest tier, required for any organisation handling more than six million card transactions a year — and has maintained that certification through every revision of the standard, including the move from v3.2.1 to v4.0 to v4.0.1. Customers using Paytia DTMF masking typically reduce their PCI scope by up to 96 per cent, which means a v4.0.1 audit covers a fraction of the systems it would otherwise need to.
How to verify your v4.0.1 compliance status
A short checklist you can run this week:
- Confirm the version of PCI DSS your last attestation was against. If it says v3.2.1 or v4.0, you have a gap.
- Identify which Self-Assessment Questionnaire (SAQ) you used. SAQ-D-MER is the most common for contact centres; SAQ-C-VT applies to virtual terminals; SAQ-B-IP applies to IP-connected POI devices.
- Run the targeted risk analysis required under Requirement 12.3.1 for each requirement that allows flexibility. The most commonly missed step in early-2026 audits.
- Inventory payment page scripts and confirm change-and-tamper detection is in place if you operate any hosted payment pages.
- Verify your incident response procedures specifically address PAN-where-it-shouldn't-be detection.
If items 3, 4, or 5 surface gaps, the question becomes whether to remediate inside the existing CDE or to descope by removing card data from the path entirely. The economics increasingly favour descoping.
Common gaps and how to close them
The four gaps we see most often when contact centres come to us mid-audit:
Call recordings still contain DTMF tones. The recording was made before masking was introduced, or the masking was implemented incorrectly. Solution: confirm DTMF suppression is happening at the right point in the call leg, and audit the recording archive for tone-bearing files.
Agent workstation drift. A workstation that was previously out of scope is brought into scope by an unrelated change — a new browser extension, a screen-share tool, a CRM integration. Solution: re-run the targeted risk analysis against the actual deployed configuration, not the documented one.
Hosted payment page script inventory missing. A common one for contact centres that added a virtual terminal during 2020. Solution: produce the inventory required under 6.4.3.
Incident response gaps.The runbook covers a breach but not "we found PAN stored in a Slack channel." Solution: amend the runbook to cover stored-PAN-in-the-wrong-place detection and response.
Talk to a specialist about your scope
If you're taking card payments over the phone and you're not confident your v4.0.1 attestation will pass cleanly, the conversation usually starts with a simple question — what is actually in scope today, and what could be out of scope tomorrow if card data never reached the agent leg in the first place. Talk to a Paytia specialist and we'll walk through your environment in 30 minutes.
