PCI DSS 4.0.1 Is Fully in Force. What Are Assessors Finding Now?
By Chuck Lerch, Founder and CEO, Cyberuptive
Every PCI DSS assessment now tests the full 4.0.1 standard. The 51 requirements that were "future-dated" best practices became mandatory on March 31, 2025, and PCI DSS 3.2.1 was retired a year before that (PCI Security Standards Council). If your last assessment predates that date, your next one will look materially different.
Credit unions, insurers, healthcare billing teams, and any business that takes cards online have now been through at least one assessment cycle under the full standard, or are about to be. Here is what changed, and where we see organizations struggle to produce evidence.
Where PCI DSS stands
PCI DSS 4.0 was introduced in 2022. Version 3.2.1 was retired on March 31, 2024, and the future-dated requirements, which had been included as best practices since March 2022, became effective on March 31, 2025 (PCI SSC). Version 4.0.1 is a limited revision of 4.0 with clarifications and no new or deleted requirements, and it is the only active version (Compyl). Of the 64 new requirements in 4.x, 51 were the future-dated ones (PCI SSC).
The e-commerce script rules
The requirements that generated the most questions are 6.4.3 and 11.6.1. Together they require that scripts on payment pages are authorized and integrity-checked, and that unauthorized changes to payment pages are detected. Their purpose is to reduce e-skimming, where malicious JavaScript captures card data in the browser (PCI SSC).
The Council also changed SAQ A. Requirements 6.4.3, 11.6.1, and the related targeted risk analysis in 12.3.1 were removed from SAQ A, though they remain in the standard. In exchange, SAQ A merchants must confirm their site is not susceptible to script attacks that could affect their e-commerce systems. That confirmation can come from protections the merchant deploys, protections a third party deploys, or confirmation from the compliant provider supplying the embedded payment iframe, when its solution is implemented as instructed (PCI SSC, FAQ 1588).
The practical takeaway: an iframe does not end the conversation. You still need to show how you know the page hosting it has not been tampered with.
Where evidence usually falls short
The future-dated requirements share a theme. Many shift from "have a control" to "show the control is operating and justified." The areas we most often see organizations scramble on:
- Targeted risk analyses. Several requirements let you set your own frequency for an activity, but only if a documented targeted risk analysis supports it. Missing analyses are an easy finding.
- Authenticated internal vulnerability scanning. Unauthenticated scans no longer satisfy internal scanning. Credentials, coverage, and remediation tracking all need evidence. Our vulnerability scanning service is built around producing that trail.
- Multifactor authentication for all access into the cardholder data environment, not just remote and administrative access.
- Automated log review. Manual daily review of logs does not scale and is hard to evidence. Assessors expect automated mechanisms and documented follow-up, which is where a managed SOC earns its keep.
- Payment-page change detection under 11.6.1 for merchants not using SAQ A.
Service providers carry extra weight
Third-party service providers face additional requirements, and merchants depend on them. If you outsource payment processing, hosting, or security monitoring, your responsibility matrix needs to show who performs each requirement. Ask each provider for its Attestation of Compliance and confirm the services you use are in its scope. The same discipline applies to security provider contracts: if a provider touches cardholder data or the systems that protect it, the contract should say how fast it will tell you about an incident.
A next-assessment checklist
- Confirm your SAQ type or ROC scope still matches how you take payments today.
- List every requirement that relies on a targeted risk analysis and confirm each one exists, is dated, and was reviewed.
- Run an authenticated internal scan now, before the assessor asks.
- Inventory scripts on payment pages and document how each is authorized.
- Refresh your responsibility matrix with every third-party service provider.
For credit unions, the credit union exam readiness checklist pairs well with this list, since examiners and PCI assessors increasingly ask for the same evidence. If you want help scoping, our financial services practice can start with a short review.
Frequently asked questions
Are the PCI DSS 4.0 future-dated requirements mandatory now?
Yes. The 51 future-dated requirements became effective on March 31, 2025 and must be fully considered in PCI DSS assessments from that date.
What is the difference between PCI DSS 4.0 and 4.0.1?
Version 4.0.1 is a limited revision of 4.0 that clarifies wording and guidance. It added and deleted no requirements, and it is now the only active version of the standard.
What do PCI DSS requirements 6.4.3 and 11.6.1 require?
They require that payment-page scripts are authorized and integrity-checked, and that unauthorized changes to payment pages are detected. They target e-skimming attacks that steal card data in the browser.
Do SAQ A merchants still need to worry about payment-page scripts?
Yes. Requirements 6.4.3, 11.6.1, and 12.3.1 were removed from SAQ A, but SAQ A merchants must confirm their site is not susceptible to script attacks, using their own protections, a third party's, or confirmation from their compliant iframe provider.
Is PCI DSS 3.2.1 still valid?
No. PCI DSS 3.2.1 was retired on March 31, 2024.