Most PCI penetration tests that get rejected were competently executed. The testing was real, the tester was skilled, and the vulnerabilities found were genuine. What failed was the deliverable: it could not evidence the methodology, the exploitation, the coverage, or the retest that PCI DSS 4.0 penetration testing requirements now demand. Your QSA is not assessing whether a test happened. They are assessing whether the document in front of them proves it happened the way Requirement 11.4 specifies. That gap costs you weeks first and a change order second, and it almost always surfaces when your assessment window is already closing.
The Test Passed. The Report Got Rejected.
You scoped the engagement in good faith. The vendor tested for a week, found a handful of real issues, wrote them up, and delivered a clean PDF. You paid the invoice, tracked the fixes through your ticketing system, and filed the report alongside your ASV scans. Nine weeks later your QSA opens it during fieldwork and starts asking questions that were never in anyone's statement of work. Which methodology did the tester follow, and where is it documented? Which findings were exploited, and what did the tester obtain? Your CDE inventory lists fifteen in-scope hosts and the report covers eight. Where are the segmentation results with pass and fail criteria? Where is the retest confirming the critical finding was fixed?
None of those questions are about whether your security is good. They are about whether your evidence is complete. That is the shift most teams have not internalised: under PCI DSS 4.0, penetration testing stopped being an activity you perform and became an evidentiary record you produce. The test is the input. The report is what the standard is written against.
The cost of getting this wrong lands on your calendar before it lands on your budget. A rejection at fieldwork means re-testing inside a compressed window, usually with the same vendor now quoting a change order, while your acquirer's deadline stays exactly where it was. If the retest cannot land in time, the alternative is a documented gap on your ROC, which is a conversation with your acquiring bank that no IT director wants in the last week of an assessment.
Understanding why the old report format stopped working means looking at what changed in the requirement.
What Actually Changed in Requirement 11.4
PCI DSS 3.2.1 asked for a penetration test. PCI DSS 4.0, and its clarifying revision v4.0.1, asks you to prove how the test was designed, executed, verified, and closed out. Penetration testing moved from 11.3 to 11.4, and the sub-requirements became far more explicit about the artefacts you have to hand over. Here is the delta that matters.
11.4.1: A documented, industry-accepted methodology is now mandatory
This is the requirement most legacy reports fail. 11.4.1 requires a defined, documented, implemented methodology based on industry-accepted penetration testing approaches. The v4.0 guidance column points at NIST SP 800-115; the PCI SSC's Penetration Testing Guidance information supplement additionally names OWASP, PTES, and OSSTMM. Any of the four is defensible. The methodology itself has to cover the entire CDE perimeter and critical systems, test from both inside and outside the network, validate any segmentation and scope-reduction controls, include application-layer testing covering at minimum the vulnerability classes listed in Requirement 6.2.4, include network-layer testing across the components that support network functions as well as operating systems, incorporate a review of threats and vulnerabilities experienced in the previous twelve months, and define a documented approach to assessing the risk posed by exploitable vulnerabilities. Results and remediation activities must be retained for at least twelve months.
Under 3.2.1 you could satisfy an assessor by asserting a methodology existed. Under 4.0 the methodology is an artefact your QSA reads.
11.4.2 and 11.4.3: Internal and external testing, with real coverage
11.4.2 covers internal testing and 11.4.3 external, both at least once every twelve months and after any significant infrastructure or application change. The cadence is not the change. The coverage expectation is. Because 11.4.1 demands coverage of the entire CDE perimeter and critical systems, testing a convenient sample and extrapolating no longer satisfies a careful assessor. For a decision framework on how to set your overall testing cadence, see Penetration Testing Frequency: Continuous vs Annual.
One point worth getting right, because it is commonly muddled: the authenticated-testing mandate in v4.0 sits in 11.3.1.2, and it applies to internal vulnerability scanning, not to the 11.4 penetration test. 11.4.2 does not require credentialed testing in those words. What it requires is coverage of the CDE perimeter and critical systems per your own documented methodology, and in practice most methodologies reach that bar by testing from an authenticated or assumed-breach position, because an unauthenticated internal sweep says little about what an attacker who has already phished one workstation can reach. Cite 11.3.1.2 for the scanning obligation and your methodology for the pentest posture, and do not attribute either to the other in front of a QSA.
External testing needs the full internet-facing footprint, including the TLS configuration of every in-scope endpoint, not just the primary payment domain.
11.4.4: Fixed, then verified by retest
11.4.4 states that exploitable vulnerabilities found during penetration testing are corrected in accordance with the entity's risk assessment, and that the penetration testing is repeated to verify the corrections. That final clause does enormous work. A ticket marked "closed" is not verification. A vendor's word is not verification. Verification is a documented repeat test showing the finding no longer reproduces. SOC 2 assessors have moved the same direction, a pattern we cover in our guide to SOC 2 penetration testing requirements.
11.4.5 and 11.4.6: Segmentation validation on a clock
If you use segmentation to isolate the CDE, 11.4.5 requires penetration testing of those segmentation controls at least once every twelve months and after any change to segmentation controls or methods. The test has to cover all segmentation controls and methods in use, and confirm they are operational and effective at isolating every out-of-scope system from the CDE. 11.4.6 is the service provider variant: PCI DSS 4.0.1 segmentation testing every six months, plus after any change. Merchants have an annual floor. Service providers, even small ones, have a six-month floor, and QSAs check the dates.
11.4.7: If you are a multi-tenant service provider
Often missed because it sits at the end of the section. 11.4.7 requires multi-tenant service providers to support their customers' external penetration testing under 11.4.3 and 11.4.4. In practice that means either permitting the tenant to test their own instance or performing the testing yourself and providing the results, redacted where necessary to protect other tenants. This was one of the future-dated items and has been mandatory since 31 March 2025. If you run a SaaS or hosting platform that sits inside a customer's CDE, expect this request in writing, and expect your own customers' QSAs to read your answer.
Tester independence
11.4.2, 11.4.3, and 11.4.5 each require organisational independence of the tester, and 11.4.6 inherits it for service provider segmentation testing. This is widely misread as "must be external". It is not. An internal resource can perform the test provided they do not manage, configure, or own the environment under test. Your network engineer cannot pentest the network they administer. A dedicated security function reporting outside the infrastructure team generally can. The standard asks for a qualified internal resource or qualified external third party, and it deliberately does not name a certification. The tester is not required to be a QSA or ASV, and no specific credential is mandated. Independence and qualification are two separate tests, and a certificate satisfies neither on its own: a highly certified tester who administers the environment still fails the independence bar.
What a QSA actually scrutinises is not the tester's employer but the evidence of separation: reporting lines, who holds change authority over the tested systems, and whose name is on the sign-off. If you can document that cleanly, an internal test stands up. If your security and infrastructure functions are the same three people, it does not, and the argument is easier to buy than to staff.
Cadence is where merchants and service providers diverge most sharply, so it is worth seeing the two obligations side by side.
That is what the standard says. What follows is what QSAs actually do with it.
The Six Reasons QSAs Reject Pentest Reports
Across QSA commentary and published PCI pentesting guidance, rejections cluster into six recurring patterns. Each maps to a specific sub-requirement, and each is fixable at scoping time for a fraction of what it costs at fieldwork.
Why does a PCI pentest report need a named methodology?
What it fails: 11.4.1, directly. The methodology must be documented and based on an industry-accepted approach.
What should have been there: a methodology section naming the framework (NIST SP 800-115, PTES, OWASP Testing Guide, or OSSTMM), mapping each testing phase to it, and stating how the twelve-month threat review informed target selection. One page, written once, reusable every year. The cheapest rejection to prevent and the most common one to hit.
What counts as proof of exploitation in a pentest finding?
What it fails: 11.4.1 and 11.4.4. Both are written around exploitable vulnerabilities, which presumes an attempt was made to determine exploitability.
What should have been there: the actual request sent, the actual response received, a timestamp, and a plain statement of what was obtained. "Path traversal confirmed, retrieved /etc/passwd, no cardholder data accessible from this host" is a finding. A version banner cross-referenced against a CVE lookup is a scan result, and Requirement 11.3 already covers scanning. If your 11.4 evidence looks identical to your 11.3 evidence, you have not satisfied 11.4.
What happens if pentest scope doesn't match the CDE inventory?
What it fails: 11.4.1's coverage requirement, and it tends to cascade into scope questions across the whole assessment.
What should have been there: a scope statement enumerating every in-scope asset, reconciled line by line against the CDE inventory, with a documented reason for each exclusion (decommissioned, isolated by segmentation, tested under a separate engagement). Most mismatches are not negligence, they are discovery failures: assets that came online after the diagram was drawn. Running subdomain enumeration and a security header sweep across your own footprint before scoping surfaces the hosts your inventory forgot, which beats having your QSA find them.
Does every PCI pentest finding need a CVSS score?
What it fails: 11.4.1's requirement for a documented approach to assessing risk, read with 6.3.1's requirement to rank vulnerabilities. PCI DSS does not literally mandate CVSS in 11.4, which is why this trips people up, but your risk ranking needs a defensible, consistent basis and CVSS v3.1 is what assessors are used to reading.
What should have been there: a base score and full vector string on every finding, applied consistently, with any deviation (an environmental adjustment for a compensating control, say) documented and justified.
A note on versions, since CVSS v4.0 has been published since late 2023. PCI DSS does not mandate either version for 11.4, and both are defensible. v3.1 remains the version most QSAs read fluently and the one the ASV programme is built around, which is why it is still the safer default for a PCI deliverable. What is not defensible is mixing them: a report carrying v3.1 vectors on some findings and v4.0 on others, or a severity label that does not match its own vector, invites exactly the consistency challenge this rejection is about. Pick one version, state it, apply it everywhere.
How should PCI segmentation testing be evidenced?
What it fails: 11.4.5, or 11.4.6 if you are a service provider.
What should have been there: an explicit test matrix. Source segment, destination segment, protocol and port, expected result, observed result, pass or fail. Segmentation testing is a binary claim about isolation, and a binary claim needs binary evidence. "Reviewed and found effective" is an opinion. A table showing 47 attempted connections from the corporate VLAN into the CDE with 47 blocked is proof.
One caveat on that proof, because QSAs apply it: 11.4.5 asks you to cover all segmentation controls and methods in use, and to isolate all out-of-scope systems from the CDE. A clean matrix from a single source VLAN evidences that one path. If you have guest wireless, a VPN concentrator, a management network, and a third-party site-to-site tunnel, each is its own source segment and each needs its own rows. Testing the easiest boundary and describing the result as "segmentation validated" is the version of this failure that survives internal review and dies at fieldwork.
What retest evidence does a QSA expect after remediation?
What it fails: 11.4.4, squarely.
What should have been there: a dated retest section covering every critical and high finding, showing the specific test performed and the result. For anything not remediated, formal risk acceptance signed by someone with authority to accept it, referencing your 6.3.1 risk assessment. Retest is also where independence resurfaces: a retest run by the team that did the remediation carries the same conflict we examined in the context of compliance platforms testing their own customers.
Six failure modes, one underlying cause: the report was written to describe work rather than to evidence compliance. Here is the alternative.
See what your external surface exposes, mapped to the controls it touches.
Run a free External Security Check →Anatomy of an Audit-Ready PCI Pentest Report
An audit-ready PCI DSS 11.4 pentest report has eight sections. If your vendor's template is missing any of them, you are buying a rejection with a delay attached.
You can check most of this in about ten minutes against a report you already have.
The Pre-Submission Checklist
Run this against your existing report before it goes anywhere near your QSA. Every item is a yes or a no. Any no is a conversation to have with your vendor now rather than during fieldwork.
The first item on that list is the one you cannot verify from the report alone. Reconciling the target table against your CDE inventory only catches the assets you already know about, and scope mismatches are usually hosts that came online after the network diagram was drawn.
If you scored twenty-one out of twenty-one, you are in good shape. If you did not, the more useful question is how to avoid buying the same gaps again next year.
What to Ask a Vendor Before You Sign
Every checklist item above converts into a procurement question. Ask these before the SOW is signed, when you still have leverage, rather than after rejection, when you have none.
Is retest included in the base price, or billed separately? The single biggest hidden cost in PCI pentesting. 11.4.4 requires it, so you will buy it either way. The only question is whether you buy it at contract rates now or at change-order rates in week nine.
Is the methodology named in the statement of work? If the SOW says "industry-standard methodology" without naming one, you have no contractual basis to demand a methodology section in the report.
Does every finding carry a CVSS v3.1 base score and vector? Ask for a sample report and check whether scoring is consistent across findings.
Are findings mapped to PCI DSS requirements? Many vendors treat this as a compliance add-on rather than standard output.
Who signs the report, and are they independent of our environment? Get the answer in writing. If your MSP built and manages your network and also proposes to test it, that is an independence problem regardless of how good their testers are.
What is your evidence retention and re-issue policy? If your QSA asks a clarifying question in month eleven, can the vendor produce the raw evidence and re-issue a corrected report, and at what cost?
Watch what sits in base scope versus what arrives as an upsell after rejection. The left column below is what almost every SOW already covers. The right column is what tends to appear as a change order once the QSA sends the report back, and every item on it is something 11.4 requires.
- Methodology documentation
- CVSS scoring on findings
- Scope statement
- Executive summary
- Findings report
- Retest after remediation
- PCI requirement mapping per finding
- Attestation and sign-off letter
- Segmentation validation testing
- Evidence retention and report re-issue
Those four surprise line items (retest, requirement mapping, attestation, and segmentation validation) are precisely what 11.4 requires, which is why rejection triggers the upsell. Priced together at signing, they are a normal engagement. Priced separately under deadline pressure, they can add half again to the bill.
For what a full engagement should cost across delivery models, we broke the numbers down in our 2026 penetration testing cost analysis, and our own pricing includes retest in every tier for exactly this reason. If you are also weighing how much of your programme can be automated, when automated pentesting is enough covers where the line sits.
How to Choose a Pentest That Survives QSA Review
Strip away vendor positioning and the selection criteria reduce to six deliverable properties, each mapped to a sub-requirement. A documented, named methodology is what 11.4.1 asks you to produce. Real captured HTTP request and response evidence, with timestamps, proof hashes, and reproduction steps, is how you evidence the exploitability expectation in 11.4.1 and 11.4.4. Consistent CVSS scoring per finding gives your risk ranking a defensible basis under 6.3.1. PCI requirement mapping lets your QSA connect findings to controls without interpretation. A dated post-remediation retest is what 11.4.4 means by repeating the test to verify corrections. A named, organisationally independent signer addresses the independence language in 11.4.2, 11.4.3, and 11.4.5.
Worth being precise about the last one, because vendors blur it: no clause of 11.4 requires a certification. It requires a qualified tester who is organisationally independent of the environment. A credential is useful evidence of the "qualified" half. It does nothing for the "independent" half, and a QSA assessing independence is looking at reporting lines and change authority, not letters after a name.
Which raises the obvious 2026 question: will a QSA accept a report where the testing was automated?
The standard does not care what generated the first draft. Requirement 11.4 specifies methodology, coverage, exploitability, verification, and independence. It does not specify tooling, and never has. QSAs have accepted reports produced with Burp Suite, Nessus, Metasploit, and custom scripts for two decades. What a QSA rejects is a report that cannot evidence what it claims, and that failure mode is tool-agnostic. A hand-written report with no methodology section and no retest gets rejected. A report with a named framework, captured request and response pairs, consistent CVSS scoring, requirement mapping, a documented retest, and a named independent signature gives your QSA what they are looking for. No vendor can promise you an assessment outcome, because the QSA assesses your environment and your evidence as a whole, not our template. What a vendor can be held to is whether the deliverable contains the artefacts the requirement names.
The risk with automation is real, but it is a different risk: output that describes vulnerabilities it never attempted to exploit. That is the proof-of-exploitation rejection in new clothes. We covered how auditors evaluate this in what auditors accept from AI-assisted pentest reports.
Two things settle it in practice. Automation handles the systematic 80% of a CDE well, which is the injection, access control, configuration, and transport security classes that reward breadth and repetition across every in-scope host rather than a sampled few. Novel business logic abuse still needs human creativity, and the report that goes to your QSA still needs a certified security professional to review the findings and put their name on the attestation. The machine buys you coverage and speed. It does not buy you the signature, and the signature is what Requirement 11.4 is written around.
Where an External Assessment Stops
Requirement 11.4 is not one purchase. It is four obligations with different vantage points, and any vendor who tells you a single external engagement closes all of them is selling you a rejection.
An external assessment, ours included, tests your internet-facing surface. That is the vantage point 11.4.3 is written from, and the retest that closes 11.4.4 for those findings follows naturally from it. It is not the vantage point for 11.4.2 or 11.4.5. Internal penetration testing has to originate inside your network, and segmentation validation has to originate inside each out-of-scope segment and attempt to reach the CDE. Neither can be performed from the public internet by anyone, which is why our platform blocks private and internal IP ranges outright rather than pretending otherwise.
So the honest map for a merchant buying external testing:
- 11.4.1 methodology covered for the external scope, and the methodology document is reusable across your other engagements.
- 11.4.3 external testing covered at the application layer and for externally observable configuration, meaning DNS and asset discovery, TLS and header posture, and the Requirement 6.2.4 vulnerability classes. Note that 11.4.1 also expects network-layer testing across the components supporting network functions and their operating systems. Confirm with any vendor, us included, whether their external engagement produces port and service enumeration evidence or stops at the application layer, because that determines whether you need a second scope.
- 11.4.4 correction and retest covered for the findings in that external scope.
- 11.4.2 internal testing not covered by an external engagement. This needs testing from inside, whether by an independent internal function or a firm you let onto the network.
- 11.4.5 and 11.4.6 segmentation validation not covered. This needs a tester positioned in each out-of-scope segment.
Plan the internal and segmentation work as separate line items with their own dates, and keep the evidence in one place so your QSA sees a complete 11.4 picture rather than a strong external report and two silences. A vendor telling you the external test alone satisfies Requirement 11.4 is the same vendor who will be quoting you a change order in week nine.
Frequently Asked Questions
What does PCI DSS 4.0 require for penetration testing?
Why do QSAs reject penetration test reports?
What must a PCI DSS 11.4 pentest report include?
How often is PCI DSS segmentation testing required?
Does PCI DSS 4.0 require retesting after remediation?
Can an internal team perform a PCI DSS penetration test?
Does a vulnerability scan satisfy Requirement 11.4?
What happens if the QSA rejects the report mid-assessment?
Sources
- PCI Security Standards Council Document Library (PCI DSS v4.0.1 and the Penetration Testing Guidance information supplement)
- NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
- Schellman: PCI DSS v4.0 Penetration Testing FAQ
- Horizon3.ai: PCI DSS v4.0 Requirement 11.4 Pentesting
- RSI Security: PCI DSS 11.4.1 Compliance Guide
PCI DSS is a registered trademark of the PCI Security Standards Council, LLC. Burp Suite, Nessus, and Metasploit are trademarks of their respective owners. These marks are used here only to identify and comment on the standards and products referred to. CyberOrbit AI Pty Ltd is not affiliated with, endorsed by, or sponsored by any of them.
This post is general information about security testing and compliance frameworks. It is not legal, audit, or compliance advice, and it is not a substitute for the current text of PCI DSS or the judgement of your own QSA. Requirement references describe PCI DSS v4.0.1 as published at the date above.