PCI DSS v4.0 Requirement 11.4: Why Penetration Testing Just Got Harder to Fake
Most organizations are still treating penetration testing as a box to check. Run a scanner, export a PDF, hand it to the QSA. Requirement met.
PCI DSS v4.0 changes that — specifically in Requirement 11.4.
The new requirements do not just ask you to test. They ask you to prove that you tested the right things, the right way, with methodology you can defend. For organizations relying on vulnerability scans dressed up as penetration tests, compliance evidence is going to be a problem.
What Is Requirement 11.4?
Requirement 11.4 covers penetration testing of cardholder data environment (CDE) systems and networks. The headline changes in v4.0:
11.4.1: Defines penetration testing methodology requirements and mandates targeted risk analysis for scoping
11.4.3: Requires active network segmentation testing
11.4.4: Mandates authenticated internal penetration testing
11.4.6/11.4.7: Adds targeted risk analysis and scope documentation for service providers
These are not cosmetic updates. They close the gaps that allowed organizations to claim compliance while doing little more than running a scanner against their CDE boundary.
11.4.1: Methodology Is No Longer Optional
Under PCI DSS v3.2.1, you needed penetration testing. Under v4.0, you need a defined methodology — documented, repeatable, and aligned to a recognized standard. NIST SP 800-115, OWASP, PTES.
Your methodology has to cover the full CDE perimeter, both internal and external perspectives, and application-layer testing where applicable.
The targeted risk analysis for scoping addition is where most organizations fall short. 11.4.1 requires documentation of why specific systems are in or out of scope. QSAs will ask: how did you determine what was in scope? What risk analysis supports that decision?
Testing the same 12 IPs every year is not a defensible answer.
11.4.3: Active Segmentation Testing
If your organization uses network segmentation to reduce PCI DSS scope, that segmentation must now be actively tested. At least once every 12 months, by a qualified resource, confirming that segmentation controls actually prevent CDE access.
This is not a firewall rule review. It is active confirmation that an attacker cannot traverse from out-of-scope networks into the CDE. That requires tradecraft — not automated tooling.
11.4.4: Authenticated Internal Penetration Testing
This is the most significant shift. Internal penetration testing under v4.0 must include authenticated access scenarios. You are no longer limited to testing what an unauthenticated attacker can do from inside your network.
Insider threat, compromised credential, and lateral movement scenarios are now expected testing surface. Attackers with initial access do not stay unauthenticated. Your test has to simulate what they do after the foothold.
Why Vulnerability Scanning Fails the 11.4 Standard
Vulnerability scanners identify known vulnerabilities. They do not:
Chain vulnerabilities to demonstrate real attack paths
Test authenticated escalation scenarios
Validate that segmentation controls actually prevent traversal
Document adversary simulation methodology
Produce evidence that a qualified human assessed targeted risk
A Nessus report is not a penetration test. Under PCI DSS v4.0 Requirement 11.4, a QSA evaluating your evidence is expected to make that distinction. QSAs who accepted scan reports as penetration testing evidence in prior assessments will find themselves in an uncomfortable position if they continue that practice under v4.0. The standards are explicit. The evidence requirements have teeth.
What Defensible 11.4 Evidence Actually Looks Like
QSAs need testing results that demonstrate:
Documented scope methodology with risk analysis rationale
External penetration test results against the CDE perimeter
Segmentation validation through active traversal testing — not a firewall config review
Authenticated internal testing with lateral movement documentation
Qualified, independent tester credentials and independence documentation
Remediation and retest evidence for exploitable findings
This is the evidence package that demonstrates compliance with 11.4. It requires adversary-driven testing by qualified testers — not automated scanning with a report template attached.
What QSAs Should Expect From Testing Partners
Methodology documentation: aligned to a recognized standard and specific to this engagement, not boilerplate.
Scope rationale: documented risk analysis, not just a list of IPs.
Segmentation test evidence: documentation of active traversal testing, not a statement that segmentation was reviewed.
Authenticated testing results: lateral movement attempts documented.
Independence: testing entity genuinely separate from the internal team managing the CDE.
Exploitation evidence: actual exploitability demonstrated in this environment, not just CVSS flagging.
Exploit Technology provides independent penetration testing services aligned specifically to PCI DSS v4.0 Requirement 11.4. We work alongside QSAs — not as a replacement — producing evidence packages that hold up under assessment scrutiny.
The Bottom Line
PCI DSS v4.0 Requirement 11.4 has raised the bar. Targeted risk analysis for scoping, segmentation validation, and authenticated internal testing are no longer optional. They are explicit requirements with documentation and evidence expectations.
Organizations that have been running vulnerability scans and calling them penetration tests are now non-compliant. The question is whether they realize it before their QSA assessment or during it.
The fix: engage a qualified, independent penetration testing partner who understands the v4.0 requirements and can produce evidence QSAs can actually work with. That is the standard Requirement 11.4 now demands. Meeting it requires more than a tool. It requires tradecraft.
Exploit Technology provides independent penetration testing for organizations navigating PCI DSS v4.0 compliance. We support QSAs with testing evidence aligned to Requirement 11.4 methodology, segmentation validation, and authenticated internal testing standards.