PCI DSS penetration testing, built for your ROC

What PCI DSS Req. 11.4 requires

PCI DSS v4.0.1 Requirement 11.4 obligates any entity storing, processing, or transmitting cardholder data to run penetration testing against the cardholder data environment (CDE) and any systems connected to it — at least once every 12 months, and again after any significant change to network architecture, applications, or infrastructure that could affect the CDE's security. A significant change isn't limited to a new payment flow: a re-architected VPC, a new third-party integration with access into the CDE, or a major application release can all trigger the retest obligation.

This is the requirement most QSAs push back on hardest, because it's the one most often satisfied with the wrong artifact. A vulnerability scan report, however thorough, is not a penetration test — 11.4 expects evidence of exploitation attempts, not just detection. Assessors are also checking for continuity: the same scope, tested on a defensible cadence, with findings tracked to remediation — not a one-off exercise bought the week before the assessment.

Internal vs external testing, and CDE scope

Req 11.4 splits into internal and external testing, and both are mandatory. External testing targets every system-facing, internet-reachable component of the CDE — payment APIs, customer-facing applications, VPN and remote-access endpoints. Internal testing covers the CDE from the perspective of an attacker who already has a foothold inside the network, which in practice means testing segmentation boundaries, internal APIs, and any system that can reach cardholder data laterally.

Scope discipline is where most programmes lose credibility with their QSA. "Connected-to" systems — anything that can affect the security of the CDE even if it never touches card data directly, like an internal admin panel with a network path into the payment environment — are in scope under PCI DSS v4.0.1's definition of the CDE, and a common finding in QSA reviews is a pentest scope that quietly excludes them. Scope should be defined once, mapped to the CDE and its connected systems, and reused consistently across every test cycle rather than redrawn ad hoc each time a test is scheduled — that consistency is itself part of what a QSA is checking for.

A defined methodology (NIST SP 800-115, OWASP)

Req 11.4.1 doesn't just require a test — it requires a defined, documented methodology behind it, industry-recognized approaches such as NIST SP 800-115 or the OWASP testing guides being the common references. This is precisely the question a QSA asks that catches teams out: "show me how you test," not "show me your last report." A methodology with no documentation trail — or one that changes tester to tester — is a gap the assessor will flag even if the findings themselves are sound.

breachr's testing methodology is written down, versioned, and cryptographically signed — architected to hold up when a QSA asks how a given finding was reached, in which environment, and against which scope. Every engagement runs the same documented process whether the work is performed by an accredited human tester or an agentic-AI tester, so "how do you test" has one answer, not one per engagement.

• ✅ A documented methodology referenced in the report, not just a tool name
• ✅ Consistent process across internal and external testing, and across test cycles
• ✅ A record of who or what performed each test action, tied to the methodology it followed

The evidence your QSA drops into the ROC

The deliverable that actually satisfies Req 11.4 in an assessment is an evidence pack the QSA can cite directly against the Report on Compliance — mapped to the specific 11.4 sub-requirement it satisfies, not a raw findings export the assessor has to reinterpret. breachr produces that pack with a cryptographic chain of custody: every finding carries a record of who found it — a named human tester or an identified AI agent — when, and in which environment, so provenance is never in question when the QSA asks.

That distinction matters because 11.4 and 11.3.2 are frequently — and incorrectly — treated as interchangeable. Quarterly ASV scans satisfy 11.3.2; they are automated, external, and run by an Approved Scanning Vendor. They do not satisfy 11.4, which requires the deeper, methodology-driven testing described above, on its own annual-plus-significant-change cadence. A ROC that cites ASV scan output as penetration-test evidence is a gap a QSA will catch. breachr keeps the two streams clearly separated in the evidence pack, so what goes in front of the assessor for 11.4 is unambiguous.

Related guides