Sample pentest report: what does a good report look like?

A pentest report that ends up in a drawer is money wasted. A good report is structured in layers — suitable for both a board looking at risk and a developer who wants to patch the same day. This page explains the structure Resync uses, with an example finding to illustrate. A sample report as a PDF is available at the bottom.

The structure at a glance

1. Executive Summary

The first two pages are for the board, management team, CISO or client — not for developers. The summary describes in plain language what was tested, what was found, how severe it is, and what that means in business terms. No jargon. No long table of CVE numbers. No 200-page scanner output.

What it contains:

• Risk overview in plain language, with a direct relationship to business objectives
• Number and severity of findings (critical, high, medium, low)
• Business impact per category — what could happen
• Strategic recommendations and compliance context (NIS2, GDPR, ISO 27001, NEN 7510)
• Conclusion: recommended next steps and timeline

2. Technical Findings

Every finding follows the same pattern — you can open any finding independently, read it, reproduce it and fix it. Each item consists of six elements:

• Title and category (e.g. "Insecure Direct Object Reference on customer endpoint")
• Severity (Critical, High, Medium, Low) with CVSS score and justification
• Reproduction steps — literally the steps an attacker or developer follows to reproduce the finding
• Evidence — screenshots, HTTP request/response logs, exploit snippets where relevant
• Impact in both technical and business terms
• Recommendation — concrete, with code or configuration examples where useful

Example finding (anonymised)

This is one example; a typical report contains 3 to 15 findings, depending on scope.

3. Prioritisation by impact

Not every finding is equally urgent. The report sorts findings on a combination of two axes: how easily exploitable (from outside, authenticated, requiring social engineering) and how large the impact if exploited (data exfiltration, account takeover, availability loss). This produces a recommended remediation order, which also appears in the executive summary.

4. Retest Declaration

After your team has remediated the findings, we retest — not the entire application, but specifically the identified findings. Per finding we note the status: resolved, mitigated, or open. The retest declaration is appended to the report as a separate PDF, with date and signature. Usable as evidence towards auditors, clients or regulators.

What a good report is not

• Not 200 pages of scanner output. A good report is typically 30–60 pages, half technical depth and half management-readable.
• Not a list of "potential issues" without context.
• Not generic OWASP links as a recommendation — concrete, application-specific advice.
• Not open-ended — every engagement closes with a retest declaration.

We send the sample report by email, ungated, after a brief intake request. This lets us match the report to your situation — more relevant than a generic PDF nobody looks at.

Ready to have your own report produced?

For scope categories and the complete process, see the penetration testing page. For pricing: how much does a penetration test cost.