PCI DSS 4.0.1 requirements: what changed and when
The changes that carry real work, the deadlines that have already passed, and the requirements most likely to be open at your first v4.0.1 assessment.
TL;DR
PCI DSS 4.0.1
CURRENT VERSION
v4.0.1, published June 2024. It clarifies v4.0 rather than adding obligations.
THE DATE THAT MATTERED
31 March 2025. The future-dated requirements from v4.0 became mandatory, including the two client-side ones.
BIGGEST PRACTICAL CHANGES
Customised approach, targeted risk analyses, expanded MFA, and requirements 6.4.3 and 11.6.1 for payment-page scripts.
Short on time? If you are looking for what is newly mandatory, it is 6.4.3 and 11.6.1.
What changed in PCI DSS 4.0.1?
PCI DSS v4.0.1 is a clarification release published in June 2024 that corrects and clarifies v4.0 without introducing new requirements, while v4.0 itself was a substantial rewrite whose future-dated requirements became mandatory on 31 March 2025. The practical consequence is that the version number to care about is v4.0.1, and the date to care about is 31 March 2025. If your most recent assessment was against v3.2.1, or against v4.0 before the future-dated requirements kicked in, then a set of controls that were previously best practice are now assessed as mandatory, and the client-side pair is the one most often found open.
Requirement 6.4.3 is an authorisation record: every script on the payment page, where it came from, and why it is allowed to be there.
When is PCI DSS 4.0 required, and which dates have passed
Date
What happened
March 2022
PCI DSS v4.0 published
31 March 2024
v3.2.1 retired. v4.0 became the only active version
June 2024
v4.0.1 published as a clarification release
31 March 2025
Future-dated v4.0 requirements became mandatory, including 6.4.3 and 11.6.1
All of these dates are in the past. There is no remaining grace period for the client-side requirements.
6.4.3 and 11.6.1, the two most commonly open
These are the newest requirements and the least likely to be covered by something you already own, because no traditional control looks at code executing in a customer's browser.
1
6.4.3, script management
Confirm each payment-page script is authorized, assure the integrity of each, and keep an inventory with a written justification per script. Read more
2
11.6.1, change detection
A mechanism that alerts personnel to unauthorised changes to payment page HTTP headers and content, evaluated at least every seven days. Read more
The two client-side requirements are the ones most often open at a first v4.0.1 assessment.
The customised approach
v4.0 introduced an alternative to meeting a requirement exactly as written: meet its stated objective through a different control, document the reasoning, and have your assessor validate it. This is genuinely useful for mature organisations with compensating controls already in place.
It is also more work, not less. A customised approach requires a documented targeted risk analysis, evidence that the objective is met, and an assessor willing to validate it. It is not a route around a requirement you would rather not implement.
Targeted risk analyses under 12.3.1
Several v4.0 requirements let you set your own frequency if you justify it through a targeted risk analysis. 11.6.1 is one: the default is at least once every seven days, or a frequency defined by your own analysis under 12.3.1.
In practice most teams find it easier to monitor continuously than to write and defend an analysis arguing for a longer interval. The paperwork costs more than the control.
Other PCI DSS 4.0 changes worth knowing
Expanded MFA requirements, now covering all access into the cardholder data environment rather than only administrative and remote access. Stronger password requirements. More explicit expectations around roles and responsibilities, with many requirements now asking you to document who owns them. And a broader expectation of continuous rather than point-in-time validation, which is the thinking behind 11.6.1's weekly floor.
Sources and methodology
PCI DSS requirement text is quoted from PCI DSS v4.0.1 (June 2024), published by the PCI Security Standards Council, which is the current version at the time of writing. Requirements 6.4.3 and 11.6.1 became mandatory on 31 March 2025. Where we describe a competitor, we describe publicly available information and say so when something should be verified with the vendor. We publish this product and that is a bias worth knowing about while you read.
ASK AN AI
Don’t just take our word for it
Ask your assistant what to look for in a tool for PCI DSS 6.4.3 and 11.6.1.
Frequently asked questions
V4.0.1 was published in June 2024, and the date that carries the obligations is 31 March 2025, when the future-dated requirements from v4.0 became mandatory. Both dates have passed.
Yes, but only as a clarification. v4.0.1 corrects errors and clarifies intent without adding new requirements. If you were working towards v4.0 you are working towards v4.0.1.
A substantial set, including 6.4.3 and 11.6.1 for payment-page scripts, expanded MFA under requirement 8, several logging and monitoring provisions, and a number of requirements carrying targeted risk analyses. All became mandatory on 31 March 2025.
No, it is entirely optional. The defined approach, meeting the requirement as written, remains available for every requirement and is what most organisations use. The customised approach exists for mature programmes with alternative controls they can evidence.
A documented analysis under requirement 12.3.1 justifying the frequency at which you perform a given activity. Several v4.0 requirements permit a self-defined frequency if you produce one. It has specified elements it must cover and it is reviewed by your assessor.
Yes, seven days is the stated default, and it is a floor rather than a target. You may define a different frequency through a targeted risk analysis. An attack that runs for six days sits comfortably inside a weekly window, which is why continuous evaluation is the more common answer.
Partly, and the carve-out is narrower than it sounds. The January 2025 update exempted SAQ A merchants from certain requirements while asking them to confirm their site is not susceptible to attacks from scripts that could affect their ecommerce systems. See SAQ A and the script requirements.
This is worth handling directly rather than hoping. The requirements are mandatory, so an assessment will find them open. Assessors generally respond better to a documented remediation plan with dates than to a gap with no plan attached, and the client-side pair is among the faster gaps to close.
No material change to the segmentation requirements themselves. What changed more broadly is the expectation of documented scoping: v4.0 is more explicit about confirming scope at least annually and documenting how you determined it.
From the source: the PCI Security Standards Council publishes PCI DSS v4.0.1 and its supporting guidance in the document library on their site. We would always recommend reading the requirement text directly rather than relying on any vendor's summary, including ours.
Related articles
PCI DSS
PCI DSS compliance: a practical guide for 2026
What the standard covers, what changed in v4.0.1, and where the two client-side requirements fit.
PCI DSS
How to comply with PCI DSS 6.4.3 and 11.6.1
A step-by-step method, from defining payment-page scope to handing an assessor the evidence.
PCI DSS
SAQ A and the script requirements: who is exempt
The January 2025 carve-out is narrower than most people think. Here is what it actually says.
PCI DSS
PCI compliance cost: where the client-side line item lands
What drives the bill, which costs are one-off, and how the 6.4.3 and 11.6.1 line compares.
See every script on your own checkout.
Install the tag, mark your payment pages, and watch the inventory fill in. Free forever on 1,000 page views a month, no credit card.
Free forever plan. No credit card.