What a Good Penetration Testing Report Should Include
The report is the deliverable. Most of them fail.
A penetration test is only as useful as the report that comes out of it. The technical work matters — you cannot report what you did not find — but the report is the artefact the business reads, acts on, references, and shares with auditors and customers. Reports that are too long, too thin, too technical, too commercial, or too generic all share one outcome: nothing actually changes. The findings sit in a PDF, the renewal date arrives, and the cycle starts again.
This article describes what a good penetration test report contains, what to be sceptical of, how to evaluate quality from the first few pages, and what red flags justify pushing back on a deliverable before signing it off.
The three audiences a report has to serve
A penetration test report is a single document that must serve three different audiences simultaneously:
- The board, executive team and senior risk owners. They need a clear picture of overall posture, the most important issues, what they mean for the business, and what is being done about them. They do not need finding-by-finding detail.
- The security team. They need patterns: what categories of issue are recurring, what does this say about the security programme, where are the systemic weaknesses, and what should the next investment be?
- The engineering team. They need specifics: exactly what is broken, exactly how to reproduce it, exactly what to fix, exactly how to test that the fix works.
A report that serves only one of these audiences is a partial deliverable. A good report layers the same content for different readers — narrative summary on top, detailed findings in the middle, technical appendices at the bottom.
What an executive summary should actually contain
The executive summary is the part of the report that is most often read and most often badly written. A useful one:
- Tells a narrative in plain English — what was tested, what was found, what it means.
- Names the three to five issues that genuinely matter, with prioritisation and a clear statement of consequence.
- States the scope honestly, including what was not tested and why.
- Provides a risk picture in business terms — “an attacker can extract our entire customer database in approximately ten minutes”, not “Several high-severity findings were identified relating to broken access control.”
- Includes strategic observations that span individual findings — themes, root causes and recommendations that go beyond the per-finding remediation.
What an executive summary is not: a finding count by colour. The summary should not be a translation of the findings table into prose. If the summary contains “3 critical, 8 high, 12 medium, 14 low findings were identified” and stops there, the report has failed at the most important audience.
Methodology: what to expect and what it tells you
The methodology section is short, technical, and informative about the quality of the tester:
- A named methodology or framework reference — PTES, OWASP ASVS / WSTG, NIST SP 800-115, or equivalent. CREST and NCSC CHECK alignment is referenced where applicable.
- A clear statement of in-scope and out-of-scope assets, restated from the engagement letter.
- Rules of engagement and any constraints (testing windows, denial-of-service restrictions, social engineering exclusions, etc.).
- Combination of tooling and manual technique, with manual investigation given appropriate weight.
- Explicit acknowledgement of what could not be tested and why — e.g. “Integration X was unavailable during the testing window and was not assessed.”
A methodology section that names no framework, lists only tools, or makes no mention of manual technique tells you the tester treated the engagement as a tool run. That is not penetration testing.
Findings: what makes each one usable
Each individual finding should contain enough information to be triaged, reproduced, fixed and retested without further conversation with the tester:
- Precise title. Names the specific issue, not a category. “Broken Object Level Authorisation on /api/orders/”, not “Authorisation issues.”
- Severity with rationale. Severity reflects real impact in your environment, not raw CVSS base score. The rationale explains how the severity was determined.
- Reproduction steps detailed enough to verify. A reader who has access to the environment should be able to reproduce the issue from the report alone.
- Evidence. Sanitised screenshots, exact requests and responses (with any sensitive data redacted), or scripts where appropriate.
- Impact specific to this environment. Not a generic description of what the vulnerability class can do; what it actually does here.
- Specific remediation guidance. Actionable in your stack. “Apply security best practice” is not remediation guidance; “Enforce server-side authorisation in the OrderService.get() method by checking that order.customer_id matches the authenticated principal” is.
- CWE/OWASP categorisation for traceability and aggregation across reports over time.
Reports that present findings without reproduction steps or specific remediation are not useful as engineering artefacts. They are useful only as a count, and a count is not a deliverable.
Attack path analysis: where the report earns its keep
Some of the most valuable findings are not individual vulnerabilities but attack paths — sequences in which several low or medium issues combine to produce high impact. A scanner cannot produce attack paths. A good tester can, and a good report explains them.
Attack path narrative typically includes:
- A numbered walkthrough of how the chain works, with evidence at each step.
- A diagram where the chain is non-trivial.
- The starting and ending state — “from unauthenticated external attacker to Domain Admin”, for example.
- The set of individual findings the chain depends on, cross-referenced.
- A remediation discussion that addresses the chain, not just each individual link.
If a report names individual findings but never describes how they combine, you are reading a vulnerability list rather than a penetration test report. Push back.
Remediation roadmap, not a list of fixes
A useful report does not stop at per-finding remediation. It groups findings by root cause and sequences a remediation programme:
- Root-cause grouping. Multiple findings often share a single underlying issue (e.g. authorisation checked only at the UI layer, not the API). Fixing the root cause fixes several findings.
- Sequencing. Some fixes unblock others; some are prerequisites for retesting; some are quick wins to demonstrate progress. The order matters.
- Effort indication. A high-level estimate — quick win, contained fix, architectural change — helps planning even if it is not precise.
- Owner suggestion. Which team or function is best placed to own each fix.
Retest and verification
A reputable provider includes retesting in the engagement. The retest report (or retest section of the main report) should state:
- What was retested.
- Which findings are confirmed fixed (and how that was confirmed).
- Which findings remain open, with current status.
- Which findings have changed in severity following partial remediation.
- Any new findings encountered during retest (usually scoped strictly, but occasionally a remediation introduces a new issue).
Without retesting, “fixed” is a self-report rather than a verified outcome.
Red flags in a penetration test report
Some patterns in a report are reliable indicators that the engagement was shallow or that the deliverable is padded:
- Generic remediation language. “Apply security best practice”, “Follow OWASP guidance”, “Harden the configuration” — these are not remediation guidance.
- High counts of low-severity findings. Often used to pad a thin report. Twenty low-severity informational notes do not equate to one usable finding.
- No reproduction steps. If a finding cannot be reproduced from the report, it cannot be verified or fixed efficiently.
- No false-positive elimination evident. A report that includes obvious scanner output verbatim has not been validated by a tester.
- No business context. Findings described only as CVSS scores and CVE references, with no statement of what they mean in your environment.
- Heavy reliance on “we ran [tool] and here are the results”. That is a scan, not a test. The report should describe judgement and decisions, not just commands run.
You are within your rights to push back on any of these before signing off the deliverable. A reputable provider will revise; an unreputable one will blame your expectations.
Frequently asked questions
How long should a penetration test report be?
Length is a poor proxy for quality. A focused engagement may produce a 40-page report; a broad one may produce 150 pages. Density and usability matter more than page count.
Should the report include CVSS scores?
Yes, as one data point. But severity in the report should reflect real impact in your environment, not raw CVSS base. A good report explains the reasoning behind any deviation.
Can I share the report with customers?
You can usually share a redacted summary letter or executive summary with customers under NDA. The full report typically remains internal due to the sensitivity of the reproduction details.
What is a retest letter?
A short follow-up document, after remediation, confirming which findings have been verified as fixed and which remain open. Often shared with auditors or enterprise customers as evidence of closure.