Which PCI SSC document says what, and which PCI DSS version it is written against

PCI DSS v4.0.1 is the only current version of the standard, and has been since 31 December 2024. Anything written against v4.0 before that date, and anything still written against v3.2.1, carries requirement numbers or effective dates that no longer hold.

The standard settles this itself, in a table on page 35 that almost nobody reaches.

Two things follow from the last column. v3.2.1 was retired on 31 March 2024, so a "v3.2.1 to v4.0 migration" is not a project anyone still has. And v4.0.1 has no retirement date because none has been set — the table carries the footnote "Subject to change upon release of a new version of PCI DSS."

The v4.0 requirement counts, and the date that made them all bite

The Summary of Changes from PCI DSS Version 3.2.1 to 4.0 (r1, May 2022) ends with a list of every new requirement, who it applies to, and when it took effect. Its totals row is the part worth memorising:

• 64 new requirements in v4.0
• 53 apply to all entities; 11 to service providers only
• 13 were effective immediately for all v4.0 assessments
• 51 were best practices until 31 March 2025, after which they became effective

The document allows no third option: the new requirements are either "Effective immediately for all PCI DSS v4.0 assessments" or "Best practices until 31 March 2025, after which they become effective." There is no later date anywhere in v4.x.

So as of 31 March 2025 all 64 are simply requirements. An assessment scoped today treats 6.4.3, 11.3.1.1, 11.3.1.2, 11.4.7, 11.6.1 and the other forty-six exactly as it treats requirements that have been in the standard for a decade. A page still calling any of them a "future-dated requirement" or a "best practice" was written before March 2025 and has not been touched since.

The same date removed requirements

This is the half that gets missed. 31 March 2025 did not only switch requirements on — it switched some off. The applicability notes in v4.0.1 say so, requirement by requirement:

• 6.4.1 — "This requirement will be superseded by Requirement 6.4.2 after 31 March 2025 when Requirement 6.4.2 becomes effective."
• 10.7.1 — "This requirement will be superseded by Requirement 10.7.2 as of 31 March 2025."
• 3.5.1.1 — "will replace the bullet in Requirement 3.5.1 for one-way hashes once its effective date is reached."
• 8.3.10 — "Until this requirement is effective on 31 March 2025, service providers may meet either Requirement 8.3.10 or 8.3.10.1."

A guide written against v4.0 in 2023 can therefore be wrong in both directions at once: silent on requirements that now apply, and prescriptive about requirements that have since been superseded.

Which document answers which question

The standard routes you to the first few itself, in its assessment-process section: "For instructions about completing reports on compliance (ROC), refer to the PCI DSS Report on Compliance (ROC) Template. For instructions about completing self-assessment questionnaires (SAQ), refer to the PCI DSS SAQ Instructions and Guidelines."

Two traps in the version numbers

The penetration testing supplement still uses v3.x numbering

PCI SSC's Information Supplement: Penetration Testing Guidance is at v1.1, dated September 2017 — when PCI DSS v3.2 was the current version — and it is still the Council's only penetration testing supplement. It cites v3.x requirement numbers throughout: "The scope of a penetration test, as defined in PCI DSS Requirement 11.3, includes the entire CDE perimeter", and "PCI DSS Requirement 11.3.4 requires penetration testing to validate that segmentation controls and methods are operational".

Under v4.0.1 those numbers point somewhere else. The Summary of Changes maps v3.2.1's Requirement 11.3 onto v4.0's 11.4.1, and 11.3.3 onto 11.4.4; v3.2.1's 11.2.3 was split into 11.3.1.3 for internal scans and 11.3.2.1 for external scans. In v4.0.1, 11.3 is vulnerability scanning and 11.4 is penetration testing — separate requirement families, separate frequencies, and in one sub-requirement a different party permitted to do the work.

The supplement is still worth reading for method. It is not usable for requirement numbers, and lifting "Requirement 11.3" out of it into a current scope document is the commonest sourcing error on this subject. What Requirement 11.4 demands covers the renumbering sub-requirement by sub-requirement.

Programme documents do not share the standard's version number

The assessor and scanning programme documents are versioned on their own schedules, and the numbers collide confusingly with the standard's:

• Qualification Requirements for Approved Scanning Vendors v3.0 is dated February 2017 — unrelated to PCI DSS 3.0, which was published in November 2013.
• Qualification Requirements for Qualified Security Assessors v4.0 is dated March 2021 — a year before PCI DSS v4.0.
• The QSA Program Guide v3.0 is also March 2021.

"QSA Qualification Requirements v4.0" does not mean "the QSA rules for PCI DSS v4.0". Read the cover date, not the number.

The revision is part of the citation

Two of these documents were corrected after publication, and naming the version without the revision is not precise enough to be checkable.

The SAQ Instructions and Guidelines went to v4.0.1 r1 in April 2025. Its own document-changes table records two substantive edits: it "Corrected table (Common e-commerce methods and applicable SAQs) to accurately reflect the number of applicable PCI DSS requirements", and it "Removed Requirements 6.4.3 and 11.6.1 from section 'Importance of new requirements added to SAQ A for PCI DSS v4.x.'" The current text of that section names only Requirements 11.3.2 and 11.3.2.1. Anyone quoting the October 2024 edition on the SAQ requirement counts is quoting a document that has since been corrected. Which SAQ applies to you works from the r1 table.

The Summary of Changes from v3.2.1 to 4.0 is at r1, May 2022, an "Errata update to correct the change description for PCI DSS v4.0 Requirement 8.3.9."

What none of these documents tells you

Whether you have to validate at all, and how. The standard is explicit that this is not its call: "Whether any entity is required to comply with or validate their compliance to PCI DSS is at the discretion of those organizations that manage compliance programs (such as payment brands and acquirers)." The versions table carries the same referral for questions about using an earlier version.

Your merchant level, your reporting deadline and which validation route you take come from your acquirer and the payment brands. PCI SSC writes the standard and publishes the forms; it does not run your compliance programme, and it issues no certificate at the end of one. What "PCI DSS certification" actually means takes that apart.

How to cite it so a reader can check you

Version, section, date. "PCI DSS v4.0.1 (June 2024), Requirement 11.4.6" can be verified in under a minute; "PCI DSS requires quarterly testing" cannot. And "Req 11.3 penetration testing" tells anyone who knows the standard that the writer is working from a source retired on 31 March 2024.

Every document named above is free from the PCI SSC Document Library. The version and date are on the cover page; the revision is in the document-changes table immediately after it. Every version, date and quotation above was checked against that published text on 20 August 2026.