What closed yesterday#
On 20 July 2026, PCI SSC closed a six-week request for comments on PCI DSS. It opened 3 June.
This one got almost no attention outside assessor circles, which is a shame, because RFC periods are where the standard actually gets shaped. By the time a new version lands and everyone starts arguing about it on LinkedIn, the decisions that produced it were made eighteen months earlier, partly on the strength of feedback submitted during windows like this one.
Two details are worth getting right, because a fair amount of secondary coverage has muddled them.
First, this was not a comment period on a draft of a new version. Stakeholders were asked to review and give feedback on the currently published v4.0.1. The Council described it as beginning the next iteration of PCI DSS by soliciting industry feedback on the current version, with a focus on strengths and opportunities, to help shape where the standard goes.
Second, participation was gated. The RFC ran through the PCI SSC Portal, participants had to accept an NDA to download the document, and comments were only accepted through the Portal within the defined window. Nothing submitted, and nothing in the RFC document itself, is public.
The part worth reading twice#
Buried in the announcement is a sentence that does more work than its length suggests. Stakeholders were encouraged to include specific feedback about PCI DSS evolution opportunities that can support future technology and AI innovation.
That’s the Council naming AI, unprompted, in the framing of what it wants to hear about.
Standards bodies don’t put a technology in the ask unless they’re already thinking about it. And in this case the thinking has a visible trail. In March 2025 the Council published guidance on integrating artificial intelligence into PCI assessments. In September 2025 it published a piece on AI principles for securing AI use in payment environments. The RFC language in June 2026 is the third step in a sequence, not a one-off.
So the reasonable read is not that AI requirements are imminent. It’s that the Council has spent roughly eighteen months moving AI from “thing we should say something about” toward “thing the standard may eventually have to account for,” and it just asked the industry to help define what that looks like.
What that could touch#
Speculating about specific requirement numbers would be silly, and anyone who does it in the next few months is guessing. But the surface area is not hard to map, because it’s the surface area practitioners are already struggling to document.
AI systems inside or adjacent to the CDE. If a model or an agent can read, transform, or route cardholder data, it’s in scope, and the current standard gives you no purpose-built language for describing it. Teams are currently mapping AI components onto system component definitions written for servers and applications. It works, awkwardly.
Non-human identity and agent authorization. Agentic systems act with credentials, often broadly scoped, often long-lived, often provisioned outside the process that governs human access. Requirement 7 and Requirement 8 concepts apply, but the assumption underneath them is that an identity maps to a person or a defined service. An agent that decides its own next action stretches that.
AI-assisted monitoring as evidence. This one cuts both ways. Detection tooling increasingly uses models to triage and correlate, and the question of whether model-produced output satisfies a monitoring or review requirement is live. The Council’s 2025 guidance on AI in assessments suggests it’s thinking about the assessor side of this too.
Third-party AI services. Most organizations aren’t building models, they’re calling somebody else’s API. That’s a third-party relationship with data flow implications, and the existing TPSP framework was not designed with inference endpoints in mind.
The other thing that shipped in June#
Slightly upstream of the RFC, on 10 June 2026, PCI SSC released a new information supplement covering compensating controls and the customized approach.
That’s less headline-friendly and more immediately useful. The customized approach has been the least-understood part of v4.x since it arrived, and the gap between “we’re using the customized approach” and “we have documented a targeted risk analysis an assessor will accept” is where a lot of programs quietly fall over. If you’re implementing anything through customized approach, that supplement is worth pulling from the document library directly rather than reading somebody’s summary of it.
Where to put your attention#
Practical takeaways, in rough priority order:
Confirm your v4.0.1 posture is current. The RFC changes nothing about what’s assessable today. The future-dated requirements have been effective since 31 March 2025.
Pull the June information supplement. Get it from the PCI SSC document library. If you’re leaning on the customized approach anywhere, read it before your next assessment cycle, not after.
Start the AI inventory. Not because a requirement exists, but because scoping already demands you know what touches cardholder data, and AI components are quietly failing to show up in a lot of scope diagrams.
Get eligible for the next RFC if you weren’t for this one. Participation runs through Participating Organization status. If your organization has strong opinions about how PCI DSS should handle AI and you had no way to submit them this cycle, that’s a fixable problem before the next window.
Be careful what you claim about the contents. The RFC document was distributed under NDA. If you see confident public commentary about what’s in it, treat that as a signal about the commenter, not about the standard.
Standards move slowly, and that’s mostly a feature. But the direction of travel usually shows up in the process documents well before it shows up in a requirement. The Council spent June and July asking the industry how PCI DSS should evolve to support AI. Whatever the next version looks like, that question is now on the record.
