Version guide
PCI DSS v4.0.1: What Changed From v4.0, and the 51 Requirements in Force Since 31 March 2025
PCI DSS v4.0.1 is the only version the PCI Security Standards Council now supports. It was published on 11 June 2024 as a limited revision, with no added or deleted requirements. It did reword three controls an assessor tests closely: patching, multi-factor authentication and payment page scripts. Separately, the requirements v4.0 future-dated have been mandatory since 31 March 2025.
Who is writing this
SecureRoot Risk Advisory LLP is not a Qualified Security Assessor and signs neither the Report on Compliance nor the Attestation of Compliance. We run gap assessments against the current text and help teams close what they find. Every date and requirement number below comes from the Council’s own documents, which do not endorse us.
Timeline
PCI DSS versions and dates, as the Council states them
| Date | What happened | Council source |
|---|---|---|
| March 2022 | PCI DSS v4.0 published, with 51 new requirements future-dated to 31 March 2025 | PCI DSS v4.0.1, Table 6; SSC blog, 26 March 2025 |
| 31 March 2024 | PCI DSS v3.2.1 retired | PCI DSS v4.0.1, Table 6; SSC blog, 31 January 2024 |
| 11 June 2024 | PCI DSS v4.0.1 published as a limited revision, with no added or deleted requirements | SSC blog, 11 June 2024 |
| 31 December 2024 | PCI DSS v4.0 retired; v4.0.1 becomes the only active version | SSC blog, 11 June 2024; PCI DSS v4.0.1, Table 6 |
| February 2025 | FAQ 1588 explains the new SAQ A eligibility criterion for scripts | SSC FAQ 1588 |
| 31 March 2025 | The future-dated requirements become mandatory and are assessed in full | SSC blogs, 11 June 2024 and 26 March 2025 |
Table 6 of the standard gives the retirement date of v4.0.1 itself as to be determined.
Two layers
What is the difference between PCI DSS 4.0 and 4.0.1?
The two versions are easy to run together. Keeping the two layers apart tells you what your next assessment will actually test.
From v3.2.1 to v4.0: the large change
The Council counts 64 new requirements in v4.x. Of these, 51 were future-dated: best practice until 31 March 2025, then mandatory. The other 13 were, in the Council’s January 2024 words, effective immediately. Version 4.0 also brought the customised approach, which lets a risk-mature entity meet a requirement’s objective in its own way. Universal MFA into the cardholder data environment, payment page script controls and targeted risk analyses all belong to this layer.
From v4.0 to v4.0.1: clarification only
The Council’s Summary of Changes sorts every edit into three types. It states there were no changes categorised as “Evolving Requirement”, the type for new, modified or removed requirements. Everything else is “Clarification or Guidance” or “Structure or format”.
So if a page tells you v4.0.1 introduced universal MFA or script controls, it has merged the layers. Those arrived with v4.0. Version 4.0.1 changed how some of them read.
What changed
Which v4.0.1 changes alter what an assessor tests?
Most of the revision is wording. Three changes are not, because they move the evidence you are asked for.
6.3.3: the one-month window is for critical vulnerabilities only
Version 4.0 had widened the one-month patch window to “critical or high-security” patches. Version 4.0.1 reverts to the v3.2.1 wording. Patches for critical vulnerabilities, ranked under 6.3.1, are installed within one month of release. All other applicable patches are installed in a time frame set by the entity’s own assessment of the risk.
A policy rewritten for v4.0 may now promise more than the standard asks. The Good Practice recommends a targeted risk analysis to set the second timeline.
8.4.2: MFA into the CDE, with one exception
8.4.2 is clarified to cover all non-console access into the cardholder data environment. A new Applicability Note says it does not apply to non-administrative user accounts that are only authenticated with phishing-resistant factors.
Appendix G now defines the term, and the questions below cover what qualifies and what an assessor checks.
6.4.3 and 11.6.1: who owns the scripts on an embedded payment page
Both requirements gained the same three Applicability Notes. They apply to scripts on your own webpage, including a page that hosts a provider’s embedded payment form, such as an iframe. They do not apply to you for scripts inside that embedded form. Those are the provider’s to manage.
The Good Practice adds that you should expect the provider to give you evidence it meets both.
v4.0 to v4.0.1
The v4.0.1 changes, requirement by requirement
| Requirement | What v4.0.1 changed | What it means at assessment |
|---|---|---|
| Scope (section 4) | New sub-section for cardholder or sensitive authentication data accidentally received through an unintended channel, moved from the 4.2.1 note. | Card numbers that arrive unasked, by email or chat, have their own guidance. |
| 3.3.1 to 3.3.3 | Issuers may store sensitive authentication data only on "a legitimate and documented business need". "Retained" becomes "stored". | Issuers and issuing processors must write the business need down. |
| 3.5.1.1 | Customized Approach Objective added. Notes that it replaces the one-way hash bullet in 3.5.1 once effective, and covers systems generating keyed hashes of a PAN. | Hashed PANs must be keyed hashes with key management. |
| 6.3.3 | Reverts to v3.2.1 wording: the one-month window applies to patches for critical vulnerabilities. "High-security patches" removed; other patches follow the entity's risk assessment. | The one-month promise covers critical vulnerabilities only. The timeline for the rest must be written and justified. |
| 6.4.3 | Script inventory bullet clarified. Three Applicability Notes on your own page versus a provider's embedded payment page. Guidance where pre-authorising a script is impractical. | Scripts on your page are yours; scripts inside the provider's iframe are the provider's. |
| 8.4.1 | MFA for non-console administrative access to in-scope systems outside the CDE moves from an Applicability Note to Good Practice. | Recommended there, not tested as a requirement. |
| 8.4.2 | Clarified as all non-console access into the CDE. New note: it does not apply to non-administrative accounts only authenticated with phishing-resistant factors. | Accounts relying on the exception must have no weaker fallback. |
| 8.4.3 | "Remote access" replaces "remote network access". Third parties added to the testing procedure. | Vendor and third-party remote access is tested explicitly. |
| 11.3.1, 11.3.1.1, 11.3.1.3 | 11.3.1 and 11.3.1.3 cover vulnerabilities "either critical or high-risk"; 11.3.1.1 covers all others. | Rescan obligations follow your own risk rankings from 6.3.1. |
| 11.6.1 | Applies to "security-impacting HTTP headers and the script contents of payment pages". "Once every seven days" becomes "weekly". Same three embedded-page notes as 6.4.3. | Tamper detection watches headers as well as scripts, on the pages you own. |
| 12.3.1 | Applies only to requirements that specify a targeted risk analysis. Points to the Council's guidance and sample templates. | One analysis per requirement that asks for one, not one for everything. |
| 12.8.2, 12.9.1, 12.9.2 | Agreement and acknowledgement distinguished. A provider's written acknowledgement confirms it is responsible; evidence it meets a requirement is not a written agreement. | Hold signed acknowledgements, not only compliance certificates. |
| Appendices | Customized approach must be "documented by a QSA or ISA". Sample templates move to the Council's website. Glossary adds "Legal Exception", "Phishing Resistant Authentication" and "Visitor". | Only a QSA or ISA records a customised approach in a ROC. |
Paraphrased from the Council's Summary of Changes from PCI DSS Version 4.0 to 4.0.1 (r1, August 2024), which also lists editorial edits not shown here.
How our gap assessment checks this
Our gap assessment maps every row above to your own evidence and ends in the PCI DSS Gap Assessment Report. It prepares you for the assessment; it does not replace it. The full programme is on our PCI DSS compliance services page.
In force
Which requirements became mandatory on 31 March 2025?
The 51 future-dated requirements of v4.x. Each carried a note that it was a best practice until 31 March 2025, then required. They are now assessed like any other requirement. By theme, with examples confirmed in the standard’s own text:
Payment page scripts
6.4.3, authorisation, integrity and a justified inventory for every payment page script; 11.6.1, change and tamper detection on payment pages.
Authentication
8.4.2, multi-factor authentication for all non-console access into the cardholder data environment, not only administrators.
Risk analysis
12.3.1, a documented targeted risk analysis for each requirement that specifies one.
Logging
10.4.1.1, automated mechanisms to perform audit log reviews.
Stored card data
3.5.1.1, keyed cryptographic hashes of the entire PAN, with key management, wherever hashing makes a PAN unreadable.
Phishing
5.4.1, processes and automated mechanisms to detect and protect personnel against phishing attacks.
This page does not print all 51. The authoritative list is the Council’s Summary of Changes from PCI DSS v3.2.1 to v4.0, in its document library, and each future-dated requirement carries its own note in the standard. Work from those, not from a copied list. The order to work through all twelve requirements is in our PCI DSS compliance checklist.
The deadline
Does PCI DSS v4.0.1 change the 31 March 2025 deadline?
No. When it published v4.0.1, the Council said the limited revision “does not impact the effective date of these new requirements”. Anything that still calls them upcoming is out of date, including a gap report or remediation plan written a year or two ago.
Embedded payment pages
What does v4.0.1 mean if your checkout uses a gateway’s hosted page or iframe?
It is a common question for Indian D2C and SaaS merchants on a payment gateway. Three Council sources answer it, and each speaks to a different document.
- The standard. 6.4.3 and 11.6.1 apply to scripts on your page that hosts the embedded form, and to scripts loaded from third and fourth parties. They do not apply to you for scripts inside the provider’s form.
- SAQ A. In March 2025 the Council said it had removed 6.4.3, 11.6.1 and 12.3.1 from SAQ A and added an eligibility criterion instead. It added that these requirements “are still in the standard”.
- FAQ 1588, February 2025. The criterion applies only to merchants whose page includes a provider’s embedded payment page or form. It does not apply to redirects or to fully outsourced payments. You meet it either with techniques such as those in 6.4.3 and 11.6.1, deployed by you or a third party, or with confirmation from your PCI DSS compliant provider that its solution protects the page when implemented as instructed.
So a redirect merchant, an iframe merchant and a merchant on a Report on Compliance each get a different answer. Which questionnaire your payment flow lands on is set out in PCI DSS scope reduction and SAQ types. If you embed a gateway’s form, ask the gateway in writing for its 6.4.3 and 11.6.1 confirmation now.
India
PCI DSS 4.0.1 in India: tokenisation, and the version on your form
Under the RBI’s card-on-file tokenisation framework, from 1 October 2022 no entity in the card transaction chain other than the card issuer and the card network may store actual card data. That removes most stored-card scope for Indian merchants and payment aggregators. It does not remove PCI DSS. Systems that receive, process or transmit card data stay in scope, and the v4.0.1 controls apply to them.
Check the version printed on every questionnaire, ROC template or attestation you are handed. After 31 December 2024 the Council supports only v4.0.1, and the standard sends questions about earlier versions to those who run compliance programmes, typically your acquiring bank or a payment brand. A form headed v4.0 or v3.2.1 is stale.
Payment aggregators carry RBI obligations on top of the standard. Those, and how the two fit together, are covered in PCI DSS for payment aggregators and fintechs.
Re-check
What should you re-check if your last assessment used v4.0 or v3.2.1?
Not the whole standard. These seven points are where evidence built for an older version can read differently against v4.0.1.
- Patching (6.3.3): one month for critical vulnerabilities, and a written, risk-based timeline for the rest.
- MFA (8.4.2): every non-console route into the CDE covered, and a list of any non-administrative accounts relying on the phishing-resistant exception.
- Payment page scripts (6.4.3, 11.6.1): a justified script inventory, a weekly header and script check, and your provider's evidence if its form is embedded.
- Targeted risk analyses (12.3.1): one for each requirement that specifies one.
- Service providers (12.8.2, 12.9): written acknowledgements that each provider is responsible, not only proof it is compliant.
- Hashed card numbers (3.5.1.1): keyed hashes, with key management under 3.6 and 3.7.
- Internal scans (11.3.1): critical and high-risk vulnerabilities, by your own 6.3.1 rankings, resolved and rescanned.
The tests Requirement 11 asks for, including segmentation testing, are covered in PCI DSS penetration testing. What a re-assessment involves, and who bills which part, is in what a PCI DSS validation costs.
Questions
What teams ask about PCI DSS v4.0.1
Do we need a fresh assessment because of v4.0.1?
No. Version 4.0.1 added and deleted no requirements, so it does not trigger a new assessment by itself. What it changes is the text your next assessment is measured against. The Council retired v4.0 on 31 December 2024, so a questionnaire or Report on Compliance completed after that date is against v4.0.1. The practical effect sits in the wording. A patch policy written to the v4.0 "critical or high-security" language may promise more than 6.3.3 now asks. A script inventory may lack the written justification 6.4.3 now names. Service provider files may hold evidence of compliance but no written acknowledgement of responsibility. None of these is a new control. Each is a place where evidence prepared for v4.0 reads differently against v4.0.1. Your acquirer or card brand decides when you validate. The version you validate against is not a choice you get to make.
Is there a v4.0.1 ROC template, AOC and set of SAQs?
The Council planned all three, and the questionnaires are confirmed. When it published v4.0.1 on 11 June 2024, it said the v4.0.1 Report on Compliance template, Attestations of Compliance and SAQs were targeted for the third quarter of that year, followed by updated supporting documents. Its FAQ 1588 now refers to the PCI DSS v4.0.1 Self-Assessment Questionnaire A, revision 1. Download whatever you file from the Council's document library on the day you start, not from a shared drive or an old email thread. A form still headed v4.0 or v3.2.1 means the template, or the advice that came with it, predates the current standard. If you are unsure which questionnaire applies, the Council's answer is to ask the entity you submit it to, typically your acquiring bank or a payment brand. SecureRoot does not complete, sign or submit these documents for you; your officer or your QSA does.
Can a merchant on a Report on Compliance use the SAQ A shortcut for scripts?
Not by default. The SAQ A change removed 6.4.3, 11.6.1 and 12.3.1 from that questionnaire and replaced them with an eligibility criterion, and the Council said plainly that the requirements are still in the standard. Its FAQ 1331, dated August 2026, says SAQ eligibility criteria should not be used as a guide to which requirements apply in a merchant's Report on Compliance. The exception is where the compliance-accepting entity, such as the acquirer or a payment brand, has explicitly reviewed and agreed to that use. So a larger merchant assessed by a QSA or ISA should expect 6.4.3 and 11.6.1 to be tested on any page that hosts a provider's embedded payment form, unless the acquirer or payment brand has explicitly agreed to that use. The QSA decides how the evidence is assessed. We help you build the script inventory and tamper detection, and assemble the evidence the QSA will ask for.
Does the phishing-resistant exception mean we can drop MFA?
No. It means some accounts meet the objective a different way. The Applicability Note added to 8.4.2 says the requirement for multi-factor authentication on all non-console access into the cardholder data environment does not apply to non-administrative user accounts that are only authenticated with phishing-resistant authentication factors. Administrative non-console access into the CDE still needs multi-factor authentication under 8.4.1. An account that can still fall back to a password or a one-time code does not qualify. Appendix G of v4.0.1 now defines the term. It says systems relying solely on passwords, one-time passwords, SMS or magic links are not phishing resistant, and it names FIDO2 as an example of one that is. Before relying on the note, list the accounts concerned, show how each one authenticates, and show that no weaker path remains open. Expect an assessor to test exactly that, and not to accept a policy statement in its place.
Who can use the customised approach, and can SecureRoot document it?
The standard describes the customised approach as intended for risk-mature entities with a mature risk-management approach. Entities that complete a self-assessment questionnaire are not eligible, although they may choose a QSA or ISA assessment documented in a ROC template instead. Version 4.0.1 also tightened the wording on who records it: use of the customised approach "must be documented by a QSA or ISA". The sample templates moved off the standard and onto the Council's website. SecureRoot is neither a QSA nor an Internal Security Assessor, so we do not document a customised approach for any assessment. What we do is the work in front of it: find where the defined approach does not fit your design, draft the controls matrix and targeted risk analysis the approach asks for, and gather the evidence that the objective is met. Payment brands and acquirers may regulate its use, so ask yours first.
Primary Sources
Where the Figures on This Page Come From
Every deadline, threshold and control count above is taken from the instrument itself. These are links to the primary text, not to a summary of it.
- Just Published: PCI DSS v4.0.1 (11 June 2024)
PCI Security Standards Council · Link checked 2026-11-10
- PCI DSS v4.0.1, the Summary of Changes from v4.0 to v4.0.1 and the Summary of Changes from v3.2.1 to v4.0 (document library)
PCI Security Standards Council · Link checked 2026-11-10
- Coffee with the Council: guidance for PCI DSS e-commerce requirements effective after 31 March 2025 (26 March 2025)
PCI Security Standards Council · Link checked 2026-11-10
- PCI DSS v3.2.1 is Retiring on 31 March 2024 (31 January 2024)
PCI Security Standards Council · Link checked 2026-11-10
- FAQ 1588: How does an e-commerce merchant meet the SAQ A eligibility criteria for scripts?
PCI Security Standards Council · Link checked 2026-11-10
- FAQ 1331: Can SAQ eligibility criteria be used as a guide for Report on Compliance assessments?
PCI Security Standards Council · Link checked 2026-11-10
Check your controls against the v4.0.1 text, not the version your last assessment used
Bring your payment flow, your last questionnaire or Report on Compliance, and the date your acquirer is waiting on. You get a written scope and a gap assessment against v4.0.1, row by row. SecureRoot is not a QSA and signs neither the Report on Compliance nor the Attestation of Compliance; your officer or your QSA does.