What a Good Penetration Test Report Looks Like (and How to Spot a Weak One)

7

A penetration test report is the single deliverable that justifies the cost of an engagement. The testing is the means; the report is the point. Yet many organisations receive documents they cannot act on. The report was written for the wrong audience, lacks real evidence, or buries its most important findings behind technical prose. Knowing what a good penetration test report looks like helps you choose the right firm and reject a weak one.

The Executive Summary Should Do the Heavy Lifting

The first test of any pen test report is the executive summary. Hand it to a senior manager with no security background. If they can read it in ten minutes and understand what was tested, how serious the findings are, and what needs to happen next, the report is doing its job. If they cannot, it is not.

A well-written executive summary covers the scope in plain terms. It gives an overall risk rating and lists the number of Critical, High, Medium and Low findings. The most significant issues are described in business language, not CVE identifiers, with a short list of clear priorities. Furthermore, a strong summary acknowledges what is working alongside the gaps. Security is not entirely broken or entirely sound, and the executive summary should reflect that.

Research by JUMPSEC found that around 42% of small and medium-sized businesses receiving unclear or overly technical reports fail to fix critical issues within six months. So an unreadable executive summary is not a minor presentation problem. It is a reason findings go unaddressed.

The Scope Section Is Your Verification Checkpoint

Before reading further, check the scope section against what you agreed at the outset. It should name every system, IP range, application or environment in scope. Exclusions matter equally: if something you expected to be tested is not listed, the penetration test report cannot tell you whether it is safe.

The methodology section describes how testing was conducted: which phases were included, which framework guided the work, and any agreed constraints. UK firms commonly reference OWASP for web application assessments and the NCSC CHECK scheme for government-connected work. The Penetration Testing Execution Standard covers broader network assessments. Together these sections give you evidence that testing followed a structured, professional approach rather than a single scan with a commercial tool.

What a Good Penetration Test Report Contains: Findings

Indeed, the findings section is where reports most commonly fall short. Each entry needs five things to be useful: a clear title, a severity rating that reflects business context, a description specific to your environment, supporting evidence, and a concrete remediation recommendation.

Severity Must Reflect Context, Not Just Technical Score

Most firms assign each finding a severity label (Critical, High, Medium, Low or Informational) and a CVSS score. CVSS is a scoring system running from 0 to 10. Specifically, it measures technical severity based on how easily the vulnerability can be exploited and what a successful attack could reach.

But the written severity label should adjust for business context, which CVSS alone does not capture. A technically Critical score on a development server with no production access might reasonably be rated High in context. A Medium CVSS score on a flaw that bypasses authentication to your customer database belongs at Critical. If every finding in a report has a CVSS score but no contextual adjustment, the firm has not done the harder work of translating technical findings into business risk.

Evidence Is the Difference Between a Real Test and a Scanner Run

Each finding should include real evidence from your environment: screenshots, annotated command outputs, or HTTP request-and-response logs showing the vulnerability in action. Without evidence, you cannot verify the finding is real, reproduce it, or confirm that it is fixed after remediation.

Findings that read like database entries, with your company name inserted at the top, are a sign that the report was produced from automated scanner output rather than active testing. Scanners flag potential weaknesses based on version numbers and signatures. Testers demonstrate that a vulnerability is exploitable in your specific configuration. The evidence in each finding is how you tell which of those things occurred.

Remediation Must Be Specific

Generic remediation advice is useless. “Patch the affected software” tells your team nothing that the description did not already imply. Instead, useful remediation guidance names the specific patch, describes the configuration change required, or sets out the code pattern to correct. Where several fix options exist, a strong report presents them in priority order and explains the trade-offs.

Context on effort matters too. A Critical finding resolved by changing a single configuration value is a different problem from one that requires rewriting an authentication flow. Both should be addressed, but the remediation plan should reflect the difference.

What a Weak Penetration Test Report Looks Like

A report produced from automated tools rather than active testing is the most common quality problem. The findings describe vulnerability classes in generic terms. The evidence section is absent or, at best, consists of scanner screenshots with no human analysis. Remediation advice reads as if copied from a knowledge base. And the executive summary repeats the technical findings without translation.

However, length is not a proxy for quality. A hundred-page report can be almost entirely worthless if the pages consist of scanner output and appendix data. A twenty-page report covering a focused scope, with evidenced findings and specific remediation guidance, is worth far more.

Supporting Material and Appendices

Appendices support the findings but are not the main event. They typically include full tool outputs, raw scan data and network diagrams. Some firms also provide an attestation letter confirming that a test took place on specified systems between specific dates. This is useful for compliance, audits and insurance renewals: it documents that testing occurred without sharing the full vulnerability detail with third parties.

A CSV export of findings is a practical addition. It lets your team import findings directly into a vulnerability management or ticketing system. That way, there is no manual transcription and no risk of a finding being missed.

How to Act on Your Penetration Test Report

Once you have verified the scope matches what was agreed, share the executive summary with senior management and the full findings with your technical and security team. Then assign a named owner to each finding. Set remediation deadlines, treating Criticals as immediate. Restrict access to the full report: it maps your exposure in detail.

Once remediation is complete, request a retest on the specific findings. A retest confirms that fixes are effective and that no secondary issues were introduced. For Critical and High findings, skipping the retest to save cost is a false economy.

At Aardwolf Security, every report we produce is written to be understood by both your technical team and your senior management. If you want to understand what a penetration test on your infrastructure or applications would actually involve, you can find details on our penetration testing services page, or get in touch to talk through scope and timing.

Frequently Asked Questions

How many pages should a pen test report be?

Length depends on scope. A focused web application test typically produces 20 to 40 pages. A full internal and external assessment of a large environment can run to well over a hundred pages. Length should reflect the work, not be treated as a quality indicator in itself.

What is the difference between a penetration test report and a vulnerability scan report?

A vulnerability scan report is automated tool output. It flags potential weaknesses based on version numbers and known signatures. A penetration test report documents what a trained tester actually demonstrated in your environment, with evidence. The two are not equivalent.

Who in my organisation should see the full report?

The executive summary should reach senior management and the board. The full technical report should go to your security team and the IT staff responsible for remediation. Treat it as sensitive documentation. Its contents map how your organisation can be compromised.

What should I do if I disagree with a finding’s severity?

First, raise it with the testing firm before accepting the final report. Disputes about severity are legitimate, particularly where business context changes the risk picture. A professional firm will review the finding and either stand by it with evidence or revise it if the context warrants. These conversations should happen before you sign off.

What is a retest and should I include one?

A retest is a follow-up check in which the tester confirms that each remediated finding is genuinely fixed. It is often not included in the initial cost and should be agreed during scoping. For Critical and High findings, a retest is worth including. Without it, you are relying on your own judgment that the fix worked.