PCI DSS 4.0: What I Learned Leading the Migration

PCI DSS 4.0 is the most significant revision to the standard in over a decade. I've spent the last year leading our PCI DSS Level 1 migration across multiple entities. Here's what I learned.

The Shift Nobody Talks About

Most of the conversation around 4.0 focuses on the new technical requirements — stronger authentication, expanded encryption scope, continuous monitoring. Those are real, but they aren't what caught us off guard.

The hard part isn't the technical controls — it's the organizational alignment. PCI DSS 4.0 introduces a customized validation approach alongside the traditional defined approach. Using it is optional, but it's worth understanding because it represents a fundamental shift in how the standard thinks about compliance.

Under 3.2.1, you could point to a control and say "we do this because the standard says so." The customized approach in 4.0 gives you an alternative: instead of following the prescribed control, you can meet the requirement's objective your own way — but you need to demonstrate why your approach works, backed by a formal targeted risk analysis. That's a different conversation to have with your engineering team, your leadership, and your QSA.

Take password requirements as an example. Under 3.2.1, the standard said "7+ characters, rotate every 90 days" — straightforward. Under 4.0, if you've implemented passwordless authentication with FIDO2 keys, the customized approach lets you validate that — but you need a formal risk analysis proving your approach is at least as effective as the defined control. The security is arguably better, and the flexibility is valuable, but the compliance burden is higher.

Start With the Gap Analysis, Not the Remediation

This is the single most valuable thing we did. Before touching a single control, we mapped every 4.0 requirement change against our existing environment. Every delta, every new requirement, every modified requirement — documented and categorized.

What we found surprised us: roughly 60% of our existing controls already met the new requirements with little or no modification. That alone changed our prioritization. But the bigger value was in the decisions that came after.

The gap analysis gave us a clear picture of where we had options. For some requirements, the customized approach was the right long-term answer — our environment and technology justified it, and the investment in a formal risk analysis would pay off over multiple audit cycles. For others, we made a deliberate choice to meet the requirement using the defined approach first, even where a customized approach might have been a better fit. The goal was to reach compliance efficiently, not perfectly — especially with a lean team and no dedicated compliance headcount per framework. You can always iterate and move toward customized validation in areas where it adds value — but you can't do that if you're stuck trying to get everything right in one pass.

Without that gap analysis, we wouldn't have had the visibility to make those trade-offs. I've talked to peers who skipped this step and went straight to remediation — most of them ended up reworking their priorities midstream.

Keep Your QSA in the Loop Early

Don't wait until audit time to surface your 4.0 approach. We engaged our QSA during the gap assessment phase, not after. We walked through our interpretation of the new requirements, discussed where we planned to use customized approaches, and validated our risk analysis methodology before we built anything.

The result: zero surprises at audit. Every finding was expected and already had a remediation plan. The QSA relationship shifted from adversarial (them finding things we missed) to collaborative (us validating our approach together).

If you're managing your own QSA relationship, I'd strongly recommend this. The cost of a few extra hours of QSA consultation during planning is trivial compared to the cost of a finding you didn't anticipate.

Treat It as a Program, Not a Project

This is the mindset shift that matters most. PCI DSS 4.0 isn't a one-time migration you complete and move on from. 4.0 formalizes expectations around ongoing risk review — particularly if you're using customized approaches, where your targeted risk analyses need to be revisited at least annually.

If you're building your remediation plan as a project with a start and end date, you're setting yourself up for a recurring scramble every audit cycle. Build the muscle now: integrate 4.0 requirements into your ongoing compliance operations, your risk register, your internal audit schedule.

Managing Across Multiple Entities

One additional complexity we faced: multiple operating entities under common ownership, each at different levels of control maturity. The same 4.0 requirement might be fully met at one entity and require significant work at another.

Our approach was to build a unified remediation roadmap but track progress per entity. Shared controls (infrastructure, policies, vendor management) got consolidated work. Entity-specific controls got individual timelines. This prevented the most mature entity from being held back while ensuring the less mature entities had realistic paths to compliance.

The Bottom Line

PCI DSS 4.0 is manageable if you approach it methodically. Start with a thorough gap analysis. Engage your QSA early and collaboratively. Build for ongoing compliance, not a one-time project. And if you're running multiple entities, track them independently while leveraging shared controls.

The organizations that will struggle aren't the ones lacking technical capability. They're the ones that underestimate the organizational change required.