PCI DSS v4.0 vs v4.0.1: What Actually Changed and Why It Matters

Understand PCI DSS v4.0.1 changes, clarified requirements, updated RoC and SAQs, and what they mean for your next PCI compliance audit.

Accorp Compliance Team

Accorp Compliance Team

Our team of compliance experts specializes in PCI DSS, SOC 2, and other security frameworks to help businesses achieve and maintain compliance.

Follow meLinkedIn

I get this question at least once a week now, usually from a client who's just been told by their acquiring bank or payment processor that they need to “align with v4.0.1.” Nine times out of ten, the first reaction is confusion — didn't we just finish migrating to v4.0? Do we need to start over?

The short answer is no. But the longer answer is worth understanding properly, because I've seen this exact confusion cost organisations weeks of unnecessary rework during a PCI compliance audit, simply because someone assumed v4.0.1 was a brand-new standard rather than a clarification of the one they already had.

Let me walk through what actually changed, what didn't, and why the distinction matters more than most people think.

What PCI DSS v4.0.1 Actually Is

PCI DSS v4.0.1 is not a new version of the standard in the way v4.0 was a new version of v3.2.1. It's a minor revision, released by the PCI Security Standards Council to correct formatting errors, fix typographical mistakes, and clarify language that assessors and organisations were interpreting inconsistently across different PCI DSS QSA companies.

That last point is important. When I was working with clients through the early v4.0 transition, I noticed real variation in how different assessors interpreted certain requirements — not because anyone was wrong, exactly, but because the original wording left room for it. v4.0.1 tightened that language so an assessment under one QSA firm looks the same as an assessment under another.

Since PCI DSS v3.2.1 was retired at the end of 2024, v4.0.1 has been the sole active version of the standard. There is no PCI DSS v4.0 anymore in any practical sense — every assessment being performed today, whether it's a full Report on Compliance or a Self-Assessment Questionnaire, is being conducted against v4.0.1.

Why the Council Issued a Minor Revision Instead of Skipping Straight to v5

This is a fair question, and one I've fielded from a few CTOs who assumed a “.1” bump meant something trivial. It wasn't trivial in terms of impact, even though the technical content didn't change.

The original v4.0 document, published in March 2022, introduced a significant volume of new material — 64 new or updated requirements compared to v3.2.1, with a large number of those designated as “future-dated” to give organisations time to prepare. That's a lot of new ground covered in one release, and inevitably, some of the wording created ambiguity once thousands of organisations and hundreds of QSAs started applying it in real environments.

Rather than wait years for a full v5 release, the Council did what most mature standards bodies do: they issued a point release to clean up the language before it caused inconsistent enforcement. That's exactly what v4.0.1 is.

What Did NOT Change Between v4.0 and v4.0.1

I want to be direct about this because it's the part that trips people up most during a PCI DSS audit. Version 4.0.1 does not add new requirements. It does not remove any. It does not change the technical substance of what you need to implement.

If your organisation had already built its compliance program around the full v4.0 requirement set — including the future-dated requirements that became mandatory on March 31, 2025 — you are not starting over. You are, in nearly all cases, already aligned with v4.0.1 without doing anything additional.

This is where I see the most wasted effort. Teams that panic and try to re-run an entire gap assessment from scratch when what they actually need is a fifteen-minute conversation with their PCI qualified security assessor to confirm nothing material changed for their specific environment.

What DID Change: Clarifications Worth Knowing

Even though the requirements themselves stayed the same, the clarifications in v4.0.1 do matter, particularly in a few areas I flag during every current PCI compliance audit.

Customized Approach language was tightened. The original v4.0 text describing how organisations could design and document alternative controls to meet a stated security objective — rather than following the defined approach word for word — left some interpretation gaps. v4.0.1 clarified exactly what documentation a targeted risk analysis needs to contain for a customized control to hold up under review.

Report on Compliance templates were reissued. The Council published an updated RoC template in August 2024 specifically aligned to v4.0.1 language. If your QSA is still working from an older template, that's worth raising directly with them.

SAQ updates followed in stages. Updated Self-Assessment Questionnaires came out in October 2024, with further SAQ A-specific changes in January 2025 and e-commerce guidance in March 2025. Businesses using SAQ A or SAQ A-EP should specifically confirm they're working from the current version, since the wording changes there were more substantive than in most other sections.

Minor wording fixes across vulnerability management and authentication sections removed ambiguity that had previously led different assessors to apply slightly different standards for what counted as adequate evidence.

None of this changes what security controls you actually need in place. It changes how clearly those controls are described and evidenced — which, from an audit-readiness standpoint, is not nothing.

Why This Distinction Matters for Your Next PCI DSS Audit

I've sat across the table from procurement teams who specifically ask vendors, “are you v4.0 compliant or v4.0.1 compliant?” as though these are meaningfully different certifications a vendor could pass or fail differently. They're not. There is one active standard right now, and it's v4.0.1. If a vendor tells you they're “v4.0 compliant,” they either mean the same thing using older terminology, or their documentation hasn't been updated — worth asking about, but not a red flag on its own.

Where I do think the distinction genuinely matters is in vendor and partner due diligence. If you're reviewing a payment processor's Attestation of Compliance and it explicitly references v4.0 rather than v4.0.1, and it was issued after the retirement of v3.2.1, that's worth a direct question. It might just be outdated paperwork. It might also mean their last assessment predates the RoC template refresh, and it's worth confirming their PCI DSS QSA company has since realigned their documentation.

What This Means If You're Choosing a QSA Right Now

This is genuinely one of the more useful screening questions I'd suggest asking when evaluating PCI DSS QSA companies today. Ask directly whether their assessment methodology and RoC templates are current against v4.0.1, and ask how they handled the transition for existing clients. A QSA firm that can answer this clearly and specifically — rather than giving a generic “yes, we're compliant” — is usually the one that's actually kept pace with the Council's updates rather than just renaming a v4.0 checklist.

I'd also flag that the standard isn't static even now. The Council opened a Request for Comments period on the current version in mid-2026, running through July, which signals further refinement is coming. Organisations working with an experienced QSA partner tend to hear about these shifts early, rather than finding out during their next scheduled audit.

The Practical Takeaway

If you're currently PCI DSS compliant and your last assessment covered the full v4.0 requirement set, including the future-dated controls, you don't need to treat v4.0.1 as a new project. What you need is confirmation — a short conversation with your assessor to verify your documentation, RoC template, and SAQ version all reflect the current language, and that nothing in the clarified sections changes how your specific environment is scoped or evidenced.

Where I've seen real value added is when clients use this as a natural checkpoint to review their Customized Approach documentation and targeted risk analyses against the tightened wording, since that's the area where the clarifications actually shift what a QSA will expect to see as evidence.

At Accorp Partners, this is usually a quick review rather than a full re-engagement — but it's one worth having before your next PCI compliance audit rather than during it.

Learn more- https://accorppartners.com/services/risk-assurance/pci-dss

Frequently Asked Questions

Q: Is PCI DSS v4.0.1 a completely new standard?
No. It's a minor revision of v4.0 that clarifies wording and corrects errors, without adding or removing any technical requirements.

Q: Do I need to redo my compliance program for v4.0.1?
In most cases, no. If you're already aligned with the full v4.0 requirement set, including future-dated requirements, you're generally already aligned with v4.0.1.

Q: When did v4.0.1 become the only active version?
PCI DSS v3.2.1 was retired at the end of 2024, making v4.0.1 the sole active version organisations are assessed against today.

Q: What changed in the Report on Compliance template?
The PCI Security Standards Council released an updated RoC template aligned to v4.0.1 language in August 2024, with further SAQ-specific updates following into 2025.

Q: Should I ask my QSA about v4.0.1 specifically?
Yes. It's a reasonable question to ask any PCI qualified security assessor or PCI DSS QSA company whether their templates and methodology reflect the current v4.0.1 language.

Also Read

Over 500+ clients have chosen Accorp for their compliance, tax, and risk assurance needs.

PCI DSS Compliance for Digital Wallets:  Tokenized Wallet Compliance
Blog

PCI DSS Compliance for Digital Wallets: Tokenized Wallet Compliance

Read More about PCI DSS Compliance for Digital Wallets: Tokenized Wallet Compliance
Click to Pay and Network Tokenization: How IT Change Your PCI Scope
Blog

Click to Pay and Network Tokenization: How IT Change Your PCI Scope

Read More about Click to Pay and Network Tokenization: How IT Change Your PCI Scope
Targeted Risk Analysis (TRA) Under PCI DSS 4.0: How to Actually Write One That Holds Up
Blog

Targeted Risk Analysis (TRA) Under PCI DSS 4.0: How to Actually Write One That Holds Up

Read More about Targeted Risk Analysis (TRA) Under PCI DSS 4.0: How to Actually Write One That Holds Up
PCI Security Standards Council 2026 RFC: What's Coming Next for PCI DSS
Blog

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

Read More about PCI Security Standards Council 2026 RFC: What's Coming Next for PCI DSS
PCI DSS Requirements 6.4.3 and 11.6.1 : Explained: Securing Your Payment Page Scripts
Blog

PCI DSS Requirements 6.4.3 and 11.6.1 : Explained: Securing Your Payment Page Scripts

Read More about PCI DSS Requirements 6.4.3 and 11.6.1 : Explained: Securing Your Payment Page Scripts