The PCI DSS v4 changes are no longer something you phase in. Version 4.0 superseded v3.2.1, which has been retired, and the set of requirements that were originally future-dated — best practice first, mandatory later — became mandatory on 31 March 2025. Any assessment you undergo now covers the complete v4 set with no transition relief attached to any part of it.
That is a different question from "what changed in v4". Most teams already read a changelog in 2023 or 2024, triaged the new items into "now" and "later", and shipped the "now" pile. The later pile is what is currently showing up as findings.
So this is not a changelog. It is an account of what the end of the transition period actually does to an assessment, which structural changes carry the most weight when a PCI DSS assessor arrives, and where the common gaps still sit.
Why v4.0.1 Is the Version You Are Assessed Against
PCI DSS 4.0.1 is the current version of the standard, and it is the one your assessor works from. It is a limited revision of v4.0 rather than a new generation: it clarified wording and corrected errors, and it did not introduce new requirements.
The practical effect is that a gap analysis built against v4.0 is still valid. An argument for re-scoping remediation because "there is a new version" does not hold. What changed is precision, not obligation.
What you should check is which version your documentation cites. Policies, network diagrams and a prior Report on Compliance that reference v3.2.1 are a visible signal to an assessor that the control set was mapped once and never revisited. The current text of the standard and its supporting documents are published at the PCI Security Standards Council.
The PCI DSS v4 Deadline and the End of Future-Dated Requirements
The PCI DSS v4 deadline that matters is 31 March 2025, the date on which the future-dated requirements stopped being best practice and became mandatory. Before that date, an entity could acknowledge a requirement, state that it was not yet in effect, and be assessed without it. After it, there is no such position to take.
This is the single most consequential thing about the current state of the standard, and it is routinely underestimated. The future-dated items were not the easy ones. They were deferred precisely because they needed engineering work, new tooling, or a change in how an activity was operated rather than documented — which is why deferring them was attractive and why the bill arrives late.
A second-order effect catches teams out. Because the future-dated requirements were handled as a separate workstream, they often sit outside the control inventory that the compliance team maintains day to day. The requirement was tracked in a project plan, the project closed, and nothing moved it into the recurring evidence cycle. The control exists; the evidence of it operating over the assessment period does not.
Not sure which of the formerly future-dated requirements you can actually evidence?
Share your work email and we'll map the v4 requirements that lost their transition relief against what your current evidence set would support in an assessment.
The PCI DSS v4 Changes That Reshape an Assessment
The PCI DSS v4 changes that reshape an assessment are structural rather than additive. Counting new requirements is a distraction — widely reported totals differ depending on how sub-requirements and service-provider variants are tallied, and the number tells you nothing about effort. These six categories are what actually alter how you are assessed.
The Customised Approach v4 Introduced
The customised approach v4 introduced lets an entity meet a requirement's stated objective by means other than the defined approach. You are choosing between 2 routes for each requirement, and you make that choice individually rather than once for the whole assessment. Take the customised route and you document the controls you are using instead, support the choice with a targeted risk analysis, and have your QSA validate that the objective is genuinely met. The defined approach remains fully available, and most requirements are still assessed that way.
The customised approach is not a shortcut, and treating it as one is the mistake. It moves work off implementation and onto documentation and analysis — you now owe a reasoned argument, evidence that the control achieves the objective, and a QSA willing to validate it. For most entities, for most requirements, the defined approach is cheaper and faster. The customised approach earns its keep in a narrow band: where you have a mature control that genuinely achieves the objective by a different mechanism and you can afford to document it to that standard.
Targeted Risk Analysis Instead of a Chosen Frequency
Targeted risk analysis is the concept that where the standard lets you set the frequency of an activity, you must justify that frequency rather than pick one. "Quarterly" is no longer an answer on its own. "Quarterly, because this analysis of the asset, the threat and the control's failure mode supports quarterly" is.
This is a cheap requirement to satisfy and an easy one to fail, because the artefact is new. Teams that already review frequencies informally have the reasoning and not the document. An assessor cannot credit reasoning that lives in someone's head. Produce a short written analysis — 1 to 2 pages is usually ample — for every activity whose frequency you set yourself, and the finding disappears.
Stronger Authentication Expectations
Authentication expectations rose in v4, and this is where remediation effort concentrates. Multi-factor authentication coverage broadened — for access into the cardholder data environment and for administrative access — and the handling of passwords and other credentials changed alongside it.
The coverage question is the hard part, not the technology. MFA on the VPN and the identity provider is usually settled. Jump hosts, database administration paths, vendor and contractor access, and service accounts used interactively are where the gaps are, and they are exactly the paths an assessor walks.
Payment Page Script Integrity Management
Payment page script integrity management is the change most likely to catch out an e-commerce merchant. The expectation is that you know which scripts execute on a payment page, that each one is authorised, and that unauthorised change is detected.
Few merchants had any of this before v4, because nobody was asking. The script inventory on a real payment page typically includes tag managers, analytics, session recording, chat widgets and A/B testing tools — often injected by marketing without engineering involvement. Building the inventory is usually the point at which a team discovers how many third parties execute code on the page where a card is entered.
It also interacts with eligibility for the simplest self-assessment questionnaires. If your model assumed a minimal SAQ, confirm that assumption still holds under v4 before you plan the assessment around it — the SAQ types and their eligibility criteria are where that gets decided.
Continuous Operation Over Point-in-Time Evidence
v4 puts far more weight on continuous operation than on point-in-time evidence, and it asks for roles and responsibilities to be documented for each requirement rather than once, globally. An assessor is looking for a control that ran throughout the period with a named owner, not a screenshot dated the week before fieldwork.
The documented-ownership change sounds administrative and is not. "Who performs this activity, and who is accountable for it" exposes orphaned controls quickly — the ones inherited from a departed engineer, or assumed to belong to a managed service provider without anything in writing.
Service Provider Expectations Rising Faster
Service provider expectations rose faster than merchant ones in several areas of v4. If you are a service provider, or a merchant who is also a service provider to your own customers, check which set applies to each part of your environment.
Companies that process on behalf of clients while also taking payments directly are frequently assessed against both, and discovering that during fieldwork is expensive.
Where Teams Are Still Behind
Teams are still behind in a consistent set of places, and the pattern is less about difficulty than about who owned the work.
- Script inventory on payment pages. Not started, or started and not maintained. The page changes whenever marketing adds a tag, so a one-off inventory decays within weeks.
- Targeted risk analyses that exist as documents. The frequencies are defensible; the written analyses were never produced.
- MFA coverage on administrative paths. Strong at the perimeter, patchy on jump hosts, database tooling and vendor access.
- Roles and responsibilities per requirement. Usually a single RACI covering the programme, not ownership mapped to each requirement.
- Evidence continuity across the period. Controls operating now, with nothing showing they operated through the whole window.
- Scope statements written against v3.2.1. Still describing an environment that has since changed, which undermines everything built on top of it.
None of these are discovered late because they are hard. They are discovered late because each one belongs to someone who was not in the room when the v4 plan was written.
Preparing for an Assessment Against the Full Set
Preparing for an assessment against the full set starts with a re-read of the requirements rather than a re-read of your last report. Work through the twelve PCI DSS requirements against your current environment, and mark every item where your evidence is a point-in-time artefact instead of a record of continuous operation.
Then do 3 things in order. Confirm your scope — a scope reduction exercise done before fieldwork is worth more than any amount of remediation inside an oversized environment. Decide, per requirement, whether you are using the defined or the customised approach, and raise any customised approach with your QSA early rather than presenting it as a finished argument. Finally, check that the recurring activities with external dependencies are actually scheduled, including penetration testing requirements and ASV scanning, because those have lead times you cannot compress.
Give yourself a full period of evidence before the assessment window closes. A control that starts operating a month before fieldwork is a control with a month of evidence.
PCI DSS v4 Transition Questions Teams Ask
These are the PCI DSS v4 transition questions teams ask most often once they realise the formerly future-dated requirements are now in scope for assessment.
No. The requirements that v4.0 introduced as future-dated were best practice until 31 March 2025 and mandatory from that date. An assessment now covers the complete v4 set, and there is no position available in which a requirement is acknowledged but not assessed because it has not taken effect yet. If your last Report on Compliance recorded items as not yet applicable, those items are in scope this time.
Not for the reason you might think. PCI DSS 4.0.1 is a limited revision that clarified and corrected rather than adding requirements, so a gap analysis mapped against v4.0 remains structurally valid. What is worth redoing is the evidence review, because the end of the transition period changed what has to be evidenced, and because your environment has changed since the analysis was written. Update the version your documents cite while you are there.
Usually not, and certainly not as a default. The customised approach in PCI DSS requires a targeted risk analysis, documented controls that demonstrably meet the requirement's objective, and a QSA willing to validate that argument — which is more work than implementing the defined approach for most requirements. It is worth considering where you already operate a mature control that achieves the objective by a different mechanism. Raise it with your assessor before you invest in the documentation.
Payment page script integrity management. Knowing which scripts execute on a payment page, authorising each one, and detecting unauthorised change was not something most merchants did before v4, and the inventory is harder to build than it sounds because scripts arrive through tag managers and marketing tooling rather than through engineering. It also bears on which self-assessment questionnaire you are eligible for, so it can change the shape of the assessment and not just its findings.
Far enough back to generate a period of evidence rather than a snapshot. Work backwards from the attestation date: the quarterly scanning obligation alone means a first assessment needs several quarters behind it, because four passing quarters cannot be produced in one. The constraint is rarely implementation. It is that several v4 expectations are about an activity operating continuously with a named owner, and you cannot retrofit a history of operation. Scanning and testing engagements with external parties add their own lead times on top.
Keep the formerly future-dated requirements evidenced between assessments
Book a demo and we'll show how Konfirmity assigns each v4 requirement an owner, holds the targeted risk analyses alongside the controls, and keeps a continuous evidence record rather than a pre-fieldwork scramble.
Book a demo
Treat v4 as the Baseline Rather Than a Project
The useful mental shift is to stop treating v4 as a migration. There is no older version to fall back to, no requirement with a later date attached, and no partial credit for having planned the work. v4.0.1 is simply the standard, and the question at your next assessment is whether you operate it.
That reframing changes where effort goes. A migration project optimises for a completion date; an operated standard optimises for ownership, recurrence and a continuous evidence trail. The teams that are behind are almost always the ones that closed a project and expected the controls to keep running without anyone named against them.
Start by reconciling your control inventory against the full v4 set and marking the items you could not evidence across a whole period today. Work through a PCI DSS compliance checklist with that lens, assign an owner to each requirement, and put the recurring activities on a calendar before you book fieldwork.
