What a penetration test report should include — an annotated walkthrough

When you buy a penetration test, the testing happens out of your sight. The report is the only artifact you, your auditor, your insurer, and your customers ever see — which is why we tell prospects to judge vendors by a sample report before judging them by price. This is the anatomy of a good one, with annotated excerpts drawn from how we write ours (details fictionalized), and the tells that expose a bad one.

Section 1 — Executive summary: written for the person who signs checks

One to two pages, no jargon, answering three questions: how far could an attacker get, what would it have cost the business, and what should be fixed first. It should reference the actual engagement, not read like a template.

The second example tells the CEO nothing — no path, no business impact, no priority beyond a number. It's also, verbatim in structure, what scanner-export reports look like.

Section 2 — Scope and rules of engagement: your legal and factual anchor

Exactly what was tested (IP ranges, application URLs and roles, cloud accounts), what was excluded, the testing window, from where testing originated, and the agreed rules: what was off-limits, how fragile systems were handled, who was on call. This section matters twice — during the engagement it protects both sides; afterwards it defines what the report actually attests. An auditor comparing your report's scope against your real environment is doing exactly the right thing, and "the pen test didn't cover the system that got breached" is a sentence you never want to explain.

Section 3 — Methodology: named, not vibes

Credible reports name their frameworks — for web applications, the OWASP Web Security Testing Guide (WSTG), with findings referencing WSTG identifiers; for overall engagement structure, NIST SP 800-115, the technical guide to security testing and assessment. The section should state how much was manual versus automated. A vendor unwilling to say is answering the question anyway.

Section 4 — The attack narrative: where the value lives

The narrative walks the reader through what the tester actually did: reconnaissance, the first foothold, each escalation, and where the path ended — with timestamps, screenshots, and request/response evidence. This is the section a scan cannot fake, because chains require judgment.

Note what that paragraph does: three individually "medium" issues become one business-critical path. Ranked by scanner CVSS alone, this engagement would have looked routine. Ranked by what an attacker can chain, it was the whole story — and that's the difference you're paying a human for.

Section 5 — Findings: evidence, impact, fix — every time

Each finding needs five elements: a plain-language description, reproduction evidence (not "trust us"), business impact in your context, a concrete fix (config, code, or process — not "implement best practices"), and references (WSTG/CWE). Anything missing one of the five is an assertion, not a finding.

Section 6 — Severity that reflects reality

Good reports show the standard score and an adjusted severity with reasoning: internet-exposed and chainable moves up; theoretically-severe-but-unreachable moves down, with the why written out. Fix-priority ordering is the practical output — your engineers should be able to work the list top-down without a meeting.

Section 7 — The retest record

A findings list you can't verify as fixed is half a product. The report (or an annex issued after your remediation window) should record which findings were retested, when, and with what result — the artifact auditors, insurers, and enterprise customers increasingly ask for by name. We include one retest in every engagement; if your vendor sells it separately, price the total before comparing quotes — the math is in our pen test pricing guide.

The two-minute review that exposes a fake

Open any pen test report — one you've received, one you're evaluating — and check five things. One: does the executive summary describe a specific attack path, or recite severity counts? Two: is there a scope section precise enough that an outsider could say what was and wasn't covered? Three: does any finding include a chain — two or more issues combined — anywhere in the document? Scanners can't chain; humans do it constantly. Four: are fixes concrete ("disable directory listing on /uploads; enforce object-level authorization on /api/invoices") or ceremonial ("harden the environment")? Five: is there a named methodology and a retest path? Fail three of five and you're holding a scan export — which, as we've written in pen test vs. vulnerability scan, is a fine product at a scan price and a rip-off at a testing price.

What to do with the report after you've read it

A good report has four audiences, and reuse is where the money comes back. Engineering works the prioritized list and books the retest. Leadership gets the summary as written — that's why it exists. Compliance files scope, methodology, findings, and retest as evidence for SOC 2 and customer due diligence (the exact artifact list appears in our exchange security guide, and the audit context in our insurance requirements guide). Sales answers security questionnaires from it for a year. One engagement, four consumers — but only if the document was written to be read, which is the whole argument of this article.

Red-flag phrases that reveal a scan in disguise

Language gives it away faster than any technical review. Watch for a report that leans on these: "industry best practices" as the fix for everything (real fixes are specific: "enforce object-level authorization on /api/invoices"); "the tool identified" or "the scan detected" as the subject of every finding (a human tester writes "we exploited," "we gained access," "we chained"); "CVSS score" as the only severity, with no adjusted, context-aware rating; "remediate per vendor guidance" with no reproduction steps; and a severity distribution presented as the headline result ("3 Critical, 9 High…") rather than an attack narrative. Individually these are style; together they're a signature. A report written by someone who spent five days trying to break into your systems reads like a story with evidence. A report generated from a scan reads like a spreadsheet with a cover letter — and once you've seen both side by side, you can't unsee the difference, which is exactly the muscle this article is trying to build.

Frequently asked questions

Request a sample report How we run pen tests

Sources: OWASP Web Security Testing Guide (WSTG) · NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment. Report excerpts are illustrative compositions based on our reporting practice, with all details fictionalized.