PCI DSS v4.0 Changes and What They Mean for European Merchants

PCI DSS v4.0 represents the most significant revision to the Payment Card Industry Data Security Standard since its inception. Published by the PCI Security Standards Council in March 2022, this version introduces 64 new requirements - 13 of which apply to all entities and 51 specifically to service providers. After a two-year transition period, v3.2.1 was officially retired on 31 March 2024, and the remaining future-dated requirements became mandatory on 31 March 2025. For European merchants, this update arrives at a time when the regulatory landscape is already complex, with GDPR, PSD2, and evolving national data protection laws intersecting with payment security obligations.

PCI DSS v4.0 Overview

The PCI Security Standards Council designed v4.0 around four main goals: ensuring the standard continues to meet the security needs of the payments industry, adding flexibility for organisations using different methods to achieve security, promoting security as a continuous process rather than a point-in-time exercise, and enhancing validation methods and procedures. The standard now contains 12 core requirements (unchanged from v3.2.1) but with substantially expanded sub-requirements, more prescriptive guidance, and new focus areas that reflect the evolution of payments technology since the last major version published in 2016.

One of the most important structural changes is the introduction of the Customised Approach, which sits alongside the traditional Defined Approach. Rather than prescribing specific controls, the Customised Approach allows organisations to define their own security controls, provided they can demonstrate that those controls meet the stated security objective of each requirement. This is powerful but requires significantly more documentation, testing, and assessor involvement.

Key Changes Impacting European Merchants

1. Customised Approach vs Defined Approach

With v3.2.1, every organisation followed the same set of prescriptive controls. v4.0 introduces a bifurcation: you can continue with the Defined Approach (the traditional method, with specific controls to implement) or choose the Customised Approach, where you design controls that achieve the same security outcome but in a way suited to your specific environment. The Customised Approach requires a Targeted Risk Analysis for each custom control, documented evidence that the control meets the requirement's objective, and validation by a Qualified Security Assessor (QSA) with experience in this methodology. For most mid-market European merchants, the Defined Approach remains the practical choice. The Customised Approach is typically adopted by large enterprises with mature security programmes and dedicated compliance teams.

2. Strengthened Authentication Requirements

Multi-Factor Authentication (MFA) is now required for all access to the Cardholder Data Environment (CDE) - not just remote access. Under v3.2.1, MFA was mandatory only for non-console administrative access and remote access to the CDE. v4.0 extends this to all accounts that can access the CDE, including local console access and service accounts where technically feasible. For European merchants, this means reviewing every system with access to card data and ensuring MFA is implemented comprehensively. Password requirements have also been strengthened: the minimum length increases from 7 to 12 characters (with a transition period at 8 characters until systems are updated), and passwords must be changed every 90 days or organisations must implement dynamic account security analysis.

3. New E-Commerce Script Integrity Requirements

Requirement 6.4.3 is one of the most impactful additions for e-commerce merchants. It mandates that all scripts loaded and executed in the consumer's browser on payment pages must be managed - that is, authorised, integrity-verified, and inventoried. This directly targets supply-chain attacks like Magecart, where malicious JavaScript is injected into checkout pages to steal card data. European e-commerce merchants must implement Content Security Policy (CSP) headers or a script management solution that monitors changes to payment page scripts and alerts on unauthorised modifications. Complementary Requirement 11.6.1 requires change- and tamper-detection mechanisms on payment pages that alert on unauthorised changes to HTTP headers and script content.

4. Targeted Risk Analysis Requirements

v4.0 replaces the general annual risk assessment with a more structured Targeted Risk Analysis (TRA). Rather than a single monolithic risk assessment, merchants now perform targeted analyses for specific requirements - for example, determining the frequency of log reviews, the interval for vulnerability scans, or the cryptographic key rotation schedule. Each TRA must document the specific threat landscape, assets at risk, likelihood and impact of compromise, and the rationale behind the chosen control frequency or configuration. TRA results must be reviewed at least annually and updated when the threat environment changes.

5. Updated Cryptography Standards

PCI DSS v4.0 tightens requirements around cryptographic protocols and cipher suites. TLS 1.0 and 1.1, which were already discouraged, are now explicitly prohibited. All encrypted connections must use TLS 1.2 or higher with strong cipher suites. Certificates must be valid and trusted, and wildcard certificates must be justified. Key management requirements now include documented cryptographic key rotation procedures, and organisations must be able to demonstrate they have an inventory of all cryptographic keys used to protect cardholder data, including expiry dates and renewal schedules. Disk-level encryption alone is no longer sufficient to meet the at-rest encryption requirement on removable media and in certain storage scenarios.

6. Enhanced Logging and Monitoring

Logging requirements have been substantially expanded. Organisations must now implement automated audit log review mechanisms - manual log reviews alone are no longer acceptable to meet Requirement 10. Log entries must capture additional fields, including user identity, event type, date and time, success or failure indication, origin of the event, and the identity or name of the affected data, system component, or resource. Real-time alerting is required for critical events, and logs must be protected from unauthorised modification via integrity monitoring mechanisms. For European merchants, these enhanced logging requirements can also support GDPR obligations around breach detection and incident response timelines.

The European Dimension: Intersection with GDPR

European merchants operate under a dual regulatory framework - PCI DSS for payment card security and GDPR for personal data protection. PCI DSS v4.0 creates several points of alignment and occasional tension with GDPR. On the positive side, the enhanced logging and monitoring requirements support GDPR's 72-hour breach notification obligation by improving detection capabilities. The emphasis on role-based access, least privilege, and data minimisation aligns well with GDPR's data protection principles.

However, friction can arise around data retention. PCI DSS mandates audit log retention for at least 12 months, while GDPR requires that personal data not be retained longer than necessary. If audit logs contain personal data (usernames, IP addresses, transaction identifiers), organisations must reconcile these competing requirements - typically through data classification and targeted retention policies that satisfy both standards. v4.0's Customised Approach offers some flexibility here, allowing organisations to design controls that meet the PCI security objective while respecting GDPR constraints.

Timeline and Deadlines

The transition to PCI DSS v4.0 followed a structured timeline. v4.0 was published in March 2022. From that point, organisations could validate against either v3.2.1 or v4.0. On 31 March 2024, v3.2.1 was officially retired - all assessments from that date must use v4.0. However, recognising the scope of some changes, the Council designated 51 requirements as "future-dated" - they were best practices during 2024 but became mandatory on 31 March 2025.

How PCI Proxy Helps with v4.0 Compliance

The most effective strategy for managing PCI DSS v4.0 complexity is minimising the environment that falls within scope. PCI Proxy achieves this by completely removing card data from your infrastructure. When raw PANs never enter your servers, databases, or application logs, the vast majority of v4.0 requirements simply do not apply to your environment. The new script integrity requirements (6.4.3 and 11.6.1) become significantly easier to manage when your payment pages use PCI Proxy secure fields - card data is captured in an isolated iframe hosted in the PCI Proxy environment, meaning your page scripts never have access to raw card numbers.

The strengthened authentication requirements become narrower in scope because fewer systems have access to cardholder data. Logging and monitoring obligations are simplified because there are fewer systems to monitor - the PCI Proxy vault handles its own audit logging within a Level 1 certified environment. And cryptography requirements are intrinsically met within the vault, where AES-256 encryption and HSM key management are already in place. In practical terms, tokenisation via PCI Proxy can reduce your assessment scope from SAQ D (over 300 controls) to SAQ A or SAQ A-EP (fewer than 30 controls), making v4.0 compliance achievable even for organisations with limited security resources.

Merchant Readiness Checklist

European merchants should use the following checklist to assess their PCI DSS v4.0 readiness:

Conclusion

PCI DSS v4.0 is the most substantial update to the standard in its history. For European merchants, the combination of new technical requirements, the intersection with GDPR, and the shift toward continuous security monitoring creates a complex compliance landscape. However, the most impactful step any merchant can take is to reduce the scope of their Cardholder Data Environment. By removing raw card data from your infrastructure through tokenisation, you eliminate the environment in which most v4.0 requirements apply - transforming an assessment of over 300 controls into a manageable one of 30 controls.

The transition deadlines have passed and compliance is no longer optional. Whether you are just starting your v4.0 journey or refining an existing programme, the time to act is now. Assess your current scope, identify gaps, and consider whether a PCI Proxy architecture can simplify your path to compliance.