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 US contact centers most often:
- Requirement 6.4.3— payment page scripts must be inventoried, justified, and integrity-checked. Plenty of US contact centers 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. It applies cleanly 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 unauthorized modification. This is partially the scope-creep that pushed many US contact centers to look at descoping rather than keeping on extending 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 US contact centers had been told for years they should do are now things they must do, with documentation and evidence.
What this means for US contact centers specifically
US contact centers 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-center 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. If you're also subject to HIPAA, the same recordings often pull PHI into PCI scope and vice versa.
Category 2 — agents stay on the line, but card data is masked or removed before it reaches them. This is what DTMF masking 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 percent 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 and routine subscription renewals.
Most US contact centers operate a mix of Category 2 and Category 3, with DTMF masking on agent-assisted calls and IVR for after-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 doesn't 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 make sure cardholder data never enters it.
That's 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's genuinely nothing to risk-analyze, because the agent leg, the recording, and the contact-center LAN don't see card data at all.
Paytia has been PCI DSS Level 1 since founding — the highest tier, required for any organization handling more than six million card transactions a year — and has held 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 percent, which means a v4.0.1 audit covers a fraction of the systems it would otherwise need to. That also makes the conversation with your QSA shorter and your finance team happier.
How v4.0.1 interacts with US-specific rules
PCI DSS is the global floor. US contact centers usually sit under one or more additional rule sets that PCI v4.0.1 doesn't replace but does interact with:
- HIPAA— if your call recordings capture both card numbers and PHI, you're defending breach exposure under both PCI and HIPAA. DTMF masking keeps payment audio out of the recording, which is the cleanest way to keep the two regimes from colliding.
- TCPA— call recording is fine for compliance review; what matters is what's in the recording. Card-data-free recordings stay simple to pull and review.
- State breach notification laws — California, New York, Massachusetts, and most other states define a breach in terms of personal information including card numbers. Less card data on tape = less breach surface to disclose.
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 US contact centers; 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 US 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 favor descoping.
Common gaps and how to close them
The four gaps we see most often when US contact centers 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 US contact centers 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 in the US 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.
