PCI DSS Penetration Testing: What Requirement 11.4 Actually Demands

If your business stores, processes, or transmits cardholder data, PCI penetration testing isn't a nice-to-have — it's written into the standard by name. PCI DSS v4.0 puts it in Requirement 11.4, and a QSA will ask for it specifically during your assessment. The mistake I see most often from PCI compliance teams is treating "we ran a scan" as if it satisfied the pentest control. It doesn't. PCI DSS v4.0 separates the two on purpose: quarterly vulnerability scanning lives in Requirement 11.3, and penetration testing — an actual attempt to break into your cardholder data environment (CDE) — lives in Requirement 11.4. This guide walks through what 11.4 actually demands: scope, frequency, who is allowed to run the test, and the evidence an assessor wants in hand before they sign anything. I'll be precise about where an automated test helps and where it doesn't, because the honest answer matters more than the sales pitch when your AoC is on the line.

What PCI penetration testing is (and what it is not)

A PCI penetration test is a controlled attack against the systems in scope for PCI DSS — chiefly the cardholder data environment and anything that can reach it — performed to find and prove exploitable weaknesses before a real attacker does. The operative word is prove. A tester doesn't just report that a service looks outdated; they demonstrate that the flaw can be used to reach cardholder data, escalate privileges, or pivot across your network, and they document the reproduction path.

That is the line between a penetration test and the other control people confuse it with. An ASV scan — an external vulnerability scan run quarterly by an Approved Scanning Vendor under Requirement 11.3.2 — is an automated pass that flags known weaknesses by signature and version. It's breadth. It's necessary. It's also not a penetration test, and you cannot use one to satisfy the other. PCI DSS asks for both because they answer different questions: the scan asks "what might be wrong here?" and the pentest asks "what can an attacker actually do with it?" If you want the longer treatment of that split, the difference between vulnerability assessment and penetration testing is the same distinction the standard is drawing, sharpened.

Requirement 11.4, sub-requirement by sub-requirement

Most competitor pages say "PCI requires a pentest" and stop. The requirement is more specific than that, and each sub-requirement is a place your assessment can stall if you treat it loosely. Here's what 11.4 actually contains in v4.0.

11.4.1 — A documented methodology

Before any testing happens, you need a penetration testing methodology that is defined, documented, and implemented. PCI is explicit about what it must include: an industry-accepted approach (the PCI SSC penetration-testing guidance points at NIST SP 800-115, the OWASP testing guides, and PTES), coverage of the entire CDE perimeter and critical systems, testing from both inside and outside the network, validation of any segmentation and scope-reduction controls, application-layer testing that covers the software vulnerabilities in Requirement 6.2.4 (injection, broken access control, and the rest), and network-layer testing across the components and operating systems that support network functions. It also has to describe how you assess and remediate what you find, and you have to retain the results for at least 12 months.

A QSA reads this document first. If your methodology is a one-line statement, expect questions.

11.4.2 — Internal penetration testing

You test from inside the network — as if an attacker already has a foothold, or an insider is poking around. This is the assumed-breach angle, and it's where segmentation and internal trust boundaries get stress-tested. It runs at least once every 12 months and after any significant infrastructure or application change.

11.4.3 — External penetration testing

You test from outside — the internet-facing attack surface of the CDE, the way a remote attacker sees you. Web applications, exposed APIs, VPN endpoints, mail and DNS, anything reachable from the public internet that touches or fronts cardholder data. Same cadence: at least annually and after significant change. Internal and external are distinct tests with distinct objectives; doing one does not cover the other.

11.4.4 — Fix what was exploited, then retest

This is the sub-requirement that trips teams up in v4.0. Exploitable vulnerabilities and security weaknesses found during the test have to be corrected in line with your risk assessment (per Requirement 6.3.1), and then the penetration test is repeated to verify the fix actually worked. A findings report with a remediation column is not enough on its own — the assessor wants evidence that the retest confirmed the correction. Budget for the second pass; it's not optional.

11.4.5 and 11.4.6 — Segmentation testing

If you use network segmentation to keep the CDE isolated and shrink your scope — and most organizations do, because it's the single biggest lever on assessment cost — you have to prove the segmentation holds. 11.4.5 requires testing all segmentation controls at least once every 12 months and after any change to those controls, confirming they genuinely isolate the CDE from out-of-scope systems. 11.4.6 is the stricter version that applies to service providers only: the same segmentation testing every six months rather than annually. (There's also 11.4.7, a narrow control requiring multi-tenant service providers to support their customers' external testing.)

Segmentation testing is the part an outside-in test structurally cannot cover, because confirming isolation requires access on both sides of the boundary. Keep that in mind — I'll come back to it.

11.4 vs 11.3: the pentest is not the ASV scan

This is the confusion that costs the most time in a real assessment, so it's worth a side-by-side. Requirement 11.3 is scanning; Requirement 11.4 is penetration testing. They are separate controls with separate cadences, separate providers, and separate evidence.

	ASV / vulnerability scan (11.3)	Penetration test (11.4)
What it is	Automated scan for known weaknesses	Active exploitation of the environment
Frequency	At least quarterly + after significant change	At least annually + after significant change
Who runs it	External scans by a PCI SSC ASV; internal by qualified staff	Qualified internal resource or external third party with organizational independence
Output	Ranked list of potential vulnerabilities	Confirmed findings with proof of exploitation and impact
Segmentation	Not validated by the scan	Explicitly tested (11.4.5 / 11.4.6)
Pass condition	A passing ASV scan (no high-risk findings)	Exploitable findings remediated and retested (11.4.4)

One nuance in that "who runs it" row that saves people a lot of money: PCI does not require the penetration test to be performed by a QSA or an ASV. It requires a qualified tester — internal or third party — with organizational independence from the team that built or manages the systems. The ASV designation applies to the quarterly external scan under 11.3.2, not to the pentest. So you can use a capable specialist provider for 11.4 and reserve the QSA for the assessment itself.

An ASV scan and a penetration test are not two flavors of the same control. One is quarterly breadth by a certified scanning vendor; the other is periodic proof by a qualified tester. Bring one to your QSA where they expected the other and you have a gap, not a head start.

Scope: the CDE, and everything that can reach it

Scope is where PCI penetration testing gets expensive or cheap, and it's decided long before a tester touches a keyboard. The cardholder data environment is the set of systems that store, process, or transmit cardholder data, plus any system that can connect to or affect the security of those systems. That last clause is broad on purpose — a jump host, a shared authentication server, a monitoring agent with access into the CDE all pull those systems into scope.

The test has to cover that scope from two directions and at two layers:

• External and internal. The internet-facing perimeter (11.4.3) and the internal network (11.4.2). An attacker who lands a phishing payload is now inside; internal testing is how you find out what they'd reach next.
• Application layer and network layer. Application-layer testing covers the web apps and APIs that handle card data — the OWASP-style bugs: injection, broken access control, IDOR exposing another customer's transactions, SSRF, authentication bypass. Network-layer testing covers the hosts, services, and operating systems underneath. Requirement 11.4.1 names both explicitly, so a report that only tested one layer leaves a hole an assessor will notice.

Segmentation sits on top of all of it. If you've carved the CDE off from the rest of the corporate network to keep scope small, the pentest has to confirm that wall is real — that out-of-scope systems genuinely cannot reach into the CDE. Get the segmentation testing wrong and your "reduced scope" quietly expands to your entire network, which is the most expensive way to discover a misconfiguration.

How often, and what counts as a "significant change"

The baseline cadence is at least once every 12 months for internal, external, and segmentation testing (every six months for service-provider segmentation under 11.4.6). But "annually" is only half the rule. The other trigger is after any significant infrastructure or application change, and that's the one that catches teams shipping continuously.

PCI leaves the exact definition of "significant" to you, but the intent is clear: a new system component in the CDE, a major application upgrade, a change to network topology or firewall rules, a new payment flow, a move to a new data center or cloud environment. If the change could plausibly affect the security of the CDE, it triggers a retest of the affected scope — you don't wait eleven months for the annual test to catch it.

Whether Requirement 11.4 even applies to you depends on how you validate. Organizations completing a Report on Compliance (ROC) — Level 1 merchants and most service providers — have 11.4 in scope. Merchants who qualify for the shorter self-assessment questionnaires vary: SAQ D includes the full Requirement 11, while smaller, more outsourced profiles like SAQ A historically do not carry the penetration-testing control. Confirm your SAQ type before you assume you're covered — or that you're exempt.

What a QSA wants to see in the report

A clean-looking PDF is not evidence. When an assessor reviews your penetration test, they're checking that specific artifacts exist and hang together. From the reports I've watched pass and fail, this is the anatomy that survives scrutiny:

• The methodology, matching the documented approach from 11.4.1 — scope tested, tools and techniques, dates, and the tester's qualifications and independence.
• Findings with evidence. Each issue described with enough detail to reproduce it, and — for anything exploitable — a proof of concept showing the exploit actually worked. This is the difference between "the login form may be injectable" and a demonstrated bypass with the request that did it.
• Severity ratings, typically CVSSv3, feeding your risk ranking under 6.3.1 so remediation priority is defensible rather than arbitrary.
• Remediation status, and critically, retest evidence proving that exploited findings were fixed and re-verified (11.4.4).
• Segmentation results, if segmentation is in scope — confirmation that isolation controls were tested and hold.

A QSA isn't hoping for a report with zero findings. They're looking for a report that found real issues, ranked them honestly, fixed the exploitable ones, and proved the fix with a retest. That story closes the requirement. A suspiciously empty report just raises the question of how hard anyone actually looked.

For a concrete sense of what that anatomy looks like on the page, a redacted sample report is worth reading before you commission anything — findings with working PoC, CVSSv3 scores, and framework mapping are exactly what an assessor is scanning for.

What a PCI penetration test costs

Pricing spans a wide range because scope does. A traditional human-led PCI penetration test from a consultancy typically runs from a few thousand dollars for a tightly scoped external test into the tens of thousands for a large CDE with internal, external, application, and segmentation testing — and the calendar cost is weeks: scoping, scheduling, four-to-six weeks of testing, the report, then a wait for the remediation retest. That retest under 11.4.4 is a real line item people forget to budget for.

The drivers are the same ones that move any pentest price — number of in-scope systems and applications, internal versus external, whether segmentation testing is included, and how much manual depth the engagement demands. The full breakdown of what you're paying for is in the penetration testing cost guide, and the tradeoffs between delivery models — consultancy, PTaaS, autonomous — are covered in penetration testing services. For PCI specifically, the thing to price carefully is cadence: the "after significant change" trigger means the annual number is a floor, not the total, if you ship often.

How BackDoor maps to PCI DSS v4.0 Requirement 11.4

Here's the honest version, because overstating this helps nobody heading into an audit.

BackDoor is an autonomous, black-box penetration test: a swarm of AI agents attacks your target from the outside like a real attacker — no source code, no backend access — and delivers a full test plus report in around five hours instead of the usual four-to-six weeks, from €5,100. Every finding is a proven exploit with a working proof of concept, scored with CVSSv3, paired with step-by-step remediation, and mapped to frameworks including PCI DSS v4.0. Fix the findings, re-run, and a passing scan earns an attestation letter you can put in front of a customer or your assessor.

Where that maps cleanly onto Requirement 11.4:

• 11.4.3 — external penetration testing. This is the core fit. BackDoor covers the internet-facing attack surface of your CDE and the web-application layer autonomously, which is exactly the external, application-layer testing 11.4.1 and 11.4.3 call for.
• 11.4.4 — remediation and retest. The re-run-and-attest loop is built for this: fix, re-scan, get a passing result on record. That maps directly to the "correct and retest" requirement that trips people up.
• 11.4.1 evidence. Documented methodology, CVSSv3-scored findings, and reproduction detail are the artifacts a QSA reviews — the report is structured to hand over, not to decode.
• Speed as cadence. Because a full run takes hours, not weeks, it's realistic to test after every significant change instead of once a year — which is the part of 11.4 that's hardest to keep up with manually.

And, just as important, where it does not reach:

• 11.4.2 — internal penetration testing requires access from inside your network. An outside-in autonomous test does not perform the assumed-breach internal engagement on its own.
• 11.4.5 / 11.4.6 — segmentation testing requires access on both sides of the segmentation boundary to confirm isolation. That's structurally outside what an external black-box test can validate.
• The QSA and the AoC. BackDoor maps findings to PCI DSS v4.0; it is not a QSA, it does not issue a ROC or an Attestation of Compliance, and mapping to a framework is not the same as certification. Your assessor still runs the assessment and signs the paperwork.

The right way to use it: as continuous testing and pre-audit readiness that covers the external and application-layer half of 11.4 fast and cheaply, keeps you tested after every change, and hands your QSA clean, exploit-backed evidence — so the human engagement that remains (internal, segmentation, sign-off) is shorter and less surprising. It accelerates the PCI compliance program; it doesn't replace the QSA. If autonomous black-box testing is new to you, scanning your external attack surface with BackDoor is the fastest way to see what the report actually contains.

What to actually do next

Start by confirming whether Requirement 11.4 is even in your scope — check your SAQ type or ROC obligation before anything else. If it is, treat 11.4 as five distinct deliverables, not one: a documented methodology (11.4.1), internal (11.4.2) and external (11.4.3) tests, corrected-and-retested findings (11.4.4), and segmentation testing (11.4.5, or 11.4.6 if you're a service provider). Map each one to who's going to perform it and on what cadence — remembering that the ASV quarterly scan under 11.3 is a separate control you still owe.

Then get the external and application layer covered early and often, so it's not the thing holding up your assessment. An autonomous test that produces exploit-backed, CVSSv3-scored findings mapped to PCI DSS v4.0 in about five hours — with an attestation letter on a passing re-scan, zero data retention, and NDA/DPA available — is a low-friction way to close 11.4.3, feed 11.4.4, and walk into your QSA engagement already knowing what an attacker can and can't reach. Read a real sample report, run a scan against your CDE's external surface, and reserve the human time for the internal and segmentation work that genuinely needs it.

Last updated 2026. Requirement references are to PCI DSS v4.0 / v4.0.1.