Where PCI DSS stands today

PCI DSS v4.0.1 has been the only active version of the standard since v4.0 retired on December 31, 2024. Every requirement is in force, including the ones that were future-dated until March 31, 2025 — there is no grace period left, and nothing you can legitimately defer as "coming later." If your last assessment predated that date, it was run against a partial standard.

v4.0.1 has no announced retirement date. That matters for planning: the Council's own documentation says a version's retirement is subject to change upon the release of a new version, so v4.0.1 remains the standard to build against until a successor is published with its own transition period.

What changed in 2026 is that the Council formally started work on that successor. Here's what actually happened, and what it means for your program.

What the 2026 RFC covered

From June 3 to July 20, 2026, the PCI Security Standards Council ran a Request for Comments (RFC) on PCI DSS v4.0.1. An RFC is not a draft of a new standard and it changes no requirements. It's the Council's structured way of collecting feedback from eligible stakeholders — under NDA, through its own portal — as the first formal step toward the next version.

Participation was substantial: roughly 70 organizations submitted around 884 comments. The Council's October 2026 community meeting presentation broke down where that feedback landed, and the top areas were:

  • Scoping (Requirement 1) — how the CDE boundary is defined and documented, and how segmentation is assessed.
  • Stored account data (Requirement 3) — including key management and keyed hashing.
  • Payment page scripts (Requirements 6.4.3 and 11.6.1) — the client-side script controls introduced in v4.0.
  • MFA and authentication (Requirement 8) — how MFA applies in practice, password complexity, password rotation and passkeys.
  • Vulnerability management and patching — including how AI-assisted code development fits the secure development requirements.
  • Requirements 11 and 12 — testing and security program obligations, where organizations asked for clearer, more workable expectations.

Two themes run through that list: scoping and authentication. Those are the same areas QSAs spend the most time on during assessments, so it's not surprising they generated the most comments. The RFC also asked explicitly about AI, cloud and APIs — a signal in itself about where the standard needs to catch up with how payment environments actually work now.

What the Council is changing next

The Council hasn't published draft requirement text, but its own presentations lay out the goals for the revision:

  • Combine the Customized Approach and Compensating Controls into a single approach, with one consolidated worksheet. Today these are two separate mechanisms with overlapping documentation demands; the intent is one path for meeting a requirement's objective in a different way.
  • Define clear scope impact for the use of PCI SSC validated solutions — so that using a validated product has a predictable effect on scope, rather than an argument.
  • Optimize and modernize validation documents — the ROC, SAQ and reporting templates that assessors and organizations have long criticized as duplicative.

Alongside those, the Council is working on AI guidance and continuing to publish alignment resources, such as the PCI DSS to NIST Cybersecurity Framework mapping. If you use the Customized Approach or Compensating Controls today — or you're evaluating validated solutions to reduce scope — this revision is aimed directly at you.

The road to the next version

The Council's published timeline shows further RFC cycles — a second and third round — with the next version's publication estimated toward 2028. That's an estimate, not an announced date: no release date exists yet, and PCI SSC has been explicit that dates are subject to change. Industry coverage sometimes calls the next version "PCI DSS v5.0," but the Council hasn't committed to a name or number.

History is a useful guide here. The move from v3.2.1 to v4.0 took roughly three years, with long transition and overlap periods. Whatever comes next will follow a similar pattern: publication, a transition window, then retirement of v4.0.1. The practical question for your program isn't "when is the new version" — it's "is my v4.0.1 program in good enough shape to absorb the changes when they arrive."

Guidance worth reading now

The RFC isn't the only thing the Council published this year. Several 2026 releases are worth your time today:

  • Compensating Controls and the Customized Approach (June 2026) — how to document either option, directly relevant to the planned merger.
  • AI guidance — expectations for governing AI use in payment environments.
  • Authentication guidance — MFA, passkeys and password handling under Requirement 8.
  • Segmentation for modern network architectures — cloud, containers and hybrid environments, which is where most segmentation arguments now happen.
  • PCI DSS to NIST CSF mapping — for organizations that maintain both.

Beyond PCI DSS itself, the Council published a new Key Management and Operations (KMO) standard and a major PTS HSM revision — evidence that the modernization push spans the whole standards family, not just PCI DSS.

What to do now

Nothing about the RFC changes your current obligations — which is exactly why waiting is the wrong move. A few practical steps:

  • Don't defer remediation. Assessments today run against the full v4.0.1 standard. Gaps don't get cheaper because a new version is coming.
  • Strengthen your Customized Approach and targeted risk analysis documentation now. Both are clearly areas the Council is refining, and organizations with well-evidenced documentation adapt to version changes far faster than those documenting retroactively.
  • Keep scoping current. It was the number one feedback area. Data flow diagrams, CDE inventories and segmentation documentation should reflect reality today — not last assessment's reality.
  • Get ahead of AI. Inventory where AI is used, including code development, and document the controls around it against the Council's AI guidance.
  • Watch the RFC feedback summary and the Council's next annual report. They'll show which themes survive the review process — the earliest reliable signal of what's actually coming.

Key takeaways

  • PCI DSS v4.0.1 is the only active version and every requirement has applied since March 31, 2025. There is no grace period left.
  • The Council ran a request for comments on v4.0.1 from June 3 to July 20, 2026 — around 884 comments from about 70 organizations — as the first formal step toward the next version.
  • Top feedback areas: scoping, stored account data, payment page scripts, MFA and authentication, vulnerability management, and AI, cloud and APIs.
  • The next revision is expected to merge the Customized Approach and Compensating Controls into one option, clarify scope impact for validated solutions, and modernize validation documents.
  • Publication is estimated toward 2028, but no release date is announced. v4.0.1 remains the standard to build against.
  • The practical move now: tighten documentation (especially Customized Approach and targeted risk analysis), keep scoping current, and govern AI use.

Frequently asked questions

Is PCI DSS v5.0 coming, and when?

The Council is working on the next version of PCI DSS, with further RFC rounds planned and publication estimated toward 2028 in its own presentations. No release date has been announced, and the version number isn't official — industry coverage uses "v5.0" as shorthand. v4.0.1 has no retirement date.

Does the 2026 RFC change any requirements?

No. An RFC is feedback on the current standard; it doesn't modify requirements. Nothing changes for your assessment until a new version is published with its transition period — and even then, transition windows are long.

Should we delay remediation or a gap assessment until the next version?

No. Every assessment today runs against the full v4.0.1 standard, and every requirement applies now. Waiting only makes the eventual transition harder, because you'd be fixing old gaps and adapting to new requirements at the same time.

Will PCI DSS add AI-specific requirements?

The direction is clear — the Council asked explicitly about AI in the 2026 RFC and published AI guidance this year — but no requirement text is public. The practical response is to govern AI use now: inventory it, document controls, and treat AI-assisted code development as part of your secure development process.

About the author. Marcello Duarte (LinkedIn, GitHub, Crunchbase) is a cybersecurity consultant at Radical Security and the author of this blog. He scopes and leads penetration tests and compliance work for organizations working toward PCI DSS, SOC 2 and ISO 27001, and previously worked in vulnerability research, where he discovered CVE-2015-7392. To talk through what the next PCI DSS version means for your program, email [email protected].