What gets a PCI penetration test report rejected

A QSA does not read your penetration test report the way you do. They run a testing procedure against it. PCI DSS v4.0.1 procedure 11.4.3.a reads: "Examine the scope of work and results from the most recent external penetration test to verify that penetration testing is performed according to all elements specified in this requirement." Procedure 11.4.2.a says the same for the internal test, 11.4.5.b for segmentation.

"All elements" is a list, and your report is the only evidence each one happened. Reports come back not for being badly written, but for leaving an element unevidenced.

The scope tested is narrower than the scope documented

Requirement 12.5.2 obliges you to document and confirm PCI DSS scope at least once every 12 months — six for service providers under 12.5.2.1, mandatory since 31 March 2025. Requirement 11.4.1 obliges the methodology to include "Coverage for the entire CDE perimeter and critical systems." The assessor has both open, and where the report's scope lists fewer hosts, applications or segments than your own scoping validation, the difference is the finding.

The version that catches competent teams is the applicability note to 11.4.1: "Testing from inside the network … means testing from both inside the CDE and into the CDE from trusted and untrusted internal networks." A test run only from a jump host inside the CDE has done half of what 11.4.2 asks — and the report usually says so plainly without realising it.

It is a vulnerability scan with a cover page

The guidance to 11.4.1 forecloses this: "Scanning for vulnerabilities alone is not a penetration test, nor is a penetration test adequate if the focus is solely on trying to exploit vulnerabilities found in a vulnerability scan." And: "Penetration testing is a highly manual process."

What an assessor notices: every finding carries a CVE and a CVSS base score and nothing else; nothing was reached by chaining two findings; no business-logic finding appears, though 6.2.4 names that class explicitly; the engagement spans a single day. Nor does the ASV scan help — Requirement 11.3.2, external scanning every three months "By a PCI SSC Approved Scanning Vendor (ASV)", is a separate obligation and evidences nothing under 11.4.

The methodology is the tester's, not yours

Requirement 11.4.1 places the methodology on the entity — "defined, documented, and implemented by the entity" — and 11.4.2 and 11.4.3 both open with "Per the entity's defined methodology". The report must be readable against your document, not the tester's internal process.

Two of its nine elements go missing more than the rest: "Review and consideration of threats and vulnerabilities experienced in the last 12 months", and a "Documented approach to assessing and addressing the risk posed by exploitable vulnerabilities … found during penetration testing." And the standard names OSSTMM and the OWASP penetration testing programmes, so "industry-accepted" is not a matter of opinion.

Findings are asserted, not demonstrated

PCI SSC's report evaluation checklist asks the question most rejected reports fail: "Did tester demonstrate attempts to exploit the identified vulnerability and clearly state the potential result/risk that each potential exploit may pose to the environment?" The findings section must show "Whether/how the CDE may be exploited using each vulnerability" — not that a weakness exists on a host, but that reaching cardholder data through it was attempted, and what happened.

The opposite failure is a clean report. The guidance to 11.4.2 is blunt: "A penetration test that found nothing is typically indicative of shortcomings of the penetration tester, rather than being a positive reflection of the security posture of the entity." Findings identified but not exploited still belong in the report, ranked by your own process under Requirement 6.3.1.

Segmentation testing is a paragraph, not a section

Requirement 11.4.5 carries three testing procedures of its own: the methodology is examined, the results are examined, and personnel are interviewed about the tester's independence. A sentence inside the internal test narrative satisfies none of them. The report needs its own segmentation section covering "all segmentation controls/methods in use" and confirming they are "operational and effective, and isolate the CDE from all out-of-scope systems" — including any isolation separating systems of differing security levels under 2.2.3.

Service providers carry 11.4.6 instead: the same test, "At least once every six months and after any changes to segmentation controls/methods." One annual report cannot evidence a six-monthly cadence, and the missing half cannot be created retrospectively.

There is no retest

Requirement 11.4.4 has two elements and the second gets missed: exploitable vulnerabilities are corrected "In accordance with the entity's assessment of the risk … as defined in Requirement 6.3.1" and "Penetration testing is repeated to verify the corrections." A change ticket marked closed, a vendor patch note, a fresh scan showing the port shut — none of those are penetration testing results, and none satisfy 11.4.4.

The retest is a short document — original findings, date of retest, results — and agreeing it in the statement of work costs nothing. Commissioning it eleven months later, after the tester's environment knowledge has gone cold, costs a second engagement.

Nothing tells the assessor which requirement each finding bears on

Requirement 11.4 does not oblige a report to cite requirement numbers. What the guidance to 11.4.4 says is that "Any weaknesses that point to PCI DSS requirements not being met should be addressed." That work happens somewhere.

TLS 1.0 answering on an internet-facing CDE service is an 11.4 finding and evidence against Requirement 4.2.1. A vendor default credential on a CDE host is evidence against 2.2.2. An unpatched component is evidence against 6.3.3. Leave the mapping implicit and the QSA does it — months later, without the tester in the room, every ambiguity resolving against you. Reports carrying the mapping get read once; the rest generate a question set that arrives after the remediation window has closed.

The date on the front page

Requirements 11.4.2 and 11.4.3 require testing "At least once every 12 months" and "After any significant infrastructure or application upgrade or change". The standard does not define "significant" — your risk assessment does. So the assessor compares your change record against your own definition, and a report predating a change you classified as significant is a gap you wrote the criterion for.

Run the Council's checklist before the assessor does

PCI SSC's Information Supplement: Penetration Testing Guidance contains a report evaluation tool "intended for entities that receive a penetration test report and need to interpret and evaluate the completeness of the report" — twenty minutes of yes/no questions against a report you have already paid for. One caveat almost nobody states: it is v1.1, September 2017, written against v3.2, and numbers penetration testing as Requirement 11.3 throughout. Under v4.0.1 — sole active version since v4.0 retired on 31 December 2024 — 11.3 is vulnerability scanning and 11.4 is penetration testing.

Every row is settled before testing begins — in the scope you agree, the methodology you hand over, and whether the retest is in the contract or a change order. Service providers have a second audience for the same document: their customers, under Requirement 11.4.7.

Security Brigade's network penetration testing is scoped and reported against Requirement 11.4, including segmentation testing under 11.4.5 and 11.4.6 and the repeat test 11.4.4 requires.