PCI DSS 4.0 Is the Compliance Update That Actually Changed Something
The transition was billed as gradual. Organizations had two years from the March 2022 release of PCI DSS 4.0 to update their programs. March 31, 2024 arrived, version 3.2.1 was retired, and a meaningful number of organizations discovered they had treated a requirements update as a documentation exercise and were now behind on things that had genuinely changed.
PCI DSS 4.0 is a better standard than what it replaced. The requirements are more aligned with how payment card attacks actually work today. It is also substantially more demanding in specific areas that prior assessments had let slide, and the organizations that are struggling are mostly the ones that assumed the gap between 3.2.1 and 4.0 would be narrow.
It is not narrow.
The Customized Approach Is Not a Shortcut
The most significant structural change in PCI DSS 4.0 is the introduction of the customized approach. Under the previous framework, every requirement had a defined implementation. You did the thing the standard specified, the QSA verified you had done it, the checkbox got checked. The customized approach allows organizations to meet the underlying security objective through alternative controls, provided they can demonstrate the alternative achieves the same result.
This sounds like flexibility. It is flexibility, with a significant catch: the documentation burden is substantially higher, and the burden of proof falls entirely on the organization. The defined approach asks you to prove you implemented a specific control. The customized approach asks you to prove your implementation is actually effective against the underlying threat. Those are different conversations with your QSA, and the second one is harder.
Most organizations should use the defined approach for most requirements. The customized approach is genuinely useful when legacy technology or specific architectural constraints make a standard implementation impractical, and when the organization can rigorously document why an alternative meets the same security objective. It is not a mechanism for avoiding requirements that are inconvenient. Organizations that read it that way and brought that reading into their first 4.0 assessment have had uncomfortable conversations with their assessors.
MFA Is Now Required for All CDE Access
Requirement 8.4.2 generated the most industry noise before the deadline, and it deserved it. Multi-factor authentication is now required for all access into the cardholder data environment - not just for remote access, not just for administrative sessions from external locations, but for all human access.
Admin access from inside the corporate network. Developer access to the payment application. Every person with any form of access to systems that touch cardholder data needs MFA before they get in.
For organizations that had deployed MFA on remote access and VPN and considered the problem solved, this requires revisiting every access path into the CDE. Internal administrative access that previously relied on a strong password and network position now needs a second factor. This is technically correct - the assumption that internal network position implies trustworthiness has been wrong for a long time - but operationally it requires changes to how administrators work, and those changes take planning, tooling decisions, and rollout time that organizations often underestimated.
Shared administrative accounts are a specific problem. PCI DSS has always been skeptical of shared accounts, but 4.0 sharpens the requirement: accounts must be tied to individual users so that authentication and activity can be attributed unambiguously. If operational processes run through a shared account, those processes need to be rearchitected, not just documented as exceptions.
Targeted Risk Analysis Is Now Required Work, Not a Formality
Version 4.0 introduced twelve requirements specified at a frequency of "periodically," where previous versions named explicit timeframes. Organizations are now required to conduct a targeted risk analysis to determine the appropriate frequency for each of those activities and document the reasoning behind the decision.
This is more substantive than it appears. A targeted risk analysis is not a paragraph written to satisfy an auditor. It is a documented assessment of the specific risk associated with an activity in your environment, the factors that influence that risk, and the justification for the frequency selected. The QSA reviewing it needs to be able to follow the reasoning to its conclusion.
For compliance programs that have historically run as primarily procedural exercises - do the thing on a quarterly schedule because the schedule says quarterly - this requires building actual risk reasoning into the compliance function. The analysis has to reflect the real threat environment and the organization's specific circumstances, not just the preference for the most convenient interval.
The Software Security Requirements Have Real Teeth
Requirements 6.2 and 6.3 significantly strengthen obligations around bespoke and custom software security. More practically, Requirement 6.4.2 requires an automated technical solution capable of continuously detecting and preventing web-based attacks against payment pages. This means a web application firewall or equivalent capability, actively monitored, configured to block rather than only detect.
Not an annual penetration test. Not manual review on a schedule. Automated and continuous, in enforced mode.
For organizations running payment applications with a WAF in detection-only mode, or with no WAF at all, this is a genuine investment and an operational change, not a documentation update. Detection-only configurations that generate reports nobody reads do not satisfy the requirement.
The language around payment page scripts also tightened. Requirement 6.4.3 requires organizations to manage all payment page scripts, maintain an inventory of authorized scripts, and have a justification for each. This catches the scenario where a third-party widget or analytics tag was added to a payment page without security review and has been sitting there ever since.
What Your Next Assessment Will Look Like
If your organization's PCI compliance posture has not been formally reviewed against 4.0 requirements, your next QSA assessment will be against a standard that may reveal gaps your previous assessments did not surface. Organizations that completed 3.2.1 assessments in 2023 with clean results may not be compliant under 4.0 without remediation work.
The practical path is not complicated: conduct a gap assessment against version 4.0, identify the requirements where current controls fall short, build a remediation roadmap with real owners and real timelines, and work with your QSA before the assessment, not just during it. QSAs who are engaged early enough can help organizations understand which gaps are procedural and which require technology or architecture changes.
The organizations navigating the transition well are treating 4.0 as what it is: a substantive update to a security standard that reflects a more accurate picture of the current threat environment than its predecessor did. The organizations that are struggling waited too long, read the customized approach as an escape hatch, or underestimated what MFA-for-everything actually requires operationally.
The standard was clear about what was changing. The tendency to defer compliance work until it is unavoidable did the rest. If that is where your program is, the gap assessment is the right first move.