Penetration Test Report: What It Contains and How to Read It

A penetration testing report is the written record of a security test: what was tested, what the tester found, how serious each finding is, and exactly how to fix it. A good one answers three questions for leadership on the first page (how exposed are we, what must we fix first, and what will it take) and gives engineers enough evidence to reproduce and fix every issue.

Whether you are reading your first report or comparing providers’ pentest reporting, this guide explains what each section should contain, gives a penetration test report template you can check any report against, shows an example of a well-written finding, and sets out how to turn the results into action.

Key takeaways

• Read the scope first: a report only tells you about what was tested.
• The executive summary should give overall risk and themes in plain English.
• CVSS scores measure technical severity; business risk also depends on exposure and data.
• Every finding needs an owner, a deadline and a retest.
• Findings that recur year after year point to a process problem.

What does a penetration testing report contain?

Most professional reports follow the same structure. If yours is missing a section, ask the provider why.

Penetration test report template

Good pentest reporting follows a predictable order, so a reader can find the same information in every report. Copy this outline into your statement of work so the provider knows what you expect, or check a report you have received against it. The sections, in order:

1. Document control
   • Report title, version, testing dates and issue date
   • Author, reviewer, distribution list and classification
2. Executive summary
   • Overall risk and the two or three most serious attack paths, in plain English
   • Recurring themes and controls that worked
   • Prioritised recommendations
3. Scope and methodology
   • Targets in scope and out of scope
   • Approach (black, grey or white box) and test accounts used
   • Testing windows, constraints and the methodology followed, such as the OWASP Web Security Testing Guide for web applications
4. Summary of findings
   • One table: reference, title, risk rating, affected asset and status
5. Detailed findings, one entry per issue
   • Reference, title, risk rating, affected asset, description, evidence, business impact, remediation and retest status
6. Appendices
   • Hosts, URLs and endpoints tested
   • Tool output and supporting evidence
7. Retest record
   • The status of each finding after remediation, usually a short letter or an updated report

An illustrative summary of findings table looks like this:

If a report you receive does not let you build this table in a few minutes, ask the provider to add one.

Why should you read the scope first?

Because anything out of scope is untested, not secure. A clean report on a narrow scope can create false confidence. Check:

• Targets. Which IP ranges, applications, APIs or environments were included, and which were excluded?
• Approach. Black box (no prior knowledge), grey box (some information and test accounts) or white box (full documentation)? Grey and white box usually give deeper coverage.
• Environment and timing. Was testing done in production or a staging copy? Has anything changed significantly since?
• Constraints. Were any techniques excluded, or was testing cut short in a way that limited coverage?

What should the executive summary tell you?

It should tell you, without jargon, whether a skilled attacker could achieve meaningful access and what to do about it. Look for:

• An overall view of your security posture.
• The most significant attack paths, told as a short story. For example: “An attacker could use a weak password on the remote access portal, combined with an unpatched internal server, to reach the customer database.”
• Common themes, such as patching delays or inconsistent access control.
• Positive findings: controls that worked and should be maintained.
• Clear, prioritised recommendations.

If you cannot understand the executive summary, that is a failing of the report, not of the reader.

Look at themes as well as counts. Ten medium findings caused by missing patches point to a broken patching process. One critical finding caused by a coding mistake points to a gap in secure development. Fixing the cause stops the same issues appearing in next year’s report.

Pentest report example: a well-written finding

Every finding should give your team enough to understand, reproduce and fix it. This penetration test report example shows an illustrative finding from a web application test (WEB-03 from the summary table above), in the format a good report uses.

Notice what makes it useful: it is specific, it uses test accounts rather than real customer data, it explains the business impact, and it says what to fix and where else to look. “Follow best practice” is not a remediation.

How should you read the risk ratings?

CVSS

Most reports use the Common Vulnerability Scoring System (CVSS), which rates technical severity from 0.0 to 10.0. Version 3.1 is still widely used and version 4.0 is increasingly common. Scores are usually banded as low, medium, high and critical. CVSS is a consistent starting point, but it describes the vulnerability in general, not your business.

Contextual risk

A good tester adjusts ratings for your environment and explains why. Two questions matter most:

• How exposed is the asset? A flaw on an internet-facing payment page is more urgent than the same flaw on an isolated test server.
• What would an attacker gain? Access to customer data, payment systems or administrative control outweighs access to a brochure site.

Findings marked “potential” or “unconfirmed” should still be investigated, but they deserve less urgency than confirmed, evidenced issues.

How do you turn findings into an action plan?

• Assign owners and deadlines. Every finding needs a named owner and a target date based on its risk, using the fix times in your vulnerability management policy.
• Fix causes, not just symptoms. If one form was vulnerable to injection, ask whether the same pattern exists elsewhere.
• Handle what cannot be fixed. Apply compensating measures, record the decision in your risk register, and have senior management formally accept any residual risk with a review date.
• Retest. A retest by the original team confirms fixes work. An automated scan is not a substitute for retesting a manually found flaw.

Our guide to penetration test remediation covers this stage in detail.

How is the report used for compliance?

• PCI DSS. Reports are key evidence for Requirement 11.4. Your assessor will check that the scope covered the whole cardholder data environment perimeter and critical systems, that the methodology meets 11.4.1, that testing happened at least every 12 months and after significant change, and that exploitable findings were fixed and retested (11.4.4). A PCI penetration testing report should be written with those checks in mind.
• ISO 27001. Results are evidence for Annex A control 8.8, and findings should flow into your risk treatment plan. See ISO 27001 penetration testing for what auditors expect.
• Cyber Essentials Plus. A penetration test is not the Cyber Essentials Plus audit, but fixing its findings makes a first-time pass much more likely.

Who should see the full report?

Only the people who need it to fix the issues. For customers, insurers or partners who want assurance, ask your provider for a summary letter confirming the scope, dates and remediation status, or share a redacted executive summary.

Compare reports year on year. Findings that reappear suggest a process failure; growing numbers of findings in new systems suggest security is not built into projects; faster remediation shows the organisation is improving.

Why Sovereign Secure

Sovereign Secure is a PCI SSC Qualified Security Assessor (QSA) company, an IASME-licensed Cyber Essentials certification body and ISO 27001 certified. We write reports for two audiences, the board and the engineers, and structure them so they can be handed to an assessor or auditor as evidence.

Request a sample penetration test report

A template shows the structure; a real report shows the quality of the writing. Because even a redacted report describes how systems were attacked, we share our sample on request rather than publishing it. Contact us, choose Penetration Testing as the enquiry type, and ask for the redacted sample report. Put the same request to everyone else on your list and compare them side by side. Our guide on how to choose a penetration testing company sets out what else to ask, and our penetration testing services UK page lists the tests we run.