A good penetration testing report earns its keep in one place: whether a developer can reproduce and fix each finding, and whether anyone re-proved it closed. Page count, a color-coded severity chart, and a glossy executive summary do not answer either question. Most reports fail exactly where it counts, the section that proves remediation actually held, not the pages that come before it. Below is the anatomy of a strong report, section by section, with a worked example finding you can hold up against your own vendor's work.
Buyers read a pentest report twice. Once when it lands, to see how bad the findings are. Then again months later, if anyone remembers to ask whether those findings ever actually got fixed. The gap between those two moments is where most security programs quietly lose the thread.
That gap is bigger than most teams assume. Cobalt's 2026 State of Pentesting Report found that 57% of executives believe their organization consistently meets remediation SLAs, versus just 15% of practitioners, as of the 2026 report. It also tracks a high-risk finding "half-life" of 10 days for top-performing teams against 249 days for the bottom tier, roughly eight extra months of exposure for the slowest programs. A report that does not force the retest question is exactly how that gap stays invisible until an incident or an audit surfaces it.
What a penetration testing report is actually judged on
A penetration testing report exists to move two people to action: the engineer who has to fix the finding, and the leader who has to decide whether the fix actually worked. Everything else, the cover page, the risk-scoring methodology, the CVSS-style heat map, is packaging around those two jobs. If an engineer cannot follow the reproduction steps and rebuild the exploit, the finding is not actionable. It is a rumor with a severity label attached.
None of that makes structure worthless. Auditors and boards genuinely need a clear executive summary and a named methodology reference, such as NIST SP 800-115 or the Penetration Testing Execution Standard, to trust that the work was structured rather than improvised. Those sections exist to make the findings credible to a non-technical reader. They are not a substitute for the findings themselves.
Judge a report on two things and two things only: can a developer reproduce and fix each finding, and did anyone re-prove it closed. A three-finding report that nails both is worth more than a forty-finding report that proves none of them fixed.
Anatomy of a good penetration testing report
A strong report has five parts, and each one earns a specific job.
Executive summary
The executive summary is written for the audience that will never read past page two: leadership, the board, an auditor doing a first pass. PTES splits reporting into exactly this two-tier structure, an executive section aimed at business impact and a technical section aimed at engineers, because the two audiences need different things from the same engagement. Good executive summaries state the overall risk posture in plain language and name the highest-impact findings without technical jargon. A summary padded with vulnerability counts and no risk framing is filler dressed as content.
Scope and methodology
Scope defines exactly what was tested, what was explicitly out of scope, and the dates of the engagement, so a reader can tell whether the report still describes the system in front of them. Methodology names the standard the testers actually followed, such as the OWASP Web Security Testing Guide or NIST SP 800-115, rather than an internal-only process nobody can verify. A report with no dates and no named methodology is not describing a specific engagement. It is a template with a client name typed into the header.
Each finding: reproduction, evidence, impact, and remediation
This is the section that does the actual work. Every finding needs four elements to be useful rather than decorative:
- A clear title and severity rating naming the vulnerability class plainly (insecure direct object reference, not "input validation issue").
- Reproduction steps detailed enough that an engineer who was not in the room can rebuild the exploit, request by request.
- Evidence: screenshots, request and response pairs, or log excerpts, not a paraphrase of what happened.
- Business impact, translated from technical access into what an attacker could actually do (read another customer's invoices, escalate to admin, exfiltrate a signing key).
- Remediation guidance specific to the code or configuration, not "apply the vendor patch" with no detail on what actually changed.
Retest and validation status
This is the section most reports either skip or shortchange, and it is the one that actually proves the engagement was worth the invoice. A retest entry states plainly whether the finding is open, remediated, or closed, the date it was re-tested, and what the tester actually did to confirm it, not just a status word changed in a spreadsheet. HackTheBox's own sample penetration test report includes a prioritized remediation summary, and even it stops there, with no retest-status column at all, which is exactly the gap this section exists to close. An auditor holding you to SOC 2's remediation evidence expectations needs proof the fix held, not a promise that it should. A findings table with no retest column is only half finished.
Example finding: a worked write-up (illustrative)
Here is what one finding looks like with all four elements above, plus a real retest entry. This is an illustrative example built for this guide, not a real company, product, or CVE.
Finding: Insecure direct object reference in the invoice API
Severity: High
Reproduction steps:
- Authenticate as a standard user on account 40218.
- Request
GET /api/v1/invoices/40218and confirm the invoice returns normally. - Replace the path parameter with a neighboring ID:
GET /api/v1/invoices/40219. - Observe that the API returns invoice 40219's full contents despite the request being authenticated as account 40218.
Evidence:
``` GET /api/v1/invoices/40219 HTTP/1.1 Host: api.example-saas.test Authorization: Bearer <account-40218-token>
HTTP/1.1 200 OK {"invoice_id": 40219, "customer": "Acme Fixtures LLC", "amount_due": 4820.00, "payment_last4": "4412"} ```
Business impact: Any authenticated customer can enumerate sequential invoice IDs and read another customer's billing details, including a partial payment identifier, with no additional privilege required. For a multi-tenant SaaS product this is a direct data-isolation failure, the exact failure mode an auditor checking confidentiality controls is trying to catch.
Remediation: Authorize the invoice lookup against the requesting account's own tenant ID server-side, not against a valid session alone, and do not rely on the object ID being hard to guess.
Retest status: Closed. Retested June 12, 2026 against the patched endpoint. The identical request now returns 403 for four additional cross-account ID pairs, and a fifth attempt using a manipulated tenant claim was also rejected.
Where most penetration testing reports fall short
The pattern above, a clean findings table with no real retest entry, is the industry default, not the exception. Retesting is also where vendors quietly draw the pricing line: some bill it as a separate line item, exactly the incentive problem we flagged when pricing out a pentest engagement.
There is a second reason the gap persists. A single report, however well it is retested, is still a photograph of one moment, and most teams now ship code faster than an annual testing cadence can track. See continuous penetration testing for what that mismatch costs beyond the report itself.
What this means for your next vendor or internal report
If you are choosing a pentest vendor, or reviewing what your internal team already produces, do not start with the page count or the severity chart. Ask to see one finding end to end: the reproduction steps, the evidence, and the retest entry with a date on it. If a vendor cannot show you that for a sample finding, they cannot show it to you for your own findings either, the exact sample-report check covered in vetting a pentester's reviews and credentials.
For engineering leads, the practical habit is smaller: treat "remediated" as a claim, not a fact, until someone reruns the original exploit against the patched code. That single habit is what separates a program with a short half-life on high-risk findings from one that only looks fixed in a ticket.
How Vortex closes the retest gap in the report
The retest section is the weakest part of almost every penetration testing report because it depends on someone manually re-running an exploit weeks or months after the finding shipped, against a system that has usually already changed again by then. Vortex is built around closing that exact gap: the loop is Test, Validate, Fix, Retest, Prove, and the retest step is not a manual follow-up scheduled for next quarter, it runs against the current build the moment a fix ships.
When a finding is genuinely exploitable, Vortex generates the code fix, then re-runs the original attack path against the patched build to confirm it is actually closed, the same reproduction-and-retest discipline this guide just walked through, but on every deploy instead of on the day an auditor asks. The report artifact that comes out the other side shows a validated, re-proven fix, with the same evidence and retest date a strong human report should have, generated automatically instead of chased down after the invoice is paid.
If your last penetration testing report told you what was wrong but left you guessing whether it is still wrong today, Get a Demo and see what a continuously retested, continuously proven report looks like against your own pipeline.
Detect. Defend. Deter. The best report is the one nobody has to take on faith.