Which PCI DSS version applies now?
PCI DSS v4.0.1 is the version to work to. PCI SSC published it on June 11, 2024 and states that there are no additional or deleted requirements in it. The changes correct formatting and typographical errors and clarify the focus and intent of some requirements and guidance.
PCI DSS v4.0 was retired on December 31, 2024, which left v4.0.1 as the only active version. The Self-Assessment Questionnaires followed the same path: PCI SSC published the v4.0.1 SAQs on October 15, 2024, and the v4.0 SAQs stayed active only until v4.0 was retired.
If a policy, contract or vendor document still cites an earlier version, update the reference. The requirements themselves carry over from v4.0, but the wording of some requirements and applicability notes changed.
What PCI DSS v4.0 introduced
The larger changes arrived with v4.0, not v4.0.1. According to PCI SSC, v4.0 added 64 new requirements, and 51 of them were future-dated: treated as best practices until March 31, 2025. Since that date they have been required and must be fully considered in a PCI DSS assessment.
Future-dated requirements aren't a separate category any more. If an earlier assessment treated them as best practices, expect the next one to test them like any other requirement.
Examples of requirements that took effect March 31, 2025
Several of the formerly future-dated requirements change day-to-day work:
- 6.4.3: for every payment page script loaded and executed in the consumer's browser, a method confirms it's authorized, a method assures its integrity, and an inventory lists it with a written justification.
- 11.6.1: a change- and tamper-detection mechanism alerts personnel to unauthorized changes to payment pages as received by the consumer's browser, running at least weekly or at a frequency set by a targeted risk analysis.
- 12.3.1: each requirement that lets you choose how often to do something is supported by a documented targeted risk analysis, reviewed at least once every 12 months.
- 11.3.1.2: internal vulnerability scans use authenticated scanning, and systems that can't accept credentials are documented.
- 11.3.1.1: vulnerabilities not ranked high-risk or critical are addressed on a timeline set by a targeted risk analysis.
Scope confirmation under requirement 12.5.2
PCI DSS v4.x also makes scope an explicit, recurring task. Requirement 12.5.2 asks the entity to document and confirm its PCI DSS scope at least once every 12 months and upon significant change to the in-scope environment. PCI SSC describes this annual scope confirmation as one of the new requirements in PCI DSS v4.x.
The confirmation covers data flows for each payment stage and acceptance channel, every location where account data is stored, processed or transmitted, systems in or connected to the cardholder data environment, segmentation controls and third-party connections. It's the entity's own exercise, separate from the scoping an assessor does during an assessment.
The SAQ A change
For merchants that validate with SAQ A, PCI SSC removed requirements 6.4.3, 11.6.1 and 12.3.1 from that questionnaire, effective March 31, 2025, and added an eligibility criterion: the merchant confirms its site isn't susceptible to attacks from scripts that could affect its e-commerce systems. PCI SSC notes that the change doesn't remove or diminish the underlying PCI DSS requirements.
Defined and customized approaches
PCI DSS v4.x offers two ways to meet a requirement. Under the defined approach, you implement the requirement as written and are tested against its stated testing procedures. The customized approach, introduced in v4.0, lets an entity meet a requirement's stated objective with a control it designs itself.
PCI SSC describes the customized approach as suited to organizations with the risk maturity, commitment and resources to design, implement and maintain such controls. For each customized control, the entity documents how it meets the objective, performs a targeted risk analysis showing it gives at least the protection of the defined requirement, tests it, and monitors its effectiveness.
The assessor then derives testing procedures for the control and records the results in the Report on Compliance. PCI SSC treats it as a conflict of interest for an assessor who helped design or implement a customized control to assess it, which is another reason to keep design help and assessment separate.
What PCI DSS 4.0.1 clarified
PCI SSC's announcement lists the main clarifications by requirement, and the Summary of Changes from v4.0 to v4.0.1, in the PCI SSC document library, lists every change. None adds a requirement, but several change how an existing one is applied.
The 11.6.1 item comes from the v4.0.1 requirement text, not the announcement. PCI SSC's March 2025 guidance on payment page security uses the same term, security-impacting HTTP headers.
- Requirement 3: clarified applicability notes for issuers and companies that support issuing services, and clarified applicability for keyed cryptographic hashes used to render primary account numbers unreadable.
- Requirement 6: reverted to the PCI DSS v3.2.1 language, so installing patches or updates within 30 days applies only to critical vulnerabilities, and added applicability notes on managing payment page scripts.
- Requirement 8: added a note that multi-factor authentication for non-administrative access into the cardholder data environment doesn't apply to user accounts authenticated only with phishing-resistant factors.
- Requirement 12: updated applicability notes on relationships between customers and third-party service providers.
- Requirement 11.6.1: the change- and tamper-detection mechanism focuses on security-impacting HTTP headers and the script contents of payment pages, as received by the consumer's browser.
Is a new PCI DSS version coming?
PCI SSC ran a request for comments on PCI DSS v4.0.1 from June 3 to July 20, 2026. Eligible stakeholders reviewed it through the PCI SSC portal under a nondisclosure agreement, and PCI SSC described the purpose as gathering feedback to help shape the future of the standard.
As of September 27, 2026, PCI SSC hasn't announced a successor version or a release date, and its RFC post calls v4.0.1 the currently published version. Plan to v4.0.1, and treat any claim about the next version's content or timing as unconfirmed until PCI SSC publishes it.
Who requires PCI DSS compliance
PCI DSS applies to entities that store, process or transmit cardholder data or sensitive authentication data, or that could affect the security of the cardholder data environment. PCI SSC lists merchants, processors, acquirers, issuers and service providers among them.
PCI SSC writes the standard but doesn't decide who must comply. It says that whether an entity must comply with, or validate compliance to, a PCI SSC standard is up to the organizations that manage compliance programs, such as a payment brand or an acquirer.
In practice, ask the entity you report compliance to, for example your acquirer, which validation you owe and when, whether a Report on Compliance (ROC) or a Self-Assessment Questionnaire (SAQ). PCI SSC encourages anyone completing an SAQ to confirm eligibility first with the entity that will receive it.
Extra requirements for service providers
Service providers carry several requirements that merchants don't, and some run on shorter cycles. Requirement 12.5.2.1 asks a service provider to document and confirm its PCI DSS scope at least once every six months and upon significant change; it was one of the future-dated requirements. If segmentation isolates the cardholder data environment, requirement 11.4.6 calls for penetration testing of segmentation controls at least once every six months and after changes to them.
Requirement 12.4.2 adds reviews, at least once every three months, confirming that personnel perform their tasks in line with security policies and operational procedures, carried out by people other than those responsible for the task. If you provide services to other entities that handle card data, build these cycles into your calendar alongside the merchant requirements.
Readiness steps for PCI DSS v4.0.1
A practical v4.0.1 readiness plan starts with the requirements that changed how work gets done, then gathers evidence for everything else. Which steps apply depends on your scope and on the validation you owe, since a Self-Assessment Questionnaire covers only the requirements it lists. Start with scope, because it decides the rest:
- Confirm scope under 12.5.2: data flows, account data locations, connected systems, segmentation and third-party connections.
- List every requirement where you choose the frequency, and document a targeted risk analysis for each under 12.3.1.
- Inventory payment page scripts, with authorization, integrity checks and a written justification for each (6.4.3).
- Deploy change- and tamper-detection for payment pages and set its frequency (11.6.1).
- Run internal scans, including authenticated scans, and external scans by an Approved Scanning Vendor at least once every three months, plus scans after significant changes (11.3).
- Schedule internal and external penetration tests at least once every 12 months and after significant changes, plus segmentation testing if you use segmentation to isolate the cardholder data environment (11.4).
- Confirm with your acquirer which validation you owe, and use the v4.0.1 version of any SAQ.
- Keep evidence as you go: approvals, reviews, scan reports, test reports and retest results.