What a good penetration test report actually contains

You don’t buy a penetration test for the testing. You buy it for the report — the artifact your engineers fix from, your leadership reads, and your customers or auditors rely on. Yet report quality varies wildly, and a bad one wastes the whole engagement. Here’s what a good one contains.

An executive summary that a leader can act on

The first page should be readable by someone who will never open a terminal. It answers three questions in plain language:

• How exposed are we? Overall risk, framed in business terms.
• What’s the worst of it? The handful of findings that actually matter.
• What should we do first? A prioritized direction, not a data dump.

If the executive summary is just a bar chart of severity counts, it isn’t doing its job.

Every finding, with proof

This is the heart of the report. For each finding, expect:

• A clear title and severity, with a CVSS vector so the score is transparent and defensible.
• Business impact — what an attacker actually gains, in your context, not a generic textbook description.
• Reproducible proof-of-exploit — the exact requests, responses, or steps that demonstrate the issue. A finding without proof is a guess, and guesses get argued with instead of fixed.
• Specific remediation — concrete guidance your engineers can implement, not “apply input validation.”

The test of a good finding: can a developer who wasn’t in the room reproduce it and understand the fix from the report alone?

Severity that reflects your business, not a scanner’s default

A high CVSS base score on an internal admin tool behind a VPN is not the same risk as a medium on your public login. Good reports adjust for context — data sensitivity, exposure, and exploitability in your environment — and explain the reasoning. Severity is a judgment, and the report should show its work.

Retest results

A finding you haven’t retested is a hope, not a result. A strong report (or its follow-up) records what was verified fixed, what’s still open, and what was risk-accepted. This closes the loop and gives you evidence the work actually reduced risk.

Methodology and scope

The report should state what was tested, what wasn’t, the roles and access used, the time window, and the standards followed (OWASP WSTG, API Security Top 10, etc.). This makes the results reproducible, defensible to an auditor, and honest about coverage.

Strategic recommendations

Beyond individual bugs, the best reports step back: are there patterns? Recurring authorization gaps, a missing secure-defaults library, a class of validation error across services? Fixing the pattern prevents the next ten findings. This is where an experienced tester adds value a tool never will.

What to be wary of

• Raw scanner output pasted in with no human triage or false-positive removal.
• “Informational” padding to inflate the finding count.
• Vague remediation that restates the problem instead of solving it.
• No proof-of-exploit, which usually means no one confirmed the issue is real.

The takeaway

A good report is honest, evidence-backed, prioritized, and actionable — and it ends with fixes you can verify. When you’re evaluating a vendor, ask to see a redacted sample. The report tells you more about the quality of the work than any sales deck ever will.