Last Updated on February 25, 2026 by Arnav Sharma
The standard PCI Standard dropped back in March 2022, went through a minor housekeeping revision in June 2024, and as of 31 March 2025, every single requirement is now fully mandatory. No more “best practice” grace period. No more treating the future-dated items as optional homework.
So let’s talk about what this version actually means for organizations handling payment card data, why the changes exist, and what you should be focused on if you haven’t locked down your compliance posture yet.
Why v4 Exists at All
The short version: the threat landscape in 2022 looked nothing like it did when v3.2.1 was written. Ransomware, phishing campaigns targeting payment systems, Magecart-style skimming attacks on e-commerce checkout pages, cloud-hosted cardholder data environments – none of this was well-served by the older standard.
The PCI SSC collected over 6,000 comments from more than 200 organizations during development. That’s a meaningful consultation process, and it shows in the output. The council had four things they were trying to fix: align the standard with modern threats, push organizations away from “compliance as a point-in-time exercise,” give larger and more complex organizations flexibility to implement controls that fit their architecture, and tighten up how assessments are conducted.
v4 delivered on all four, though the flexibility piece tends to be the most misunderstood.
The 64 New Requirements – What They Actually Cover
The headline number is 64 new or revised requirements. Fifty-three apply to all entities; eleven are specific to service providers. That sounds like a lot, but when you map them against the 12 principal requirements, a clear pattern emerges. The changes aren’t random – they cluster around four main areas.
Protecting account data with stronger cryptography
Requirements 3 and 4 got eight new requirements between them. The big ones:
- SAD (sensitive authentication data) stored electronically before authorization now needs to be encrypted. This closes a gap that existed in v3.2.1 where pre-authorization storage sometimes fell into grey areas.
- PAN protection via disk-level encryption on non-removable media is no longer acceptable. If you’re relying on full-disk encryption as your primary control for stored PANs, you need to rethink that architecture.
- Keyed cryptographic hashes are now required for hashed PANs. MD5 hashes without a key? That’s gone.
- Technical controls must prevent PAN from being copied or moved during remote access sessions.
I’ve seen the disk-encryption issue catch organizations off guard, particularly those running on-premises infrastructure with legacy storage configurations. It’s worth auditing early.
Access control and authentication getting serious
Requirements 7 and 8 add twelve new requirements combined. MFA is now required for all access to the cardholder data environment – not just privileged or administrative accounts. Every user who can reach the CDE needs MFA. Full stop.
Password minimums jumped to 12 characters (with both alphabetic and numeric elements), unless the system genuinely can’t support it. The 8-character fallback exists, but you should be documenting why you need it rather than defaulting to it.
System and application accounts now have their own dedicated management and review procedures. This is the kind of thing that gets overlooked in scoping exercises – non-human accounts accessing CDE components still need to be tracked and reviewed.
Threat detection and monitoring
Ten new requirements across Requirements 5, 10, and 11 focus on detecting threats faster and responding more effectively.
The one that probably has the biggest operational impact for e-commerce teams is Requirement 11.6.1: tamper detection for payment pages. If you’re running any kind of client-side JavaScript on a checkout page – which every modern e-commerce site does – you need a mechanism to detect unauthorized changes. This is a direct response to Magecart. Attackers inject malicious scripts into checkout flows to skim card data before it even hits your payment processor. The old standard had no specific control for this.
Phishing protections are now explicit. Anti-phishing mechanisms must be deployed for personnel. Automated log reviews replace the old manual, periodic approach.
Organizational maturity and risk management
The largest bucket is the internal risk management category with 23 new requirements. Annual CDE scope confirmation. Explicit assignment of roles and responsibilities for nearly every requirement. Targeted risk analysis (TRA) as a formal mechanism for justifying activity frequencies and customized controls.
The TRA piece is actually useful once you get familiar with it. If your organization wants to conduct certain activities – vulnerability scans, log reviews, user access reviews – at frequencies different from the defaults, you can justify that with a documented risk analysis. It’s the standard’s way of acknowledging that a monthly cadence might be overkill in one environment and insufficient in another.
The Customized Approach: Flexibility with Accountability
This is probably the most significant structural change in how compliance can be demonstrated. The “defined approach” still exists – you implement the control exactly as specified. But the “customized approach” lets organizations substitute alternative controls if they can demonstrate those controls meet or exceed the requirement’s security intent.
The catch is documentation. You need a targeted risk analysis that’s specific, reviewed, and defensible to a QSA. You can’t just claim your compensating controls are equivalent – you need to show the evidence.
For mature organizations with complex architectures, this is genuinely useful. A large financial institution running a cloud-native payment processing environment might have controls that don’t map neatly to the defined approach prescriptions, but demonstrably achieve better outcomes. The customized approach gives them a path to compliance without forcing architecture changes that would actually reduce security.
Smaller organizations should probably stick to the defined approach unless they have a clear, specific reason not to.
Where Organizations Are Getting Tripped Up
Having seen a few of these assessments play out, certain patterns come up repeatedly.
- CDE scoping is still the biggest gap: The v4 scoping guidance was updated to account for cloud environments, third-party services, and modern network architectures. But organizations are still drawing their CDE boundaries too loosely, pulling in systems that don’t need to be in scope, or – worse – drawing them too tightly and leaving connected systems unprotected. Get this right before you do anything else.
- E-commerce page protection is underestimated: Requirement 11.6.1 requires a mechanism to detect unauthorized changes to payment pages. This means a technical control, not just a policy. If your team hasn’t implemented client-side integrity monitoring on checkout flows, that’s a gap that needs closing.
- MFA rollout scope surprises: When teams realize “all access to the CDE” means more than just admin accounts, there’s usually a discovery phase where systems and user accounts that had been flying under the radar need to be brought into the MFA framework. Plan for this.
- Application and system account inventory: Non-human accounts – service accounts, API accounts, automated processes – accessing CDE components now need dedicated management procedures. A lot of organizations haven’t maintained this inventory rigorously.
Practical Steps for Getting Compliant
If you’re working through a compliance programme right now, here’s where to focus energy:
- Start with scoping: Use the updated v4 guidance on modern network segmentation and cloud environments. Be precise about what’s in scope and document your rationale.
- Assign ownership immediately: Every requirement in v4 needs documented roles and responsibilities. This isn’t just administrative overhead – when something breaks, you want it to be clear who owns the fix.
- Audit your cryptography: Check stored PANs for disk-level encryption dependencies, review hashing implementations for key usage, and verify pre-authorization SAD handling.
- Build your TRA library: If you’re using activity-frequency flexibility anywhere, have your targeted risk analyses documented and current. These get reviewed during assessments.
- Test your e-commerce pages: Requirement 11.6.1 needs a technical solution. Work with your development team to implement change detection mechanisms on payment page scripts.
For larger organizations going through ROCs with QSAs, the Prioritized Approach for PCI DSS v4.0.1 (updated January 2025) is a useful planning tool. For smaller merchants, updated SAQs are available and worth reviewing even if you’ve been through the process before.
The Bottom Line
PCI DSS v4 isn’t a bureaucratic refresh. It addresses real attack patterns that have caused real breaches – skimming, phishing, weak authentication, inadequate monitoring. The 64 new requirements look daunting on paper, but most of them reflect things well-run security programmes should have been doing anyway.
The bigger shift is cultural. The standard is trying to move organizations from “we passed the assessment” to “we have controls that continuously protect payment data.” That’s a harder lift than updating a config, but it’s the right direction.
As of February 2026, full compliance with v4.0.1 is required. If there are gaps in your programme, now is the time to close them rather than explaining them to a QSA.