PCI DSS v4.x has been the only version you can be assessed against since March 31, 2024, when v3.2.1 retired, and the 51 future-dated requirements lost their best-practice grace period on March 31, 2025. Assessments happening in 2026 are well past the point where a QSA will accept a plan instead of evidence.
Most of the attention has gone to the authentication and scripting changes. The clause that quietly does the most damage to how teams actually test sits in Requirement 11.4: "after any significant infrastructure or application upgrade or change."
That phrase is not new. It has been in PCI DSS since the v1.x era, and it sat in Requirements 11.3.1 and 11.3.2 of v3.2.1. What changed in v4.x is that it became much harder to argue your way out of. The standard now gives concrete examples of what counts as a significant change instead of leaving the definition entirely between you and your QSA, and it restated the cadence as "at least once every 12 months" rather than "annually." The obligation was always there. v4.x turned it into something you have to evidence.
If you handle cardholder data, it is worth understanding why that breaks the annual-pentest model, and what to do about it.
What Requirement 11.4 actually requires
Requirement 11.4 is explicit and broad:
- Internal (11.4.2) and external (11.4.3) penetration testing, at least once every 12 months and after any significant infrastructure or application upgrade or change.
- Segmentation testing, where segmentation is used to keep systems out of scope: at least once every 12 months and after any change to the segmentation controls (11.4.5), and at least once every six months for service providers (11.4.6), to confirm that the controls isolating your cardholder data environment actually hold.
- A documented methodology (11.4.1) built on an industry-accepted approach. The requirement text does not name a framework, but PCI SSC's own Penetration Testing Guidance points to NIST SP 800-115, OSSTMM, the OWASP Testing Guide, and PTES as accepted examples. 11.4.1 then spells out what the methodology must contain, including application-layer testing against the Requirement 6.2.4 vulnerability list and retention of results and remediation records for at least 12 months.
- Tester independence. Each of 11.4.2, 11.4.3, 11.4.5, and 11.4.6 carries the same two conditions: the test is performed by a qualified internal resource or a qualified external third party, and organizational independence of the tester exists. The standard adds explicitly that the tester is "not required to be a QSA or ASV," so what is being tested is independence from the team that builds and runs the environment, not a certification badge.
Read together, 11.4 is asking for something an annual engagement cannot deliver: testing that is internal and external, that proves your segmentation, and that keeps pace with change.
Why traditional penetration testing falls short
"After any significant change" is incompatible with a once-a-year engagement. A modern cardholder data environment changes constantly, with deployments, cloud updates, new services, and configuration changes landing weekly. You cannot schedule a multi-week manual pentest after every meaningful change. Between engagements, your tested state and your actual state drift apart, and 11.4 is precisely about closing that drift. An engagement proves a point and then it is over; a continuous adversary campaign never stops, which is the posture 11.4 is reaching toward.
Internal, external, and segmentation are all named. A single external application pentest does not satisfy a requirement that calls out internal testing and segmentation control testing as distinct obligations. The internal network, where an attacker pivots toward the cardholder data environment, is often the least tested and the most consequential.
The window of exposure stays open. A weakness found in next year's pentest may have been exploitable for eleven months. PCI is trying to shrink that window. Point-in-time testing holds it open by design.
Consistency and evidence are hard to sustain by hand. Your assessor wants a defensible, repeatable methodology and clear evidence. Ad hoc internal testing, squeezed in between projects, is difficult to make consistent, independent, and audit-ready.
How SpartanX supports your Requirement 11.4 program
SpartanX is the first Autonomous Exposure Management (AEM) platform: an autonomous adversary that runs the full offensive loop continuously and proves every finding with evidence. That is the shape Requirement 11.4 is reaching for, but at a cadence a human team cannot sustain.
For an 11.4 program specifically:
- Internal, external, and segmentation. SpartanX continuously tests your external attack surface, including your mobile apps and their backend APIs (a major cardholder-data exposure in payments), and, with NodeX, your internal environment, including the east-west paths that segmentation is meant to block, validating whether your isolation actually holds.
- Change-driven, not calendar-driven. Every significant change can trigger fresh adversary testing, and Targeted Attack Validation lets you point the platform at a specific system, release, or segmentation control and get a proven answer on demand. Your posture stays current between annual assessments rather than only at audit time.
- Proof your assessor can use. Every finding is exploit-validated with proof-of-concept evidence, prioritized, remediated, and retested, with audit-ready reporting. SpartanX operates as an independent, autonomous testing capability with a consistent, documented methodology.
To be precise about the boundary: SpartanX supports and strengthens your Requirement 11.4 program and complements your QSA's assessment. It does not replace your QSA, and it does not by itself make you PCI compliant. What it does is take the hardest part of 11.4, testing that is internal and external, continuous, segmentation-aware, and evidence-backed, and make it something you actually run, all year.
Why now
Because there is no runway left. Everything in 11.4.1 through 11.4.6 has been fully assessable since March 2024, and 11.4.7, the only future-dated requirement anywhere in 11.4, lost its grace period in March 2025. There is no version of the standard left to grow into and no best-practice status to hide behind, so a 2026 assessment is a straight evidence check. Teams that attach a continuous adversary to their cardholder data environment turn 11.4 from an annual scramble into a steady state, and they enter their assessment with evidence already on file rather than a test still to schedule.
The shift in one line
Requirement 11.4 assumes a world where your environment changes faster than you can manually test it. That world is here. Autonomous Exposure Management is how you test at the speed your environment actually changes.
SpartanX is The Ultimate Adversary™, pointed at your cardholder data environment, continuously. Request a guided proof-of-value, or learn what Autonomous Exposure Management is.
Ready to see SpartanX in action?
See how a continuous adversary maps your whole attack surface, inside and out, and proves what is actually exploitable.