What a Good Penetration Test Report Looks Like

A good penetration test report communicates risk in business terms, documents every finding with reproducible evidence, provides specific remediation guidance that a developer can act on the same day, and includes a structured retest process to confirm fixes actually close the identified vulnerabilities.

It has two audiences — the C-suite who needs to understand exposure and authorize remediation budget, and the technical team who needs to know exactly what broke, how an attacker could exploit it, and precisely how to close the gap. A report that serves only one of those audiences is a partial deliverable. Most reports on the market fail both.

The Executive Summary

The executive summary is the most read section and the most consistently mishandled. It should not be a condensed list of CVEs. Executives do not need to know that CVE-2024-1234 scored 9.1 — they need to know whether the organization can withstand a ransomware operator, whether customer data was at demonstrable risk during the test window, and what the remediation effort will cost in engineering time.

A defensible executive summary contains:

Overall risk posture — a single, honest characterization (Critical / High / Medium / Low) with the business rationale behind it, not just an arithmetic average of finding severities.
Attack narrative — what a realistic threat actor could have achieved with the access and techniques discovered. If the tester achieved domain compromise via a chain of three medium-severity findings, that chain belongs here, in plain language.
Key statistics — total findings by severity, findings compared to prior engagement (if applicable), percentage of scope covered.
Top remediation priorities — the three to five actions that, if taken immediately, reduce the most risk. Not a full list — a prioritized starting point.
Residual risk — what the test did not cover and why (scope limitations, time-box constraints, out-of-scope systems). Honesty about coverage gaps is a quality signal, not a weakness.

Methodology

A methodology section tells you whether the team followed a structured, repeatable process or improvised. It should reference established frameworks — the Penetration Testing Execution Standard (PTES), the OWASP Testing Guide (OTG), or NIST SP 800-115 — and then describe what the testers actually did within that framework for this specific engagement.

Generic boilerplate reads: "We performed reconnaissance, scanning, exploitation, and reporting." A proper methodology section specifies which reconnaissance techniques were used and why, which tool categories were applied to which targets, what authentication states were tested (unauthenticated, authenticated as standard user, authenticated as privileged user), and what the test was explicitly designed to simulate (external attacker with no prior knowledge, insider threat, compromised third-party vendor, etc.).

If the methodology section could have been copy-pasted from any other report, it describes no methodology at all.

Scope Definition

Scope is a contract. The report must document it precisely and permanently, because scope determines what findings mean and what they do not mean.

A complete scope section includes:

IP ranges, hostnames, and URLs that were in scope
Explicit list of systems and services that were out of scope
Test dates and times (with timezone)
Test type (black box, grey box, white box)
Authentication credentials provided (roles, privilege levels)
Rules of engagement — whether denial-of-service testing was authorized, whether social engineering was in scope, whether production databases could be targeted
Point-of-contact authorizations (who authorized the test)

The out-of-scope list is as important as the in-scope list. A finding on an out-of-scope system is not a finding in this report. An untested system that is later breached does not implicate the pentest — provided the exclusion is documented.

Risk Rating: Why CVSS Alone Is Not Enough

CVSS v3.1 (Common Vulnerability Scoring System) provides a standardized baseline for scoring vulnerability severity. A CVSS score is calculated from six base metrics:

Metric Group	Components
Exploitability	Attack Vector, Attack Complexity, Privileges Required, User Interaction
Impact	Confidentiality, Integrity, Availability
Scope	Whether the impact crosses privilege boundaries

The base score ranges from 0.0 to 10.0, bucketed into None / Low / Medium / High / Critical. It gives you a common vocabulary and a reproducible number. It does not give you business risk.

A CVSS 9.8 unauthenticated remote code execution vulnerability on an isolated development server with no production data and no network path to the core environment is materially less dangerous than a CVSS 7.2 authenticated SQL injection on the payment processing API. Raw CVSS informs technical severity. Business risk requires layering in asset criticality, data classification, network exposure, compensating controls, and threat actor likelihood.

A quality report presents both: the CVSS score as a baseline, and an assessed business risk rating that accounts for context. These should not always match, and when they diverge, the report should explain why.

Finding Format: The Atomic Unit of a Pentest Report

Each finding is a standalone technical document. A reader should be able to hand a single finding to a developer and have everything that developer needs to understand, reproduce, and fix the issue — without any other context.

A complete finding includes:

Title — descriptive and specific. "SQL Injection in Login Endpoint" is a title. "SQL Injection" is a category.
CVSS v3.1 score and vector string — the full vector, not just the number, so the scoring rationale is auditable.
Business risk rating — the assessed severity in context (see above).
Description — what the vulnerability is, why it exists, and what class of weakness it represents (CWE reference).
Evidence — screenshots, request/response captures, proof-of-concept output. Evidence is not optional. A finding without evidence is an allegation.
Step-by-step reproduction — numbered steps a reader can follow to reproduce the finding in the tested environment. If the steps require a specific tool, name it and the exact command.
Business impact statement — a concrete description of what an attacker who successfully exploited this finding could achieve, in terms the business understands. "An attacker could extract the full customer database including PII, enabling regulatory notification obligations under applicable data protection law."
Specific remediation guidance — not "update the library." The library name, the patched version, the configuration change required, the code pattern to eliminate, and a reference to vendor documentation or a known-good implementation.
References — CVE identifier (if applicable), CWE identifier, relevant OWASP category, vendor advisory, or research publication.

The difference between a finding that drives remediation and one that does not is almost always the specificity of steps 6, 7, and 8.

Remediation Verification

A penetration test without a retest capability is an incomplete service. Developers patch. Patches introduce regressions, miss root causes, or address the symptom rather than the underlying weakness. The only way to know whether a finding is resolved is to test the resolution. The guide on retesting and remediation covers the full remediation cycle — from finding publication to verified closure — in detail.

A quality report distinguishes explicitly between:

Fix stated — the client reports the remediation was applied.
Fix verified — the tester retested the specific finding against the production or staging environment and confirmed the vulnerability is no longer exploitable.

"Fix stated" is not remediation verification. It is a status update. Organizations that accept "fix stated" as closure are operating on trust rather than evidence, and that posture regularly produces surprises during the next audit or incident.

The best providers publish findings to a SaaS platform in real time during the engagement, so development teams can begin remediation before the test window closes. Each finding carries a retest workflow: when the client marks a fix as applied, a tester retests and updates the finding status with evidence. The final report reflects verified closure, not self-reported closure.

Red Flags in Low-Quality Reports

Security managers who receive a pentest report should evaluate it critically. These are signs the deliverable is not fit for purpose:

Automated scanner dump — findings that read like Nessus or Qualys output with no manual validation, no evidence of exploitation, and no business context. Scanner output is reconnaissance, not a pentest.
No evidence — findings stated without screenshots, request captures, or proof-of-concept output.
Generic remediation — "Apply vendor patches" or "Follow secure coding practices" are not remediation instructions.
No executive summary — or an executive summary that is a severity count table and nothing else.
Inflated finding counts — informational items and best-practice recommendations counted alongside exploitable vulnerabilities to justify scope or fees.
No methodology — or a methodology section indistinguishable from a template.
No out-of-scope documentation — the report cannot be evaluated if you do not know what was not tested.

How to Evaluate Report Quality: A Checklist for Security Managers

Before accepting a pentest deliverable, run it through these six checks:

Criterion	What to Look For
Executive summary	Risk posture, attack narrative, business context — not a CVE list
Methodology	Specific techniques, frameworks referenced, what the test simulated
Scope documentation	In-scope and out-of-scope explicitly listed, test dates, rules of engagement
Finding quality	Evidence present, reproduction steps numbered, business impact stated, specific remediation
Risk rating	CVSS score plus business context rating with rationale when they diverge
Retest commitment	Process defined for verifying fixes, not just accepting client attestation

If a report fails more than two of these criteria, request a revised deliverable. A pentest that does not produce an actionable report is a compliance checkbox, not a security exercise. For a detailed comparison of automated platform reports versus traditional PDFs, automated vs. manual pentest reports explains how reporting format affects how quickly your team can remediate.

What a Bad Report Looks Like — Side by Side

The gap between a useful pentest report and an inadequate one is not subtle. The following comparison shows the same six report elements as they appear in high-quality and low-quality deliverables.

Report Element	Good Report	Bad Report
Finding title	"Unauthenticated Admin Access via JWT None Algorithm — /api/v1/admin"	"Authentication Bypass"
CVSS score	"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (9.8 Critical)"	"Critical"
Evidence	HTTP request/response pair with headers + screenshot of admin panel accessed using an unsigned JWT token	Scanner output or one-line assertion
Remediation	"Validate JWT algorithm server-side and reject any token with `alg:none` or an unexpected algorithm. Reject before signature verification. Example: `if (decoded.header.alg !== 'RS256') throw new Error('Invalid algorithm')`"	"Update authentication library"
Business impact	"Any unauthenticated external attacker can access all tenant data, modify billing records, and permanently delete customer accounts. No credentials required."	"High impact"
Reproduction steps	Five-step numbered sequence including the exact HTTP request, the tool used (Burp Suite / curl), and the expected response confirming exploitation	"Exploitable via Burp Suite"

The left column produces immediate, unambiguous remediation action. The right column produces a conversation about what the finding actually means and whether it is real — a conversation that delays remediation and consumes engineering time that should be spent patching.

The finding title alone signals report quality. A tester who writes "Authentication Bypass" either did not investigate deeply enough to characterize the specific mechanism, or cannot communicate technically with sufficient precision. Either condition should concern the organization receiving the deliverable.

Frequently Asked Questions

How long should a penetration test report be?

There is no correct page count — the right length is whatever is required to document every finding completely, explain the methodology, and provide a useful executive summary. In practice, a comprehensive web application test covering a typical mid-market application will produce a report in the range of 40 to 120 pages. Internal network tests with a larger finding set may run longer. What matters is not length but completeness: every finding must include evidence, reproduction steps, business impact, and specific remediation. A 15-page report that omits evidence for half its findings is not a lean report — it is an incomplete one. A 200-page report padded with boilerplate and scanner output is not thorough — it is obscuring signal with noise.

Should the executive summary be readable by a non-technical board member?

Yes. That is its primary purpose. The executive summary exists because the people who authorize remediation budgets and accept residual risk are usually not reading CVSS vector strings. A board member or CFO reviewing the executive summary should be able to answer four questions without any other context: How exposed are we? What could an attacker have done? What do we need to fix first? What will it cost in time and resources? If the executive summary requires a technical background to interpret, it has failed. A useful test: hand the executive summary to someone outside the security team and ask them to summarize the organization's situation. If they cannot, the summary needs revision.

What is the difference between a technical report and an executive summary?

They are not separate documents — they are two sections of the same report, written for different audiences. The executive summary translates risk into business language: overall posture, what an attacker could have achieved, top priorities, and remediation cost. The technical report contains the full finding inventory with CVSS scores, evidence, step-by-step reproduction, and specific remediation guidance. The executive summary references the technical findings by severity and priority but does not reproduce their technical detail. Both sections are necessary. An organization that receives only a technical report without an executive summary cannot efficiently direct executive attention and budget toward the right problems.

How should a report handle vulnerabilities that could not be fully exploited?

They should still be documented, with a clear explanation of why exploitation was not achieved or completed. The tester may have identified a probable vulnerability that time constraints prevented from being fully proven, or a vulnerability that requires a specific precondition that was not present in the test environment. These are documented as "potential" or "unconfirmed" findings with the evidence gathered, the suspected impact if exploited, and the rationale for inclusion. Omitting partially-investigated findings misrepresents the scope of the assessment. A finding that was partially confirmed during a time-boxed test may be fully exploitable under real-world conditions where an attacker has no time limit.

What is a remediation SLA in a pentest report context?

A remediation SLA (service-level agreement) defines the expected timeline for addressing findings of each severity level, measured from finding publication to verified closure. Most organizations operate with SLAs along these lines: Critical findings — 24 to 72 hours for initial mitigation; High — 7 to 14 days; Medium — 30 to 60 days; Low and Informational — next scheduled maintenance window. Some organizations define SLAs in their security policy; others negotiate them with the pentest provider as part of the engagement terms. The SLA is only meaningful if the provider supports a retest process that can confirm closure within the defined timeline. A 24-hour Critical SLA is not achievable if the provider batches retests into a final report delivered three weeks after testing ends.

Closing Note

The report is the product. The testing is the process that generates it. An organization that commissions a penetration test is paying for documented, verifiable knowledge of its exposure — and for a clear path to closing that exposure. Anything that falls short of that is an incomplete service.

If you want to see what a complete, evidence-backed, retest-verified penetration test report looks like in practice, providers like WhiteJaguars publish findings in real time through a SaaS platform, with full evidence, structured remediation guidance, and verified closure tracking for every engagement. See the checklist for evaluating penetration testing providers to evaluate deliverable quality before selecting a provider.

Elements of a High-Quality Penetration Test Report