PCI DSS v4.0 was published on 31 March 2022. After four years of development, stakeholder feedback rounds, and two draft versions, the Payment Card Industry Data Security Standard has its most significant update since version 3.0 a decade ago. Organisations certified under v3.2.1 have until 31 March 2024 to complete the transition — two years to absorb, plan, and implement the changes.

This post gives you the practical breakdown: what v4.0 changes at a structural level, what the most operationally significant new requirements are, and how to start planning a transition that does not become a scramble in Q1 2024.

The Structural Change: Customised Implementation

The most philosophically significant change in PCI DSS v4.0 is the introduction of the customised implementation approach alongside the existing defined approach. Under v3.2.1, organisations implemented specific prescribed controls — the standard told you what to do and how to do it. Under v4.0, organisations can choose to implement controls differently, provided they can demonstrate that their customised approach achieves the stated security objective of each requirement.

This is a meaningful shift. It acknowledges that the security landscape and organisations’ technology environments are diverse enough that a single prescribed implementation is not always the most effective security measure. It gives mature security programmes the flexibility to implement controls that better fit their architecture — but it also requires significantly more documentation and evidence, because the organisation must prove their customised approach achieves the objective, not just implement a prescribed control.

For most organisations, particularly those in their first few PCI DSS cycles, the defined approach remains the right choice. Customised implementation is an option for organisations with the security maturity and documentation capability to use it credibly.

The Most Significant New Requirements

Multi-factor authentication expanded. Under v3.2.1, MFA was required for all non-console administrative access and remote access to the CDE. Under v4.0, MFA is required for all access to the cardholder data environment — including access by personnel working within the network perimeter. This is one of the most operationally impactful changes for organisations that have not already implemented MFA broadly for CDE access.

Password requirements updated. Minimum password length increases to 12 characters (from 7 under v3.2.1) for systems where technology supports it. Password complexity requirements are revised. These requirements, flagged as “future-dated” in v4.0, become mandatory from 31 March 2025 — organisations have time to plan but should not defer.

E-commerce and phishing protections. New requirements address the specific threat profile of card-not-present environments. Requirement 6.4.3 requires that all scripts loaded and executed in a consumer’s browser for payment pages are managed, documented, and their integrity ensured. Requirement 11.6.1 requires a mechanism to detect changes to HTTP headers and the contents of payment pages. These requirements directly target Magecart-style skimming attacks — a persistent and growing threat to e-commerce payment flows.

Targeted risk analysis. v4.0 introduces flexibility in the frequency of several recurring activities — organisations can set their own frequency for some requirements rather than meeting prescribed timelines, provided they conduct a targeted risk analysis justifying their chosen frequency. This flexibility is accompanied by a documentation requirement: the risk analysis must be performed, documented, reviewed, and approved.

Authentication mechanisms strengthened. Requirement 8 has been substantially reworked, with more prescriptive requirements for service accounts, system/application accounts, and the management of accounts used by vendors and other third parties. The expansion of MFA requirements and the new controls around password management sit within this strengthened authentication framework.

What the Transition Timeline Looks Like

v3.2.1 retires on 31 March 2024. From that date, assessments will be conducted against v4.0 only. The transition plan for most organisations involves three phases:

First, a gap assessment: mapping your current v3.2.1 controls against v4.0 requirements to identify where the changes create compliance gaps. The MFA expansion, the e-commerce script requirements, and the updated authentication requirements are the areas where gaps are most commonly found.

Second, remediation planning: prioritising the gaps identified, estimating the effort to close them, and building a remediation roadmap. Future-dated requirements (those mandatory from March 2025 rather than March 2024) can be sequenced into a second phase, but should be planned for now rather than deferred until the deadline approaches.

Third, evidence collection: updating your documentation, policies, and audit evidence to reflect the v4.0 requirements and your implementation against them. Your next QSA assessment will be conducted against v4.0 — having documentation in order before that assessment begins saves significant time.

At Bitsecura, we support organisations through PCI DSS v4.0 transitions — from gap assessment through remediation planning to QSA readiness. If you are starting to think about your v3.2.1 to v4.0 transition and want a clear view of where your gaps are and what closing them requires, start a conversation with us here.

Bitsecura provides PCI DSS compliance support, gap assessment, and QSA readiness services. Learn more about our PCI DSS services.