Penetration Testing Report Example: What a Real, Actionable Report Looks Like

What a Penetration Testing Report Is

Most organizations only see two or three of these a year, usually right before an audit. That scarcity is exactly why so many reports go unread. If the report cannot survive contact with a skeptical engineer or a bored board member, the money spent on the test was largely wasted.

Below is the structure a competent report follows, a realistic findings table, and the parts that separate a report engineering teams actually fix from one that sits in a shared drive until next year’s audit.

Standard Report Structure

Frameworks differ (OWASP Testing Guide, PTES, NIST SP 800-115, OSSTMM), but a professional report almost always contains the same seven sections in the same order. Skipping any of them is a signal the tester rushed the deliverable, not just the test.

1. Executive Summary

Written for a CFO, general counsel, or board member, not an engineer. No CVSS jargon, no stack traces. It states what was tested, how many findings were critical or high, whether an attacker could have reached sensitive data or admin control, and what it would cost the business if exploited. Two pages, maximum. If a non-technical reader has to ask “so are we exposed or not,” the summary failed.

2. Scope and Methodology

This section names exactly what was in scope (domains, IP ranges, API endpoints, mobile builds, source code access level) and, just as important, what was explicitly out of scope and why. It states the testing type (black box, gray box, white box), the access level granted (unauthenticated, low-privilege user, admin), the test window, and the standard followed, typically the OWASP Web Security Testing Guide (WSTG) or a PTES-aligned methodology for infrastructure work. A report with no methodology section is a red flag: it means you cannot tell whether the tester ran an automated scan for four hours or did genuine manual testing for two weeks.

3. Findings Summary Table

A single table listing every finding by severity, so a reader can grasp exposure in under a minute before reading a single technical detail. See the example below.

4. Detailed Findings

One entry per vulnerability, each with a fixed structure: title, CVSS score and vector string, affected asset or endpoint, business impact in plain language, technical description, proof of exploitation, and remediation guidance. This is the section engineers actually use, and it is where most reports fall apart, either because the proof of exploitation is missing or because the remediation advice is a generic one-liner copied from a CVE database.

5. Attack Narrative (Chained Findings)

When individual findings combine into a full compromise path, a competent report tells that story separately from the findings list. A “medium” information disclosure bug and a “medium” broken access control bug can chain into a critical account takeover. If the report never shows the chain, the business impact section for each individual finding will understate the real risk, sometimes by a lot.

6. Retest and Verification Appendix

After the client patches, a retest confirms each fix actually closed the hole rather than just changing the error message. This appendix lists each finding, its remediation status (fixed, partially fixed, not fixed, risk accepted), the retest date, and evidence the fix holds under the same proof-of-concept used originally. Reports without this appendix cannot tell you whether last quarter’s “critical” is still open today.

7. Appendices

Raw scanner output (if any was used as an input, not the final product), tool versions, a glossary of terms for non-technical stakeholders, and a full list of testers with certifications (OSCP, OSWE, OSCE) for auditor requirements like SOC 2 or PCI DSS.

Example Findings Summary Table

This is what a realistic findings table looks like for a mid-size web application and API engagement. Severity ratings here follow CVSS v3.1 base scoring, translated into business terms.

Illustrative example for format reference. Actual findings, scoring, and business impact will vary by application and must be validated against the live system, not copied from this table.

Anatomy of a Single Finding

Each detailed finding, like the BOLA example above, should expand into roughly this structure in the body of the report:

Title and severity. A specific, searchable name, not “Authorization Issue.” “Broken Object-Level Authorization on Order Retrieval API” tells an engineer exactly what to search for in the codebase.

CVSS score and full vector string. The vector string matters more than the number. Two findings can both score 7.5 for completely different reasons (one needs no privileges and no user interaction, one needs an authenticated insider), and the vector string is the only place that distinction is visible.

Affected asset or endpoint. The exact URL, parameter, header, or code path. Not “the API,” not “the login system.”

Business impact. Written for a product owner or risk committee: what data, workflow, or revenue stream is exposed, and under what conditions.

Technical description. The root cause: missing authorization check, unsanitized input, misconfigured header, whatever it is, in enough depth that a developer can locate it in the codebase.

Proof of concept / evidence. A request and response pair (with sensitive data redacted), a screenshot of the exploited state, or a short script that reproduces the issue on demand. This is the single most important piece of a finding and the one most often missing or faked.

Remediation guidance. Specific, not “implement proper authorization.” For the BOLA example: “Enforce ownership checks server-side on every request to /api/v2/orders/{id} by comparing the authenticated user’s ID against the order’s owner_id field before returning data. Do not rely on the client to only request its own IDs.”

What Separates an Actionable Report From Shelf-Ware

Most pentest reports are read once, filed, and never opened again until the next audit cycle. A handful get fixed within the quarter. The difference is rarely the tester’s skill. It is almost always the report itself.

Proof of exploit, not a scanner export. A raw Burp Suite or Nessus export dumped into a PDF template is not a pentest report. If every finding cannot be traced to a manual step a human tester actually performed, ask why you paid for manual testing rates.

An executive summary a board member can defend budget with. If the CFO cannot repeat the top three findings in their own words after reading it once, the summary is written for the wrong audience.

Engineer-level technical detail with reproducible steps. A developer should be able to reproduce the finding from the report alone, without calling the tester to ask “wait, how did you get that request to work.”

Prioritization tied to exploitability and business impact, not raw CVSS. A 9.8 on an internal admin tool behind three layers of network segmentation is a different risk than a 7.5 on a public-facing payment endpoint. A report that ranks purely by CVSS number, with no adjustment for exploitability or exposure, is asking engineering to fix the wrong things first.

A retest that confirms the fix actually worked. Roughly a third of “fixed” findings in unverified environments turn out to be incompletely patched when retested with the same proof of concept. Without a retest section, “fixed” is a claim, not a fact.

Questions to Ask Vendors

Ask these before signing, not after the first report lands. Vendor-neutral, and they apply whether you are evaluating a boutique shop, a Big Four practice, or an automated platform.

1. Can I see a full sample report on an application similar to mine, not a two-page excerpt? A vendor who only shows redacted snippets is hiding either thin technical depth or a template that does not scale to real complexity.
2. For each finding, is the proof of exploitation an actual request/response pair or screenshot, or just a CVSS score and a paragraph? No proof of exploit means no one confirmed the vulnerability actually fires, only that a pattern matched.
3. Do you show attack chains, or only isolated findings? A report with twenty “medium” findings and no chain analysis may be hiding a critical path a determined attacker would find in an afternoon.
4. Who signs off on severity ratings, and is it adjusted for actual exploitability, or just raw CVSS? Raw CVSS with no business context produces prioritization that does not match real risk.
5. What is your false positive rate, and how is it measured? If the vendor cannot give you a number, or the number comes from marketing rather than a validation process, treat every finding as unverified until proven otherwise.
6. Is a retest included in the price, and how long after remediation can I request it? A report with no included retest leaves you unable to prove to an auditor that a critical finding was actually closed.
7. What testing standard or framework do you follow (OWASP WSTG, PTES, NIST SP 800-115), and can I see the checklist you tested against? No named standard usually means no consistent methodology, just whatever the individual tester felt like doing that week.
8. What percentage of this engagement was manual versus automated tooling? If the answer is vague, assume the ratio favors automation more than the price implies.
9. Will the same tester who ran the engagement be available to walk my engineering team through the findings? A vendor who cannot produce the original tester for a follow-up call likely used a junior or contracted resource you never met.
10. How do you handle a finding we dispute, for example a false positive or a compensating control you did not know about? No documented dispute process signals the report is final the moment it is delivered, with no room for engineering’s context.
11. What is your average time from test completion to report delivery? A multi-week gap after testing ends often means findings sat in a queue while the vulnerability window stayed open.
12. Can findings be exported in a machine-readable format (CSV, JSON, or direct integration) for our ticketing system? A PDF-only deliverable with no structured export adds manual re-entry work and slows remediation for every finding.

RFP Criteria

Criteria to write directly into a formal RFP for report deliverables and quality. Use as-is, adjust thresholds to your risk tolerance.

Vendor Evaluation Criteria

Use this rubric to score competing vendors side by side on report quality specifically, independent of price or brand reputation.

Why This Matters for How You Test

Annual pentest programs typically cover about 20 percent of an organization’s attack surface, tested once against a threat landscape that moves every day. CVEs are exploited in the wild in about 3 days on average. A report that takes two weeks to arrive after testing, covering a fraction of the surface, describes a risk picture that is already stale by the time anyone reads it.

This is the gap FireCompass’s agentic AI platform is built to close. It runs continuous, agentic web application and API pentesting instead of a point-in-time engagement, and every finding ships with proof of exploit: a reproducible request/response pair or working exploit code, not a CVSS score and a hope. On public benchmarks it validated 104/104 XBEN cases and 12/12 Acuart cases with proof-of-concept evidence, and its false positive rate runs under 2 percent, against 40 to 70 percent for traditional scanners. In a Fortune 500 engagement, this pushed effective coverage from roughly 10 percent to 99 percent of the application surface across a portfolio of 2,000-plus apps, at around 11 times lower cost than manual testing alone.

None of that changes what a good report has to contain. It changes how often you can afford to get one, and how current the findings are when your engineering team opens it.

Frequently Asked Questions

Related Terms