PCI Security Standards Council 2026 RFC: What's Coming Next for PCI DSS

A client asked me last week whether they should hold off on some remediation work “since a new version is apparently coming.” I hear some version of this question every time the PCI Security Standards Council makes noise about the future of the standard, and my answer is always the same: no, don't wait. But it's worth understanding exactly what's happening right now, because there is genuine movement toward the next iteration of PCI DSS, and organisations that stay ahead of it tend to have a much easier time when it eventually lands.

Let me walk through what the Council actually opened up this year, what it means in practice, and why I'm telling every client during their PCI compliance audit prep to pay attention rather than panic.

What the Council Actually Announced

On June 3, 2026, the PCI Security Standards Council opened a Request for Comments period on the current PCI DSS v4.0.1 standard. This isn't a leak or a rumour — it's a formal, structured process the Council runs periodically, and this particular RFC ran for six weeks, closing on July 20, 2026.

To be precise about what this is: an RFC is not a draft of a new standard. It's the Council inviting eligible Participating Organizations and stakeholders to submit structured feedback on the current version, under NDA, through the official PCI SSC Portal. It's the very first formal step in how a new version of PCI DSS eventually gets built. Nothing about the technical requirements changes as a result of the RFC itself — but it signals, reliably, that the standard's next evolution is now in motion.

Why This RFC Is Different From Previous Ones

I've watched a few of these cycles now, and this particular RFC had a notable emphasis that earlier ones didn't. The Council specifically encouraged stakeholders to include feedback on “PCI DSS evolution opportunities that can support future technology and AI innovation.”

That's a meaningful signal. It tells me the next version of the standard is very likely to grapple directly with how AI-driven tools — fraud detection systems, automated customer service agents, AI-assisted checkout experiences — interact with cardholder data environments. We've already seen the Council publish separate guidance on AI earlier in the standard's lifecycle; folding AI considerations into the core RFC process suggests it's moving from a side conversation to something that could shape actual requirements down the line.

I wouldn't want to overstate this. The RFC period generates feedback, not requirements. But if you're running a PCI DSS audit today and your environment involves any AI-assisted payment tooling, I'd start documenting how those systems interact with your Cardholder Data Environment now, rather than waiting for a mandate to force the conversation.

The RFC Sits Alongside Other Recent Council Activity

It's worth noting this RFC didn't happen in isolation. Just a week earlier, on June 10, 2026, the Council released a new information supplement specifically addressing the Customized Approach — the mechanism that lets organisations design alternative controls to meet a stated security objective rather than following the defined approach word for word. I've flagged before how much clearer the Customized Approach documentation requirements became under v4.0.1, and this supplement goes further, giving assessors and organisations more concrete guidance on what a defensible targeted risk analysis actually needs to contain.

Taken together, these two moves in the same month tell a consistent story: the Council is actively refining how organisations document and justify their security decisions, and it's laying groundwork for a more structured next version rather than a reactive one.

What Happens After an RFC Closes

This is where I want to manage expectations, because clients sometimes assume a new standard follows immediately once an RFC closes. It doesn't work that way, and it shouldn't. Historically, PCI DSS version transitions have taken years from initial feedback-gathering to publication, and then further time before older versions retire. When v4.0 was published in March 2022, PCI DSS v3.2.1 didn't fully retire until March 2024, and even after that, a large batch of “future-dated” requirements weren't mandatory until March 31, 2025.

If that pattern holds, whatever comes out of this 2026 RFC cycle is unlikely to reshape assessments imminently. What it does mean is that the requirements you're building compliance around today — the ones a PCI qualified security assessor is testing during your current audit — are the ones that matter right now, and will continue to matter for the foreseeable future.

Why Businesses Shouldn't Wait to Act

I want to be direct about this, because I've seen the “wait and see” instinct cost organisations real time. Every current PCI DSS audit is being run against v4.0.1, and that isn't changing anytime soon. Delaying remediation work, deferring a gap assessment, or putting off a scheduled PCI QSA audit because “something new might be coming” is a mistake I actively talk clients out of.

If anything, the RFC is a good prompt to tighten up documentation practices now, particularly around the Customized Approach and targeted risk analysis, since that's clearly an area the Council continues to refine. Organisations that already have strong, well-evidenced documentation tend to adapt faster whenever a new version does eventually arrive, simply because good documentation habits transfer forward regardless of which specific version is active.

What This Means for Choosing PCI QSA Services

This is also a reasonable moment to evaluate how plugged-in your assessor actually is. Not every PCI DSS QSA company tracks Council announcements closely, and I've had prospective clients tell me their previous PCI certified assessor never mentioned the RFC, the AI-focused feedback request, or the Customized Approach supplement at all. That's a gap worth noticing. A QSA firm that's actively following Council activity — RFCs, information supplements, FAQ updates — is generally the one that catches emerging expectations before they become audit findings, rather than after.

When you're comparing PCI QSA services, it's worth asking directly whether the firm participates in or tracks these RFC cycles, and how they translate Council-level activity into practical guidance for clients. That's a genuinely useful differentiator between assessors who are simply running through a checklist and ones who understand where the standard is heading.

Staying Ready Regardless of What Comes Next

My practical advice hasn't changed much from previous version transitions, and I don't expect it to change now. Keep your Cardholder Data Environment scoping current. Maintain your script inventory and monitoring under Requirements 6.4.3 and 11.6.1. Keep your Customized Approach documentation and targeted risk analyses genuinely defensible, not just filed away. And if your organisation is experimenting with AI in any part of the payment flow, start documenting that now — because if the next version of PCI DSS does formalise AI-related expectations, you'll want a head start rather than a scramble.

At Accorp Partners, we treat RFC cycles like this one as an early signal to revisit documentation quality with clients, not as a reason to pause work. The standard you're being assessed against today is the one that matters for your next PCI compliance audit — everything else is groundwork for later.

Frequently Asked Questions

Q: What is the PCI SSC Request for Comments (RFC) process?
It's a formal period during which eligible PCI SSC stakeholders review the current PCI DSS standard and submit structured feedback under NDA, helping shape future versions of the standard.

Q: When did the 2026 RFC period run?
The RFC opened on June 3, 2026, and closed on July 20, 2026.

Q: Does the RFC mean a new version of PCI DSS is about to be released?
Not immediately. An RFC is the early feedback-gathering stage. Based on past version transitions, a new standard typically takes considerable time to develop, publish, and phase in after this stage.

Q: Why did this RFC specifically mention AI?
The Council invited feedback on how PCI DSS could evolve to support future technology and AI innovation, suggesting AI-related payment security may factor into future guidance or requirements.