PCI DSS v4.0: What Changed and How to Prepare

PCI DSS v4.0, released by the PCI Security Standards Council (PCI SSC) in March 2022, represents the most significant revision to the Payment Card Industry Data Security Standard since v3.0 in 2013. After a two-year transition period, v3.2.1 was officially retired on March 31, 2024. The v4.0 future-dated requirements - initially optional - became mandatory on March 31, 2025. Organizations are now expected to be fully compliant with all v4.0 requirements, including the previously future-dated items. This article details the critical changes and provides actionable guidance for merchants and service providers.

Customized Approach: A Paradigm Shift

Defined vs. Customized Approach

The most fundamental change in v4.0 is the introduction of the Customized Approach as an alternative to the traditional Defined Approach. Under the Defined Approach, organizations implement controls exactly as specified by each requirement. The Customized Approach allows organizations to implement alternative controls that meet the stated security objective of each requirement, provided they can demonstrate equivalent or greater security through a documented risk analysis.

Customized Approach Documentation Requirements

The Customized Approach is not a shortcut - it actually requires more documentation and validation than the Defined Approach. For each requirement addressed through the Customized Approach, the organization must: document a controls matrix showing how their alternative control meets the security objective, perform a targeted risk analysis demonstrating that the alternative control adequately mitigates the identified threats, have the alternative control validated by their Qualified Security Assessor (QSA) as part of the annual assessment, and maintain evidence of control effectiveness on an ongoing basis.

When to Choose Customized vs. Defined

This approach is most valuable for organizations with mature security programs that have implemented advanced controls (e.g., zero-trust architectures, advanced behavioral analytics) that exceed the prescriptive requirements but don't follow the exact implementation specified. For most small-to-medium merchants, the Defined Approach remains the more practical path.

Enhanced Authentication Requirements

MFA for All CDE Access

PCI DSS v4.0 significantly strengthens authentication requirements across the cardholder data environment (CDE). Multi-Factor Authentication (MFA) is now required for all access into the CDE - not just remote access, as in v3.2.1. This means internal administrators, support staff, and any personnel accessing systems within the CDE must use MFA, even when connecting from the corporate network.

Password Policy Updates

Password requirements have been updated: minimum length increased from 7 to 12 characters (or 8 characters if the system doesn't support 12), passwords must be changed every 90 days unless the organization implements a continuous security monitoring approach that detects compromised credentials in real-time. The standard now explicitly requires that passwords/passphrases be checked against known compromised password databases (e.g., HIBP) during creation and reset.

Service and System Account Controls

Service accounts and system accounts are now explicitly addressed: where interactive login is not needed, service accounts must be managed with limited privileges, restricted to the minimum access necessary, and have credentials rotated at a frequency proportional to risk. Application and system accounts that use interactive login are subject to the same MFA requirements as human users.

Targeted Risk Analysis

Risk-Based Frequency Methodology

PCI DSS v4.0 introduces targeted risk analysis as a formal methodology for determining the frequency of certain periodic activities (log reviews, vulnerability scans, password rotation, etc.). Rather than prescribing fixed frequencies, v4.0 allows organizations to determine appropriate frequencies based on a documented risk analysis that considers: the asset's exposure level, threat landscape, vulnerability history, and the potential impact of a compromise.

Application to 12 Specific Requirements

This applies to 12 specific requirements where the standard previously mandated fixed frequencies. For example, rather than requiring quarterly internal vulnerability scans as a blanket rule, the organization can document a risk-based justification for a different scanning frequency - provided the analysis demonstrates that the chosen frequency adequately addresses identified risks. The targeted risk analysis must be reviewed and approved by management at least annually and updated when the risk environment changes.

Mandatory Frequencies That Remain Fixed

However, some frequencies remain mandatory and cannot be modified through targeted risk analysis: external vulnerability scanning must still be performed at least quarterly by an Approved Scanning Vendor (ASV), and penetration testing must still be conducted at least annually and after significant changes.

Client-Side Security: New Requirements

Web Skimming and Magecart Threats

One of the most impactful additions in v4.0 addresses client-side security - specifically the threat of web-based skimming (Magecart-style attacks) that compromise payment pages by injecting malicious JavaScript. Requirements 6.4.3 and 11.6.1 (both previously future-dated, now mandatory) directly address this threat.

Requirement 6.4.3: Script Inventory and Integrity

Requirement 6.4.3 mandates that all payment page scripts are managed with: an inventory of all scripts loaded on payment pages with documented business justification, a method to confirm script integrity (Subresource Integrity - SRI hashes, Content Security Policy headers), and authorization controls ensuring that only approved scripts execute on payment pages. This effectively requires organizations to implement a Content Security Policy (CSP) with script-src directives that allowlist approved JavaScript sources.

Requirement 11.6.1: Change Detection

Requirement 11.6.1 requires a mechanism to detect unauthorized changes to payment pages - including HTTP headers and script content. This can be implemented through: real-time change detection and alerting (file integrity monitoring extended to web content), periodic comparison of payment page content against known-good baselines, or client-side monitoring solutions that detect unauthorized script injection in real-time (solutions like Jscrambler, Source Defense, or Akamai Page Integrity Manager).

Operational Impact for E-Commerce

For e-commerce merchants, these requirements represent a significant operational change. Many organizations have dozens or hundreds of third-party scripts on their payment pages (analytics, marketing tags, A/B testing, chat widgets). Each must be inventoried, justified, and monitored. Organizations should aggressively reduce the number of third-party scripts on payment pages and consider isolating the payment form in an iframe served from a minimal, tightly controlled origin.

Encryption and Key Management Updates

Beyond Disk-Level Encryption

PCI DSS v4.0 strengthens cryptographic requirements to reflect current threats. Disk-level encryption (e.g., BitLocker, LUKS) is no longer sufficient as the sole mechanism for rendering cardholder data unreadable (Requirement 3.5.1.2). Organizations must implement database-level, column-level, or file-level encryption that provides cryptographic isolation - disk encryption only protects against physical theft of media, not logical access by authenticated users or compromised applications.

Cipher Suite Inventory and Review

The standard now requires that cryptographic cipher suites and protocols be formally inventoried and reviewed annually (Requirement 12.3.3). Organizations must document: all cryptographic algorithms in use, key lengths, certificate authorities, certificate expiration dates, and protocol versions. Deprecated algorithms (SHA-1, 3DES, RSA-1024) must be identified and remediated. TLS 1.0 and 1.1 have been prohibited since v3.2.1, but v4.0 now requires that all implementations of TLS 1.2 disable CBC-mode cipher suites where possible, favoring AEAD ciphers (GCM, ChaCha20-Poly1305).

Cloud KMS Requirements

Key management requirements now explicitly address cloud-based key management services (KMS). Organizations using cloud KMS must document the shared responsibility model for key management, ensure that key material is not accessible to the cloud provider in an unencrypted form (BYOK or HYOK models), and verify that key rotation, access controls, and audit logging meet PCI DSS requirements.

How to Prepare

Immediate Compliance Priorities

Organizations that have not yet addressed the previously future-dated requirements are now non-compliant. Immediate priorities should include: conducting a gap assessment against all v4.0 requirements (including the 51 previously future-dated requirements), implementing MFA for all CDE access (not just remote), deploying client-side security controls for payment pages (CSP, SRI, change detection), completing a formal cryptographic inventory and remediation plan, and performing targeted risk analyses for all requirements that permit risk-based frequency determination.

Engaging Your QSA for Customized Approach

For organizations considering the Customized Approach, engage your QSA early in the process. Customized Approach assessments require significantly more assessor time and documentation, which impacts both timeline and cost. Budget 30-50% additional assessment costs compared to the Defined Approach.

Embracing Flexibility in v4.0

PCI DSS v4.0 raises the bar significantly for payment security. But for organizations that embrace the changes - particularly the Customized Approach and targeted risk analysis methodologies - it also provides greater flexibility to implement security controls that align with their specific architecture and risk profile, rather than following prescriptive checklists that may not reflect modern infrastructure realities.