PCI DSS v4.0.1 — What Changed

A New Era for Payment Security

PCI DSS doesn't stand still. The standard has been through several major revisions since its creation in 2004, and the most significant update in its history arrived with version 4.0, published in March 2022. A minor revision, v4.0.1, followed in June 2024 to address errata and provide clarifications. Together, they represent a fundamental shift in how the PCI Security Standards Council expects businesses to approach payment security.

If you've been complying with PCI DSS v3.2.1 — the previous version — you need to understand what's changed. The transition deadline from v3.2.1 was 31 March 2024, meaning all assessments after that date must use the v4 standard. Additionally, some of v4's new requirements had an extended implementation deadline of 31 March 2025, after which they became mandatory for all organisations. This guide covers the key changes and what they mean for your business.

As we covered in Guide 1, PCI DSS applies to every organisation that stores, processes, or transmits cardholder data. The v4 update doesn't change who needs to comply — it changes how you comply and raises the bar on what "good" looks like.

The Customised Approach: Flexibility Meets Rigour

Perhaps the most talked-about change in PCI DSS v4 is the introduction of the "customised approach." In previous versions, there was essentially one way to meet each requirement: follow the prescribed control exactly as stated. V4 now offers two paths.

The defined approach is what you're used to — specific, prescriptive controls that tell you exactly what to implement. Install a firewall. Use 12-character passwords. Encrypt data using a specific standard. If you follow the defined control, you meet the requirement.

The customised approach allows organisations to meet the objective of a requirement using alternative controls of their own design. Instead of asking "did you implement this specific control?" the assessor asks "does your alternative control meet the security objective just as effectively?" This approach is validated through a detailed customised control matrix and independent testing.

The customised approach isn't a shortcut — in many ways it's more demanding because you need to prove your alternative is equally effective. It's designed for mature organisations with sophisticated security programmes that may already have controls in place that don't match the prescriptive wording but achieve the same outcome. For most small and mid-sized businesses, the defined approach will remain the practical choice.

Enhanced Authentication Requirements

PCI DSS v4 significantly tightened the requirements around authentication — how people prove they are who they say they are when accessing systems.

Multi-factor authentication (MFA) has been expanded. Under v3.2.1, MFA was required for remote access to the cardholder data environment. Under v4, MFA is required for all access to the CDE, whether remote or local. This is a substantial change for organisations where staff previously used single-factor authentication (just a password) to access payment systems from within the office.

Password requirements have been strengthened. The minimum password length has increased from 7 characters to 12 characters (or 8 characters if your system cannot support 12). Passwords must include both numeric and alphabetic characters. These requirements apply to all accounts with access to the cardholder data environment, including service accounts and application accounts.

Failed authentication lockout remains at 10 attempts, but the requirements around account management have been tightened. Inactive accounts must be removed or disabled within 90 days, and there are new controls for shared and service accounts.

For businesses that have already adopted modern authentication practices — password managers, MFA everywhere, strong password policies — these changes may not require much work. But for organisations still using simple passwords or lacking MFA on internal systems, this is a significant compliance lift.

Expanded Encryption and Data Protection

Data protection requirements under v4 have been both expanded and clarified. Several changes are worth noting:

Disk-level encryption is no longer acceptable as the sole method for protecting stored cardholder data on most systems. Under v3.2.1, full disk encryption (like BitLocker) could satisfy Requirement 3 for some environments. V4 clarifies that disk encryption only satisfies the requirement on removable media. For other storage, you need file-level, column-level, or field-level encryption — or better yet, don't store the data at all.

Encryption key management requirements have been strengthened, with more specific guidance on key rotation, key storage, and the separation of duties between key custodians.

Hashing requirements have been tightened. If you use hashing to render PANs unreadable, the hash must be keyed (using HMAC or a similar mechanism). Simple, unkeyed hashes are no longer considered adequate because they can be reversed through rainbow table attacks.

The message is clear: the council wants to see stronger, more deliberate data protection. The best strategy remains the one we've been advocating throughout this series — reduce the amount of cardholder data in your environment so there's less to protect. DTMF masking for telephone payments and hosted payment pages for online transactions both achieve this by routing card data directly to the processor.

Targeted Risk Analysis

PCI DSS v4 introduces the concept of "targeted risk analysis" for several requirements. Under v3.2.1, many security controls had fixed frequencies — scan quarterly, review annually, rotate passwords every 90 days. V4 allows organisations to determine their own frequencies for certain controls, provided they conduct a formal risk analysis to justify their chosen schedule.

For example, instead of mandating that all service provider relationships are reviewed at a fixed interval, v4 allows you to determine the appropriate review frequency based on a risk analysis that considers the nature of the service, the data involved, and the risk profile. This applies to areas including:

• Log review frequency — how often you review logs for security events
• Password change frequency — how often passwords must be changed (if you choose time-based rotation rather than event-driven changes)
• Vulnerability scan frequencies for internal scans beyond the required quarterly ASV scans
• Review cycles for security policies, firewall rules, and user access

This is a double-edged flexibility. You get to set frequencies that make sense for your business, but you must document the risk analysis and be prepared to defend your choices to an assessor. "We only review logs monthly because we're busy" won't fly. "We review logs monthly because our targeted risk analysis identified low transaction volume, compensating detective controls, and automated alerting that reduce the risk to an acceptable level" might.

Continuous Security and the End of Point-in-Time Compliance

One of the strongest themes running through PCI DSS v4 is the emphasis on continuous security. The council has been saying for years that compliance should be a continuous state, not an annual event. V4 puts teeth behind that message.

Several requirements now explicitly state that controls must be in place and operating effectively "at all times" or "throughout the year," not just at the point of assessment. New requirements include:

• Requirement 12.3.2: A targeted risk analysis must be performed for each PCI DSS requirement where the entity uses the customised approach, and this analysis must be updated when conditions change
• Requirement 5.3.2.1: If periodic malware scans are used (rather than real-time scanning), the frequency must be defined by a targeted risk analysis
• Requirement 10.4.1.1: Automated mechanisms must be used to perform audit log reviews

The practical implication is that you can't let your security controls lapse between assessments and then scramble to get everything in order when the auditor comes. V4 expects you to be able to demonstrate that your controls have been functioning throughout the entire assessment period. As we'll discuss in Guide 9, treating compliance as an annual checkbox is one of the most common — and now most risky — mistakes businesses make.

Script Integrity and Payment Page Security

PCI DSS v4 introduced entirely new requirements around payment page security that didn't exist in v3.2.1. These primarily affect e-commerce businesses, but they're worth understanding.

Requirement 6.4.3 mandates that all payment page scripts (JavaScript, for instance) that are loaded and executed in a consumer's browser must be managed. You need to maintain an inventory of all scripts, ensure each has a justified business reason, and implement a method to confirm script integrity. This addresses the growing threat of web skimming attacks (sometimes called Magecart attacks), where attackers inject malicious JavaScript into payment pages to steal card data as customers type it.

Requirement 11.6.1 requires a change and tamper-detection mechanism for payment pages. If someone modifies the HTTP headers or content of your payment page, you need to be alerted.

These requirements reflect the evolving threat landscape. As online payment security has improved in some areas, attackers have shifted to client-side attacks that are harder to detect with traditional server-side security tools. For businesses using fully hosted payment pages or iframes, the impact is reduced because the payment page isn't served from your domain — another benefit of descoping, as we discussed in Guide 5.

Timeline and Transition

Understanding the transition timeline is important for planning:

• March 2022: PCI DSS v4.0 published
• June 2024: PCI DSS v4.0.1 published (minor corrections and clarifications)
• 31 March 2024: v3.2.1 officially retired — all assessments must use v4
• 31 March 2025: Extended deadline for "future-dated" requirements — these were identified in the standard as best practices until this date, after which they became mandatory

If you haven't yet transitioned your compliance programme to v4, you need to do so immediately. Your next SAQ submission or QSA assessment must use the v4.0.1 forms and criteria. Work with your acquiring bank or QSA to understand exactly which new requirements affect your environment.

Key Takeaways

• PCI DSS v4.0.1 is the current standard — all assessments must now be conducted against v4, with the final transition deadline having passed on 31 March 2025
• The customised approach offers flexibility to meet security objectives using alternative controls, though it requires more rigorous validation than the defined approach
• MFA is now required for all access to the cardholder data environment, not just remote access — a significant change for many organisations
• Passwords must be at least 12 characters with both numeric and alphabetic characters
• Targeted risk analysis allows businesses to set their own frequencies for certain controls, provided they document the justification
• Continuous security is now a requirement, not just a recommendation — controls must be operating effectively throughout the year, not just at assessment time
• New payment page security requirements address web skimming threats — another reason to use hosted payment pages that keep card data off your domain