Guide

What's in a penetration test report?

The report is the thing you actually pay for. Here's what a professional web application penetration test report contains, section by section — and how to tell a real one from a rebadged scanner dump.

A penetration test is only as valuable as the report it produces. A good report serves two very different audiences at once — executives who need to understand risk and sign off budget, and engineers who need precise, reproducible steps to fix each issue. Here's how a professional report is structured.

1. Executive summary

A plain-English overview for stakeholders and non-technical readers: what was tested, the overall risk posture, the most serious findings, and what they mean for the business. This is the section your client's security team or your board will read — and often the section an enterprise customer asks to see before signing a deal.

2. Scope and methodology

Exactly what was in scope (which applications, URLs, roles and accounts), the rules of engagement, the testing dates, and the standards followed — for us, the OWASP Web Security Testing Guide and PTES. This makes the test auditable and repeatable.

3. Technical findings

The core of the report. Each finding is documented individually with:

  • A clear title and description of the vulnerability.
  • Severity rating — based on impact and likelihood, so you fix what matters first.
  • Proof of concept — the exact steps, requests or payloads needed to reproduce it. This is what separates a real test from a scanner: a demonstrated, exploitable issue, not a maybe.
  • Affected components — the specific endpoints or parameters involved.
  • Remediation guidance — concrete, actionable advice mapped to your stack, not generic boilerplate.

4. Severity ratings

Findings are scored by severity (typically Critical, High, Medium, Low, Informational) and by business impact, so your team can triage. A good report never just lists issues alphabetically — it tells you where to start.

5. Remediation advice

For each issue, clear steps to fix it, written for developers and mapped to your technology. The point of a test is not to produce a list of problems; it's to help you close them.

6. Retest and verification

Once you've remediated, a retest confirms the fixes actually work and the report is reissued showing each issue's updated status. With Vesperis Security this retest is included free — see what's included in a web application penetration test.

How to spot a low-quality report

Be wary of reports that are clearly an exported vulnerability scan with a logo on the front: hundreds of "findings", no proof of concept, generic remediation text, and no business-logic issues (because scanners can't find them). A genuine manual test produces fewer, higher-confidence findings — each one demonstrated and explained.

Request a sample report

Want a report your developers can act on?

Get a fixed-price quote in minutes, or ask us for a redacted sample report.