PCI DSS 4.0 — One Year On: What We've Learned

PCI DSS 4.0 became mandatory on 31 March 2025. Thirteen months later, the first full compliance cycle is behind us, and the patterns from Q1 2026 assessments are now clear enough to draw conclusions. Some of the changes have landed as intended. Others have been widely misinterpreted, creating compliance risk that will not reveal itself until the next QSA assessment.

This is not a recap of the standard. It is a look at what the first year has actually surfaced in real engagements, drawn from conversations with QSAs, pen testing providers, and merchants across Europe and North America.

A Quick Recap of the 4.0 Changes

PCI DSS 4.0 introduced several structural shifts from the 3.2.1 regime. The customised approach allows organisations to define alternative control implementations if they can demonstrate equivalent risk mitigation. Targeted risk analysis is required for any control implementation that relies on organisational judgement. Authenticated internal vulnerability scanning replaced unauthenticated scanning as a minimum. Multi-factor authentication requirements expanded to all access into the cardholder data environment. Segmentation testing moved from annual to every six months for organisations relying on segmentation to reduce scope.

For penetration testing specifically, Requirement 11.4 remained largely intact but with clearer expectations around methodology, scope, and the handling of segmentation controls.

Lessons From the First Compliance Cycle

The customised approach is being under-used and, where used, often poorly documented. The option to implement a customised control was supposed to allow mature organisations to tailor PCI DSS to their actual risk profile. In practice, most organisations have stuck with the defined approach, either because their QSAs have signalled reluctance or because the documentation burden has proved greater than expected. Where customised approaches have been attempted, the targeted risk analysis is frequently inadequate, missing the structured threat modelling and justification the standard expects.

Authenticated scanning is catching issues that were invisible under the old regime. Merchants that moved from unauthenticated to authenticated internal vulnerability scanning have typically seen a three to five times increase in reported vulnerabilities in the first quarter, as credentialed scans see into the operating system and application layer. Most of these are legacy misconfigurations that predate the new requirement. Q1 2026 assessments have exposed organisations that assumed a clean 3.2.1 scan history translated to a clean 4.0 baseline.

Segmentation testing every six months is straining provider capacity. Organisations that relied on annual segmentation tests under 3.2.1 now need to engage their providers twice yearly. Providers have adapted, but lead times for segmentation testing specifically have lengthened in heavily regulated markets. Booking three to four months ahead is now the norm.

MFA expansion has caught many organisations off guard. The new requirement to apply MFA to all access into the CDE, including system accounts, non-console administrative access, and cloud management consoles, triggered a wave of remediation work in 2025. A surprising number of organisations only discovered in 2026 that their MFA implementation did not cover all the paths the standard now requires.

Where Pen Testing Has Been Misinterpreted

The 4.0 standard did not fundamentally change the pen testing requirement, but several misinterpretations have become common.

The biggest is treating authenticated internal scanning as a substitute for internal penetration testing. They are different controls. Requirement 11.3 covers vulnerability scanning. Requirement 11.4 covers penetration testing. Some organisations have conflated the two, reasoning that their authenticated scans now cover what internal pen testing used to cover. They do not. Internal pen testing still requires manual exploitation, lateral movement testing, and privilege escalation attempts that scanners cannot perform.

Another common error is under-scoping application-layer testing. The standard requires testing of vulnerabilities listed in Requirement 6.2, which aligns with the OWASP Top 10. Some pen tests cover the network layer thoroughly but treat the application layer as a tick-box exercise, running automated scans without meaningful manual testing of business logic, authentication flows, and authorisation controls. Q1 2026 assessments have increasingly flagged this as insufficient.

Segmentation testing is often performed without verifying the segmentation control itself. A proper segmentation test places the tester on a non-CDE network segment and attempts to reach the CDE through any available path. Some providers have been conducting what amounts to a connectivity review rather than an active penetration attempt, which does not satisfy the standard's intent.

Scoping Pitfalls From Real-World Q1 2026 Assessments

The most common scoping failures are not new, but the 4.0 regime has made them more expensive to miss.

Cloud workloads are frequently excluded from CDE scope definitions that predate significant cloud migration. An organisation that moved its payment processing to AWS in 2023 and still documents its CDE as a set of on-premise IP ranges has a scoping problem. QSAs in Q1 2026 have been notably more rigorous about cloud scope documentation than in previous cycles.

Third-party service providers are another source of pain. The customised approach, and the clearer expectations around shared responsibility, have pushed merchants to demonstrate exactly which PCI DSS requirements their payment processors, cloud providers, and managed service providers are delivering on their behalf. Many organisations discovered in Q1 2026 that their service providers' AOCs did not actually cover what they assumed.

Development, staging, and pre-production environments that handle real cardholder data, or data representative of it, have been caught more systematically in 2026 assessments. The 4.0 standard's clearer expectations around data protection in non-production environments have made this harder to quietly ignore.

How to Prepare for the 2027 Refresh

The PCI Security Standards Council has indicated that a 4.0.2 or 4.1 refresh is likely in 2027. While the details are not yet public, several directions are visible from council communications and working group activity.

Expect stronger requirements around software supply chain security, reflecting the increasing focus on this across other frameworks. This will likely include clearer expectations around dependency scanning, SBOM maintenance, and third-party code verification.

Expect the customised approach to be clarified, potentially with more prescriptive templates for targeted risk analysis to reduce the documentation burden that has limited its adoption.

Expect MFA and authentication requirements to tighten further, potentially including phishing-resistant factors for the most sensitive access paths.

Organisations preparing for the 2027 cycle should use 2026 to consolidate their 4.0 compliance, tighten their scope documentation, and invest in the penetration testing capabilities that the refresh is likely to demand more of.

Our PCI DSS compliance guide at /compliance/pci-dss covers the full penetration testing requirements in detail. Our directory lists PCI DSS specialists, including PCI QSA-qualified providers who can handle both the assessment and the pen testing components of your compliance programme.