PCI DSS Penetration Testing Report: What QSAs Actually Want to See in 2026
Most pentest reports I've seen submitted for PCI DSS audits get kicked back. Not because the testing was bad — but because the report read like a CVE dump with a logo slapped on it.
PCI DSS 4.0 changed the documentation requirements significantly. QSAs now have a higher bar, and if you've ever had a report rejected or sent back for “clarification,” this is probably why.
Here's what actually needs to be in your PCI DSS pentest report.
Why PCI DSS Pentest Reports Keep Getting Rejected
The most common rejection reason is simple: the report lists vulnerabilities without proving they were exploitable.
PCI DSS Requirement 11.4 doesn't just ask you to find weaknesses. It asks you to demonstrate that your security controls can withstand a real attack. A Nessus scan export renamed to “pentest_report.pdf” doesn't do that.
The other common failure is missing retest evidence. Under PCI DSS 4.0, you must show that every finding was fixed and verified. A report that ends at “here are the vulnerabilities” is automatically incomplete.
When You Actually Need One
Annual testing is mandatory — but that's the minimum. You need a new pentest report after any significant infrastructure change. New payment app? New pentest. Migrated to cloud? New pentest. Changed your network segmentation? You need a report proving the CDE is still isolated.
Service providers who rely on segmentation to reduce their PCI scope have it stricter: every 6 months.
What the Report Must Include
Scope and methodology
Define every system in the Cardholder Data Environment you tested, the boundaries you were working within (external, internal, segmentation), and the methodology you used — OWASP, PTES, or OSSTMM. Vague scope sections get flagged immediately.
Test narrative
Not just a list of what you found — a walkthrough of what you did. What attack paths did you explore? What did you try that didn't work? QSAs want to see that actual testing happened, not just a tool scan.
Findings with CVSS 3.1 scores
Each vulnerability needs a severity score, a plain-English description, and proof it was exploited or exploitable. Screenshots, command outputs, traffic captures. No proof, no finding.
Business impact
Not just “this is a critical RCE.” Explain what an attacker could actually do with it in the context of this specific cardholder environment. This is what matters to the QSA and the client.
Remediation steps
Specific, actionable fixes — not “patch the system.” Include the exact CVE, the fix version, the configuration change, or the architectural recommendation.
Retest results
This is mandatory under PCI DSS 4.0 and the most commonly missing section. For every finding, you need evidence it was remediated and verified. A separate retest section or an updated finding status with proof.
Segmentation validation
If your client uses network segmentation to reduce PCI scope, you must test and document that the CDE cannot be reached from out-of-scope systems. This has its own requirement (11.4.5) and needs its own section.
Executive summary
One page. Non-technical. Explains what was tested, what was found at a high level, and what the business risk is. The person signing off on remediation budget needs to read this and understand it without a security background.
The Types of Testing PCI Requires
External network testing covers your perimeter — public-facing systems, internet-exposed services, anything an attacker could reach without being on your network first.
Internal testing covers lateral movement. Can an attacker who's already inside reach cardholder data? This is often where the real findings are.
Application testing covers your payment apps and APIs. Logic flaws, authentication bypasses, injection vulnerabilities. If you process payments through a web app, this section is non-negotiable.
Segmentation testing is its own category. You're not looking for vulnerabilities here — you're proving that your network isolation actually holds.
How Long It Takes to Write One of These
An experienced pentester doing this manually spends 3 to 6 hours on report writing alone for a mid-size PCI engagement. Formatting findings, calculating CVSS scores, writing the executive summary, structuring the remediation table, going back to add retest evidence.
That time adds up fast, especially when you're running multiple concurrent engagements.
PentestReportAI handles the entire report generation locally on your machine. Paste in your findings, tool outputs, and screenshots. The AI parses, classifies, scores, and composes a structured report — with a dedicated compliance template built specifically for PCI DSS, SOC 2, and ISO 27001 audits.
Your client's data never touches a cloud server
For PCI engagements where the data in question is cardholder data, that's not a small thing. PentestReportAI's desktop app processes everything locally on your machine.
Before You Submit to Your QSA
Run through this before you hand over the report:
If any of those are missing, the report is coming back.
Written for pentesters conducting PCI DSS assessments under Requirement 11.4. Always align your scope and methodology with your client's QSA before testing begins.