PCI DSS 4.0.1 Penetration Testing Requirements: What Counts as QSA-Ready Evidence

Most organizations preparing for a QSA review already know they need a penetration test. PCI DSS mandates one. What trips up otherwise well-prepared teams is evidence, specifically, evidence that's scoped correctly, cites the right requirement numbers, and shows a documented path from finding to closure. Get that wrong and a technically solid pentest still comes back with questions attached.

This guide covers what Requirement 11.4 actually asks for, how it differs from Requirement 11.3, why an ASV scan can't substitute for either, what segmentation testing requires on its own, and what a vendor-selection decision should weigh before you sign a contract.

Where PCI DSS 4.0.1 Enforcement Actually Stands

PCI DSS v3.2.1 retired March 31, 2024. PCI DSS v4.0 became the active standard, and the 51 future-dated requirements deferred since 2022 became mandatory on March 31, 2025. PCI DSS v4.0.1 followed as a clarification release, tightening definitions and language, phishing-resistant authentication being one example, without adding, removing, or re-dating any requirements. Every source we checked for this guide confirms the same thing: v4.0.1 is the sole active version, and there's no grace period remaining on any of the 64 new or updated requirements introduced since 3.2.1.

Practically, that means if your organization is still testing or documenting against 3.2.1 numbering, or treating the future-dated controls as optional, you're not looking at a future compliance gap. You're looking at a current one, and it's the kind a QSA will flag on sight.

Requirement 11.3 vs. Requirement 11.4: Get This Straight Before Your QSA Does

This is the single most common point of confusion in PCI DSS audit prep, and it's worth settling before anything else.

Under PCI DSS 3.2.1, penetration testing lived under Requirement 11.3. When the standard moved to v4.0, and its current clarification release, v4.0.1, the numbering changed. If your documentation, your prior vendor's reports, or your internal wiki still reference "Requirement 11.3" for penetration testing, that's outdated 3.2.1 language, and a QSA reviewing your evidence pack will catch it fast.

Both requirements are mandatory. Both need to show up in your evidence pack as separate artifacts. A QSA who finds only ASV scan reports in a folder labeled "penetration testing evidence" is going to open a finding, not close one.

This also applies whether you're validating through a full Report on Compliance (ROC) with a QSA or a Self-Assessment Questionnaire. SAQ D merchants and service providers carry the full weight of Requirement 11.4. Even SAQ A and A-EP merchants using hosted or redirected payment pages aren't exempt from testing obligations on the systems that remain in scope, including the anti-skimming and script-integrity controls under Requirement 6.4.3 and 11.6.1.

Why a Vulnerability Scanner Won't Satisfy Requirement 11.4

ASV-approved quarterly scans satisfy Requirement 11.3.2. They do not satisfy Requirement 11.4.3. This isn't a technicality QSAs overlook when they like your vendor's report format. It's a structural difference in what each activity actually does.

A scanner identifies known signatures against a static ruleset. It can't chain a low-severity misconfiguration to a broken authorization check to reach cardholder data, and it can't tell your QSA whether that chain is real or theoretical. PCI DSS v4.0.1 explicitly expects testing that demonstrates whether an attacker can exploit what's found, and that demands manual reasoning a scanner doesn't have.

Submitting scan results in place of a pentest report creates a compliance finding on the spot. It also leaves your organization unaware of the real attack surface your QSA is about to scrutinize, which is a worse problem than the finding itself.

What Actually Shows Up in PCI Penetration Test Findings

Knowing what typically fails matters for evidence planning, because it tells you where to expect open findings and how to budget remediation time before your audit window closes.

Payment applications concentrate risk in a narrow set of places. Checkout flows, transaction APIs, and admin portals carry a disproportionate share of injection and access-control findings relative to the rest of a typical environment, patterns consistent with what the OWASP Top 10 and the OWASP API Security Top 10 track as the highest-frequency, highest-impact web and API risk categories. Broken access control shows up constantly in multi-tenant SaaS billing portals and customer dashboards, usually as an object ID that isn't properly scoped to the authenticated user. Weak JWT validation, broken MFA flows, and unauthenticated API endpoints round out the list for API-driven payment stacks.

None of this is exotic, and none of it requires exotic testing to catch. It does require manual reasoning, since a signature-based scanner is structurally unequipped to understand that an endpoint is doing something it shouldn't, when the endpoint itself isn't inherently vulnerable.

For e-commerce environments specifically, Requirement 6.4.3 and 11.6.1 deserve their own line item in your evidence plan. These cover script inventory, authorization, and tamper-detection on payment pages, controls that exist because of the rise in client-side skimming attacks against checkout flows. Even where SAQ A reporting simplified some of the paperwork, the underlying technical requirement didn't go away, and it's a common gap in organizations that migrated payment providers or redesigned checkout without revisiting script authorization.

This is also why chaining matters in your report, not just as an attacker-narrative device but as evidence structure. A low-severity misconfiguration and a weak authorization check are individually minor findings. A report that shows the two combined into a path toward cardholder data is what demonstrates real exploitability, and it's exactly the distinction a QSA is trained to look for between a scan output and a genuine penetration test.

Segmentation Testing Is Its Own Requirement, Not a Side Effect of the Firewall Diagram

If your organization uses network segmentation to shrink the scope of your CDE, that segmentation has to be tested and validated separately, under Requirement 11.4.5. This is a standalone requirement, and it's one of the most frequent gaps in organizations that assume their firewall architecture is sufficient without explicit validation results behind it.

A few specifics that matter here:

• Cadence differs by entity type. Merchants validate segmentation at least annually. Service providers validate it at least every six months, under 11.4.6.
• A network diagram is not evidence. Your QSA needs test results showing the segmentation controls actually hold under attempted traversal, not an architecture drawing showing what was intended.
• Segmentation scope changes trigger retesting. Any change to firewall rules, VLAN structure, or the systems sitting on either side of the boundary should prompt a fresh validation pass, not a wait for the next annual cycle.
• This is where scope-reduction claims get tested for real. If your SAQ eligibility or ROC scope depends on segmentation working, this is the evidence that either supports or undermines that claim in front of an assessor.

What Your QSA Will Look For in the Evidence Package

Assessors reviewing penetration testing evidence check five things, in roughly this order.

1. Tester qualification. The testing organization must be demonstrably independent from your environment. Internal security staff generally don't qualify, regardless of certification level. A third-party firm with no operational relationship to your payment environment does.

2. Methodology documentation. The report must reference a recognized testing framework, such as PTES or NIST SP 800-115. Results presented without methodology context are a recurring QSA finding, not a rare edge case.

3. Scope completeness. Every system in your CDE, plus any system that could affect CDE security if compromised, has to be included. Scope gaps read as audit findings, not administrative oversights.

4. Remediation evidence. Findings can't just be listed. The report has to show that vulnerabilities were resolved before the audit, or that compensating controls are formally documented under PCI DSS Appendix B.

5. Segmentation validation. If segmentation reduces your scope, your QSA needs explicit test results confirming it holds, structured the way described above.

A complete evidence pack built around these five checks has a predictable shape. It starts with a scoped CDE network diagram, mapping the boundary, in-scope systems, and payment data flows in a form your QSA can review without a walkthrough call. Alongside it sits the pentest report itself, methodology-documented, with findings mapped to specific requirement numbers rather than left as generic severity ratings. Segmentation validation appears as its own section or supplementary report, not folded into the general findings. An ASV-scan cross-reference catches discrepancies between your quarterly 11.3.2 scans and the pentest findings before your QSA does. Where something can't be closed in time, compensating controls documentation under Appendix B carries the weight instead of a placeholder note. A prioritized remediation roadmap sequences what's left, and retest confirmation ties each closed finding back to its original ID so the lifecycle is traceable in one pass. An executive summary rounds it out, written for board or QSA pre-briefing rather than for engineers who already have the technical detail.

Miss any one of these and the pack usually still gets reviewed, just with more follow-up questions than a clean submission would generate.

From Finding to Closed Gap: The Remediation and Retesting Cycle

A pentest report full of open findings the week of your audit is not a passing evidence pack, but open findings don't have to mean a failed review either. What matters is whether your QSA can see a clear, evidenced path from each finding to either closure or a formally accepted compensating control.

The pattern that holds up under review, regardless of how far out your audit date is:

• Findings get logged as tickets, not spreadsheet rows. Each one traces finding → fix (or documented risk acceptance) → closure date → responsible owner. A ticket that dead-ends in "won't fix" with no risk acceptance attached is one of the fastest ways to trigger assessor pushback.
• Retesting confirms closure, it doesn't just claim it. For vulnerabilities identified during the pentest, retesting means confirming the specific exploit path is no longer viable, not re-running the original scan and calling it done.
• Evidence gets collected as fixes ship, not scrambled together the week before the audit. Undated screenshots and evidence that's older than its required cadence, a "quarterly" scan report that's five months old, for example, are two of the most common auditor pet peeves that repeat across engagements.
• Compensating controls get documented properly or not at all. Where remediation genuinely can't finish before the audit window closes, PCI DSS Appendix B gives you a real path, but it requires the Compensating Controls Worksheet completed correctly, not a paragraph explaining why you're behind schedule.

If you're staring at a finding list from a readiness assessment, an internal audit, or a prior pentest and need it turned into closed gaps rather than open risk, that execution work is a distinct engagement from the assessment itself. Our PCI DSS Remediation Services team picks up exactly at this point.

What to Look for in a PCI DSS Penetration Testing Vendor

Choosing the wrong provider is how organizations end up back at square one three weeks before an audit. A few things worth checking before you sign anything.

Manual testing capability, not automated-only. Ask directly whether findings come from manual exploitation or from scan output with a cover page attached. If everything in the sample report traces back to a signature match, that's your answer.

PCI DSS and compliance fluency, not general security fluency. A qualified provider should speak fluently about Requirement 11.4, segmentation testing cadence, SAQ implications, and what a QSA will and won't accept as evidence, not just about vulnerabilities in the abstract.

API and SaaS-specific experience. Modern payment environments run on APIs. A provider whose methodology hasn't kept pace with OAuth, JWT-based auth, and multi-tenant authorization risk will miss exactly the findings a signature scanner also misses, which defeats the purpose of paying for manual testing.

Reporting built for QSA submission, not internal use. A good report includes business impact framing, technical evidence, exploit validation, clear remediation guidance, and retest confirmation, structured so your QSA can map evidence to requirement numbers without a follow-up call.

Organizational independence. QSAs strongly prefer, and PCI DSS effectively requires, independent third-party testing over internal staff performing tests on their own environment.

Pentest Testing Corp has worked through this exact evidence-package problem with 257+ organizations across 30+ countries, holding certifications including API Security for PCI Compliance. If you'd like to see the report format before committing to anything, our sample penetration testing report shows the finding structure QSAs are used to reviewing.

Preparing for a QSA review, mid-cycle gap assessment, or initial CDE scoping? Our PCI DSS Penetration Testing & Audit Readiness service scopes engagements against your specific audit timeline. Already sitting on a finding list that needs closing? PCI DSS Remediation Services picks up exactly there.