What's in a Penetration Test Report (and How to Read One)

The report is the part of a penetration test you keep. The testing itself lasts days; the report is what your developers fix from, what your auditor files as evidence, and what your sales team sends to the enterprise customer who asked “have you been pentested?”

Here’s what a good report contains, what each section is for, and how to turn it into action.

Executive summary

One or two pages, written for people who won’t read the rest: founders, managers, board members, customers.

A good executive summary answers three questions in plain language:

• What was tested, and when?
• What’s the overall risk? Usually a single rating, with a sentence explaining why.
• What matters most? The one or two findings that would cause real business damage, described by impact (“any customer could read other customers’ invoices”), not by jargon (“IDOR in /api/v2”).

If the executive summary is a table of CVE numbers, it has failed at its job.

Scope and approach

This section records exactly what was tested: URLs, API endpoints or IP ranges; the environment; the user roles and test accounts used; the dates; and anything explicitly excluded.

It matters more than it looks. Auditors check that the scope covers the systems they care about. And when a finding is later disputed, or a new vulnerability is discovered, the scope section tells you whether that part of the system was ever tested.

Methodology and severity ratings

How the test was carried out, and against which published standard: usually the OWASP Web Security Testing Guide (opens in a new tab) for web applications, and PTES (opens in a new tab) or NIST SP 800-115 (opens in a new tab) for network testing. Auditors look for this section, because it shows the test followed a repeatable method rather than one person’s instincts.

It should also explain how severity was decided. Most reports use CVSS, the Common Vulnerability Scoring System maintained by FIRST. Version 4.0, released in November 2023, is current; many reports still use 3.1, and either is fine if the report says which. CVSS scores run from 0 to 10 and map to fixed bands:

CVSS score	Severity
0.0	None
0.1 to 3.9	Low
4.0 to 6.9	Medium
7.0 to 8.9	High
9.0 to 10.0	Critical

FIRST’s own CVSS v4.0 specification (opens in a new tab) is explicit that the base score measures severity, not risk. It describes how bad a flaw is in general, not how much it matters to you. A good report adds business context: a Medium finding on the payments system may deserve attention before a High on an internal test server, and the report should say so.

Findings summary

A table of every finding with its ID, title, severity and, after retesting, its status. This is the page your team will return to most, because it’s effectively the to-do list.

Detailed findings

The core of the report: one section per finding. Each should contain:

• Title: what’s wrong, in words a developer understands immediately.
• Severity: the rating and the full CVSS vector string (for example CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N), so anyone can recalculate the score and see why it landed where it did.
• Affected components: the exact URLs, endpoints, parameters or hosts.
• Description: what the weakness is and why it exists.
• Impact: what an attacker could realistically do with it.
• Evidence: the requests, responses or screenshots proving it, with sensitive data redacted.
• Reproduction steps: enough detail that your developer can see the problem for themselves, and later confirm the fix.
• Remediation: a specific fix for your system, not a generic “sanitize input”.
• References: the relevant OWASP category and CWE (opens in a new tab) entry, which let you look up the weakness class and search your codebase for the same pattern.

The reproduction steps and remediation are what separate a useful report from an expensive PDF. If your developers can’t reproduce a finding, they can’t be confident they’ve fixed it.

You can see a full example finding in this sample penetration test report.

Retest results

After you fix the findings, the tester verifies each fix and updates the report. Every finding ends up marked as fixed, partially fixed, not fixed, or risk accepted (a documented decision to live with the issue).

For compliance and customer questionnaires, the retest is often as important as the test. It’s the evidence that issues were closed, not just discovered.

Appendices

Supporting material: tools used, full lists of hosts or endpoints, raw evidence, and sometimes lower-priority observations that didn’t warrant a full finding.

How to turn a report into a fix plan

1. Read the executive summary together. Make sure everyone agrees on what matters most.
2. Book the readout call. Walking through findings with the tester answers questions that would otherwise take days of back-and-forth.
3. Fix Critical and High findings first, starting with anything internet-facing that touches sensitive data.
4. Look for patterns. Three access-control findings usually mean a missing central authorization check. Fix the pattern, not just the three endpoints.
5. Add a regression test for each fix, so the same bug can’t quietly return.
6. Formally accept any risk you won’t fix, with a reason and an owner.
7. Request the retest and share the updated report and attestation letter with whoever needs it.

Red flags in a report

• Hundreds of pages dominated by informational findings.
• Generic descriptions that could apply to any system.
• No evidence or reproduction steps.
• Severity ratings with no explanation.
• No retest offered.

These usually indicate an automated scan rather than a penetration test. See penetration testing vs vulnerability scanning for why that distinction matters. If the report is for an auditor, check it against what SOC 2, ISO 27001 and PCI DSS require.

If you’d like a report your developers can actually fix from, get a quote for a web application penetration test.

Sources

• FIRST, Common Vulnerability Scoring System v4.0: Specification Document (opens in a new tab), and CVSS v3.1 specification (opens in a new tab) for qualitative severity ratings.
• OWASP, Web Security Testing Guide (opens in a new tab).
• NIST, SP 800-115: Technical Guide to Information Security Testing and Assessment (opens in a new tab), section 8 on reporting.
• MITRE, Common Weakness Enumeration (opens in a new tab).