What Auditors Want to See in a Penetration Test Report

When a penetration test report lands, most people go straight to the findings. How many criticals are there? How bad is the worst one? An auditor reads the same report very differently. They’re less interested in the number of vulnerabilities and much more interested in two things: if it was the right test, carried out by the right people, and what was done about the findings.

This guide takes the compliance angle on penetration testing reporting. It covers which sections of a report an ISO 27001, PCI DSS, or SOC 2 auditor is likely to read closely, what each of them is looking for, and why the remediation and retest record can matter just as much as the findings themselves. If you’re more interested in how to think about your results, our post “Did We Pass?” covers the mindset side.

Why Auditors Read Pen Test Reports Differently

An auditor isn’t there to assess your security directly, and their job is to decide if you have effective controls and can prove it. A penetration test report is one of the most important pieces of evidence they’ll see because it provides an independent view of how well your controls work.

That changes what matters because a report with no findings and a vague scope is weak evidence, because it doesn’t show that anything meaningful was tested. A report with several high-risk findings, a clear scope and a record showing each one was fixed and retested is strong evidence, because it shows a working process for finding and fixing problems. Interestingly, the second report often goes down better with an auditor than the first; however, a report with no major findings and a clear, thorough scope is also absolutely fine, because the methodology is sound.

Penetration Testing Reporting: The Sections Auditors Actually Read

The PCI Security Standards Council’s Penetration Testing Guidance suggests a report outline that has become a useful reference point well beyond PCI DSS. It includes an executive summary, statements of scope, methodology and limitations, a testing narrative, findings, the tools used and how the environment was cleaned up afterwards. In our experience, these are the parts auditors pay most attention to.

Scope and dates

This is usually the first thing an auditor checks. They want to know exactly which systems, applications, IP ranges and environments were tested, when the testing took place, and what was excluded. They’ll compare that scope against what they’re auditing, such as your ISO 27001 scope, your PCI DSS cardholder data environment or your SOC 2 system description. If a key system is missing, or the test dates fall outside the period being audited, the report may not count as evidence at all.

Methodology

Auditors want to see that the test followed a recognised, documented approach, not an ad hoc one. For PCI DSS, this is an explicit requirement. For ISO 27001 and SOC 2, it’s a strong indicator that the test was thorough and repeatable. A methodology section should explain how the testing was carried out and which standards it followed, such as the OWASP testing guides for web applications.

Limitations

A good report is honest about what it couldn’t do. Time constraints, systems that were unavailable, accounts that weren’t provided or areas the client asked the testers to avoid should all be stated clearly. Notably, auditors tend to trust a report more when it acknowledges its limits, because it shows the scope hasn’t been overstated.

Tester independence and qualifications

Most frameworks expect testing to be carried out by someone independent of the systems being tested, and auditors increasingly look at who did the work. A report that names the testing company and confirms the testers’ qualifications, such as CREST certifications, makes this easy to verify. Choosing a provider offering CREST-accredited penetration testing removes most of the doubt.

The findings, and especially the high-risk ones

Auditors do read the findings, but they rarely work through every low-risk issue. They focus on the critical and high-risk findings, and for each one they want to understand the risk rating and how it was decided, which systems were affected, and if the vulnerability was actually exploited or only identified. A consistent scoring system, such as CVSS, helps an auditor compare findings across reports and years.

The executive summary

The executive summary matters more to your board than to your auditor, but auditors often use it to gauge the overall picture before they dig into the detail. It should give a clear, plain-English view of the risk, not just a count of findings by severity.

What Each Framework Is Looking For

The core sections above apply everywhere, but each framework has its own priorities.

PCI DSS

PCI DSS is the most prescriptive because, under Requirement 11.4 of version 4.0.1, which you can find in the PCI SSC document library, a QSA will expect to see a documented, industry-accepted methodology, internal and external testing at least every 12 months and after significant changes, evidence that exploitable vulnerabilities were corrected and retested, and segmentation testing results where segmentation is used to reduce scope. The methodology must also include retaining penetration testing results and remediation activity results for at least 12 months. We cover each sub-requirement in our guide to PCI DSS penetration testing.

ISO 27001

ISO 27001 doesn’t prescribe a report format, so an auditor will look at how the penetration test fits into your information security management system. They’ll want to see the report linked to Annex A controls such as 8.8, management of technical vulnerabilities, and they’ll often check that significant findings appear in your risk register or risk treatment plan. If a finding reflects a control that isn’t working, they may also expect to see it handled through your corrective action process.

SOC 2

For a SOC 2 Type II report, timing is critical, because the test needs to fall within the audit’s observation period to show that your controls were operating during it. The auditor will also check that the scope matches your SOC 2 system description and will usually want to see management’s response to each finding, such as remediation tickets, evidence of fixes, retest results or documented risk acceptance. Our guide “Does SOC 2 require penetration testing?” covers this in more detail.

Why the Remediation and Retest Record Matters as Much as the Findings

Perhaps the most common mistake we see is treating the report as the end of the process. To an auditor, the report is only half of the evidence. The other half is what you did next.

A remediation record shows how each finding was handled. For most findings, that means a fix, but it can also mean a compensating control or a formally documented decision to accept the risk, with a reason and an owner. If you can’t fix everything straight away, that’s normal, and our guide on what to do if you can’t fix everything explains how to prioritise and document what’s left.

A retest record then proves that the fixes actually worked. Without it, an auditor only has your word that a critical vulnerability was closed. PCI DSS requires retesting of corrected exploitable vulnerabilities, and ISO 27001 and SOC 2 auditors will usually expect it for anything rated high or critical. We explain why it matters in our post on retesting after fixing vulnerabilities.

The same record matters outside formal audits too. Cyber insurers, for example, increasingly ask whether you’ve implemented the high and critical recommendations from your most recent test, and a retest report is the simplest way to show that you have.

Common Report Problems That Cause Audit Issues

A few problems come up again and again, and most of them are easy to avoid if you know about them before the test starts:

• A scope or timing that doesn’t match the audit: Agree the scope with your auditor’s requirements in mind, so the test covers the same systems the audit does, and make sure it falls within the right period. Timing matters most for SOC 2 Type II, but PCI DSS and ISO 27001 auditors will also question a report that’s well over a year old.
• Scanner output presented as a penetration test: Auditors can usually tell the difference between an automated scan and a genuine manual test, and many won’t accept the former. Our guide to automated vs manual penetration testing explains why.
• Open high-risk findings with no explanation: A critical issue left unresolved without a plan or a risk acceptance raises questions about your whole control environment.
• The same report every year: If your scope hasn’t changed in years, an auditor may wonder if you’re testing the same things every year while new systems go untested, which is a common route into the Pentest Trap.

Getting the Report Right Before the Test Starts

Most of what makes a report audit-ready is decided before any testing begins. A cyber security risk assessment helps you agree a scope that reflects your real risks and your compliance obligations, and telling your provider which frameworks you need the report for means they can structure it accordingly. It also helps to plan time for remediation and retesting before your audit date, so you’re presenting a closed-out record instead of a list of open issues.

For a wider view of how different frameworks approach penetration testing, see our guide to which compliance standards require penetration testing.

Audit-Ready Reporting with Fortifi

Fortifi is a CREST-accredited penetration testing company, and our UK penetration testing services are designed to produce reports that stand up to scrutiny from auditors, insurers and customers. Every report includes a clear scope and methodology, plain-English findings with practical remediation guidance, and retesting to confirm that fixes have worked.

Because we don’t do sales calls, you’ll speak directly to a cyber security expert who can help you scope a test around your audit requirements and time it to fit your audit calendar. Book a call with our team today.

Penetration Test Report FAQs

What should a penetration test report include?

A good penetration test report should include an executive summary, a clear statement of scope and testing dates, the methodology used, any limitations, detailed findings with risk ratings and evidence, and practical remediation guidance. For compliance purposes, it should be followed by a retest report confirming which findings have been fixed.

Do auditors need to see the full penetration test report?

Usually, yes. Auditors generally want to see the full report, or at least the scope, methodology, findings and remediation status, so they can judge if the test counts as valid evidence. A short summary or attestation letter is more often used for sharing with customers, who typically don’t need the technical detail.

How long should we keep penetration test reports?

PCI DSS requires penetration testing results and remediation results to be retained for at least 12 months. For ISO 27001 and SOC 2, it’s sensible to keep reports for at least as long as your audit cycle requires, and many organisations keep several years of reports to show how their security has improved over time.

Will an auditor fail us for having findings in our report?

Not usually. Auditors expect penetration tests to find things. What matters is how you responded, so a report with findings that have been fixed, retested or formally risk-accepted is far stronger evidence than one with unexplained open issues.