PCI DSS 4.0.1 Is Business as Usual. What the Next Version Changes

The direct answer: PCI DSS 5.0 has no announced release date. As of late August 2026, the PCI Security Standards Council is in active development: a second request for comments cycle for the next major version completed in December 2025, and a further RFC on the evolution of v4.0.1 ran June 3 to July 20, 2026, focused on future technology and AI. In the meantime there is no transition period to plan around and no future-dated grace to lean on. Version 4.0 was retired on December 31, 2024, all 51 future-dated requirements became mandatory on March 31, 2025, and every assessment conducted in 2026 runs against the complete v4.0.1 standard. The practical agenda for a mid-market merchant or service provider is therefore twofold: operate the newly mandatory controls as routine, especially 8.4.2, 6.4.3, and 11.6.1, and watch the v5.0 signals without betting the program on any of them.

Status verified August 27, 2026. This page is updated when the regulatory status changes.

Most PCI content on the internet stops at the March 2025 deadline, written as countdown material for a date that has now passed. This page starts where that content ends. If you need the foundations first, our plain-English guide to PCI DSS compliance covers who the standard applies to and how validation works, and our breakdown of the v4 requirements, scoping, and the cardholder data environment covers the structure of the standard itself.

There is no partial compliance left in v4.0.1

Version 4 of PCI DSS shipped with a long tail: 51 requirements marked as best practice until March 31, 2025, after which they became mandatory. That date has come and gone. The Council published v4.0.1 as a limited revision to clarify the standard, v4.0 itself was retired at the end of 2024, and the future-dated column of every readiness spreadsheet is now just the standard.

What that means for a 2026 assessment is concrete. Requirement 8.4.2 requires multi-factor authentication for all access into the cardholder data environment, not only remote access and not only administrators. Requirement 12.10.7 requires documented incident response procedures for when cardholder data turns up where it should not be. The expanded e-commerce and anti-phishing controls apply in full. And the two requirements that caught the most merchants unprepared, 6.4.3 and 11.6.1, are tested as operating controls with evidence, not as plans.

The merchants hit hardest by that last pair are not the large ones. SAQ-eligible mid-market merchants, including SaaS companies with embedded payments and multi-location businesses taking cards online, inherited a set of payment-page obligations that most had never operated before. Which is worth unpacking, because these two requirements generate more confusion than the rest of the standard combined.

Requirements 6.4.3 and 11.6.1, explained for a SaaS checkout page

Both requirements exist for the same reason: web skimming. Attackers compromise a script that loads on a payment page, often a third-party tag rather than anything the merchant wrote, and siphon card data directly from the consumer's browser. The server never sees the theft, so server-side controls never catch it. The standard's answer is to make merchants govern what runs on the payment page and detect when it changes.

Question	Requirement 6.4.3	Requirement 11.6.1
What it requires	An inventory of every script on payment pages, a written justification for each, and a method to authorize scripts and assure their integrity	A change- and tamper-detection mechanism that alerts on unauthorized modification to payment-page HTTP headers and script contents as received by the browser
The question it answers	What is allowed to run on this page, and why?	Did anything on this page change without approval?
Cadence	Maintained continuously, reviewed as scripts change	At least weekly, or per a targeted risk analysis
Typical failure mode	Nobody can list the marketing and analytics tags loading beside the card field	Detection tooling exists but nobody owns the alerts

The scoping question every SaaS team asks next: does this apply to us if we use a hosted payment provider? It depends on how the integration is built. A full redirect to the provider's hosted page pushes most of the burden to the provider. An embedded iframe still leaves the merchant with obligations for the page that hosts the iframe, since a compromised parent page can overlay or manipulate what the consumer sees. A direct API integration where card data touches your form puts both requirements squarely on you. The honest starting point is a script inventory of your checkout flow as the browser actually loads it. Most teams that run one for the first time find scripts nobody can justify, and removing them is both a compliance win and a genuine attack-surface reduction. Practitioner guides such as Linford & Co's requirements walkthrough cover the evidence assessors expect for each.

The v5.0 roadmap: what is actually known

Here is the verifiable record, separated from the speculation. The Council's 2025 Annual Report, published in January 2026, confirms that a second request for comments cycle for the next major version of the standard completed in December 2025. The Council then ran a further RFC from June 3 to July 20, 2026, asking participating organizations where v4.0.1 should evolve, with explicit attention to future technology and AI. No release date has been announced, and no draft requirement text is public.

On direction, the signals deserve a hedge because the Council has not published a formal roadmap. Design goals cited across Council communications and informed commentary, including long-running QSA analysis of the v5.0 process, cluster around three themes: more risk-based flexibility in how requirements can be met, scoping that is less centered on the primary account number as tokenization and modern payment architectures reduce where PAN actually lives, and differentiation between simple and complex environments so a small merchant is not assessed like a global processor. Treat these as directional with moderate confidence. Any of them could narrow or vanish between RFC and publication.

Timing is the question everyone actually types into a search box, and the honest answer has two parts. First, no date exists. Second, even publication is not a deadline: every prior major version of PCI DSS has come with a multi-year overlap during which the old version remained valid, and v4's own future-dated requirements added years beyond that. The realistic planning assumption is that v4.0.1 governs your next several assessment cycles regardless of when v5.0 lands.

What to do between now and v5.0

The wrong response to a version on the horizon is to wait for it. The right response is to make v4.0.1 genuinely routine, because everything signaled about v5.0 rewards merchants who already operate that way. Three moves are worth prioritizing. First, treat the March 2025 controls as operating controls with owners and evidence, not as items that passed once: MFA coverage under 8.4.2, the script inventory under 6.4.3, and the weekly tamper-detection review under 11.6.1 all decay quietly if nobody runs them. Second, shrink scope now. A less PAN-centric v5.0 will reward architectures that already minimize where card data flows, and descoping through tokenization and hosted fields pays for itself in assessment effort today. Third, mature your targeted risk analyses, since the risk-based flexibility being signaled for v5.0 extends a mechanism v4 already introduced, and assessors already expect it done well.

It also helps to keep PCI in perspective within a broader assurance stack. PCI DSS is a contractual, card-brand-driven standard with a prescriptive control set, which makes it structurally different from attestation frameworks. If your customers are also asking for SOC 2 or ISO 27001, our comparison of ISO 27001 versus SOC 2 explains how those regimes differ and where evidence can be reused across them. A program that produces dated evidence continuously handles all three; a program that scrambles per audit handles none of them well.

What to watch next

Concrete markers, in order. The Council's feedback summary from the June 3 to July 20, 2026 RFC, which will show which evolution themes survived contact with participating organizations. The Council's annual Community Meetings in the fall, historically where version roadmap news lands. The 2026 Annual Report, expected in early 2027 based on the January 2026 timing of the last one, which should state where next-version development stands. And eventually a formal announcement of a v5.0 publication window with its transition period. Until that last item exists, every "PCI DSS 5.0 release date" claim you read is inference. This page will be updated as each marker lands. If you would rather have someone watching the standard for you while your team runs the controls, talk to a Z Cyber advisor.