What a PCI Pentest Report Needs to Pass Your Assessment

Your assessor never sees the testing. They see the report. If the report doesn't show that the requirements in PCI DSS 11.4 were met, it doesn't matter how good the work behind it was. The finding goes in the ROC, or you end up testing again.

I write the PCI penetration test reports for our engagements at Radical Security, and I write them with the assessor as a second reader. Here's what I put in them and why.

What your assessor does with the report

When a QSA reviews a penetration test, they're answering a handful of questions for the testing procedures under 11.4:

• Was there a documented methodology, and does it cover what 11.4.1 requires?
• Did internal and external testing happen within the last 12 months and after significant changes?
• Was the tester qualified and organizationally independent?
• If segmentation is used to reduce scope, was every segmentation control tested, and did it work?
• Were exploitable findings corrected, and was the correction verified by repeating the test?

A report that makes the assessor hunt for those answers is a weak report even if the testing was excellent. Each one should be easy to find. That's also why I prefer to agree on report contents during scoping, before any testing starts.

The sections every PCI pentest report should have

The PCI Security Standards Council's Penetration Testing Guidance information supplement lays out recommended report contents, and they're a good baseline. Our reports include:

1. Executive summary. What was tested, the overall result and the findings that matter, written for people who won't read the rest.
2. Statement of scope. Every host, range, application, cloud account and segmentation boundary tested, and how each maps to the CDE and to 11.4.2, 11.4.3 and 11.4.5.
3. Methodology. The industry-accepted approach followed and how it addresses each element of 11.4.1, including application-layer testing against the 6.2.4 attack classes.
4. Limitations. Anything that constrained the test: excluded systems, testing windows, accounts that weren't provided. Hiding limitations is how reports get rejected later.
5. Testing narrative. What we did, in order, so an assessor can follow the work from reconnaissance to exploitation.
6. Segmentation test results. Each control tested, from where, against what, and the result.
7. Findings. Each with a risk rating, evidence, affected systems, business impact and specific remediation steps.
8. Tools used. What we ran and what it was used for.
9. Cleanup. Anything we created during testing, such as accounts and files, and confirmation that it was removed.
10. Tester qualifications and independence. Who performed the work, their credentials, and a statement of organizational independence.

Segmentation results need their own section

If you rely on segmentation to keep systems out of scope, the segmentation results are often the first thing an assessor checks, because a segmentation failure changes the scope of the whole assessment. A single line saying "segmentation was found to be effective" isn't enough.

Our segmentation section lists every out-of-scope network segment we tested from, every segmentation control between it and the CDE, the methods used and the result for each pair. I walk through how we do that testing in PCI segmentation testing in practice. For the requirement itself, see what Requirement 11.4.5 actually requires.

Findings your team can act on

Requirement 11.4.4 says exploitable vulnerabilities and security weaknesses must be corrected in line with your own risk assessment under Requirement 6.3.1. That means findings have to give you enough to make that assessment. For every finding, we include:

• A clear title and risk rating, with the reasoning behind the rating rather than just a CVSS number.
• Evidence: requests, responses, screenshots or command output that let your team reproduce the issue.
• The affected systems, mapped back to the scope.
• What an attacker could actually do with it, in terms of cardholder data and the CDE.
• Specific remediation steps, not "apply vendor patches" boilerplate.

We share critical findings as soon as we confirm them rather than holding them for the final report. If something is exposing cardholder data, you shouldn't learn about it two weeks later in a PDF.

Retest evidence

The part of 11.4.4 that catches people out is the second half: the penetration testing has to be repeated to verify the corrections. A report full of findings with no evidence they were fixed and retested is incomplete for assessment purposes.

Our retests are included in the engagement price. After you remediate, we retest each finding and issue a retest report that lists every original finding, what we tested again and the result. Together with the original report, that gives your assessor the full story from finding to verified fix. Keep both for at least 12 months, as 11.4.1 requires.

Common gaps I see in other reports

When clients bring me a previous report to review before their next assessment, these are the problems I see most often:

• Scanner output presented as a penetration test. Requirement 11.3 scans and 11.4 penetration tests are different requirements with different evidence.
• No application-layer testing, or application testing that doesn't address the 6.2.4 attack classes.
• Missing segmentation results, or results that don't cover every segmentation control in use.
• No statement of scope mapping tested systems to the CDE, so the assessor can't tell whether coverage was complete.
• No retest, or a retest that only covers critical findings when other exploitable issues were also reported.
• No statement of independence for testers who also administer the environment.

Every one of those is a scoping or documentation problem, which is why we fix them before testing starts by agreeing on report contents in writing.

What you can expect from us

At Radical Security, the report contents are part of the written scope, so you know what you'll receive before we start. We never ask for money up front, and you pay only once the work is complete. If the report doesn't meet what we agreed, our 100% money-back guarantee means you choose whether we fix it at no cost or refund every dollar. You can see the whole process in what a Radical Security PCI engagement looks like.

Key takeaways

• Write the report for two readers: your team, and the assessor checking 11.4.
• Include scope, methodology, limitations, narrative, segmentation results, findings, tools, cleanup and tester independence.
• Give segmentation results their own section, covering every control in use.
• Findings need evidence, impact and specific remediation so you can risk-rank them under 6.3.1.
• Retest every exploitable finding and keep both reports for at least 12 months.