A penetration test report is the only artifact most of your organization ever sees from the engagement. Your board sees the executive summary. Your auditors see the scope and the findings table. Your engineers see the remediation guidance, or they see a PDF nobody opens. The testing itself happened weeks ago behind an NDA; the report is what remains, and for the business, the report is the pentest. That is exactly why so many buyers get burned. A rigorous engagement led by senior testers and an automated scan relabeled as a pentest arrive in the same shape: a heavy PDF, a color-coded severity table, some remediation paragraphs, a logo on the cover. Both cost roughly the same on the invoice. Only one of them will actually reduce the breach you avoid next year, and that gap matters, because IBM's 2025 Cost of a Data Breach Report puts the global average breach at US$4.44M and the US average at US$10.22M.
So how do you read a pentest report and tell whether it is any good? Grade it against ten criteria. A good pentest report communicates clearly to two very different audiences, proves every claim with reproducible evidence, and hands your team a prioritized path to fixing what it found. Anything that fails those three jobs is not a pentest report; it is scan output with a cover page. This post is the scorecard. Score your most recent deliverable as you read. A report that lands under 7 out of 10 means you paid pentest prices for automation, and the remedy is a conversation with your vendor, not a bigger line item next cycle.
What a good penetration test report should include
Before the scorecard, the short answer to the question buyers ask most. A good penetration test report should include, at minimum: a business-language executive summary with a bottom-line-up-front verdict; a clear statement of scope, methodology, and limitations; the attack narrative showing how findings chain together; a findings register where each issue carries a business-impact-based severity, reproduction steps, and evidence; prioritized remediation with named owners and effort estimates; and a defined retest path. If any of those six are missing, the report is incomplete regardless of how thick it is. The scorecard below expands each of these into a gradable, ten-point test so you can put a number on it rather than a gut feeling.
The 10-point pentest report scorecard
Award one point per criterion. Be strict: half-credit is a fail. Tally at the end.
1. BLUF executive summary a director can act on
The executive summary is the most-read and most-neglected page in the report. It should open bottom-line-up-front: what is the overall risk posture, what are the two or three things leadership must decide this quarter, and what happens if they do nothing. A director who does not know what CVSS stands for should be able to read one page and correctly brief the board. If the executive summary is a restatement of the findings count ("we found 3 critical, 7 high, 12 medium") with no interpretation, no business framing, and no recommended decision, it fails. Pass test: a non-technical executive can read only the summary and correctly answer "how bad is this and what do we do about it."
2. Attack narrative, not a bag of bugs
Real attackers do not stop at one vulnerability; they chain a medium-severity information leak into a broken access control into a full account takeover. A strong report tells that story as a kill chain: entry point, pivot, escalation, impact. This attack-narrative section is the single clearest signal that a human tester with adversarial intent did the work, because automated scanners cannot construct it. They report isolated findings with no concept of how a real intrusion composes them. Pass test: the report contains at least one narrative walkthrough that connects two or more findings into a realistic attack path.
3. Severity rated by business impact, not raw CVSS
CVSS v4.0, published by FIRST, is a useful common language, but a raw Base score is not a risk rating. The same technical flaw can be a nuisance on an internal test box and a company-ending event on an internet-facing system holding regulated data. A good report factors in exploitability in your environment, data sensitivity, and blast radius, and it says so. A report that pastes the raw CVSS Base score as the final severity, with no environmental adjustment and no business context, has outsourced its judgment to a formula. Pass test: severity ratings visibly account for your context, not just the vector string.
4. Reproducible evidence for every finding
Every finding must include enough for your engineer to reproduce it independently: the exact request or payload, the affected endpoint or parameter, the preconditions, and evidence such as a screenshot, response snippet, or proof-of-concept. "The login form is vulnerable to injection" is not a finding; it is an assertion. Reproduction steps are what separate a claim from proof, and they are also what let your team confirm the fix later. Pass test: an engineer who did not attend the engagement can reproduce a sampled finding from the report alone.
5. Prioritized remediation with named owners
Findings are worthless until someone fixes them. Strong remediation guidance is specific ("parameterize this query," "enforce object-level authorization on this endpoint"), ordered by risk, scoped with a rough effort estimate, and mapped to an owning team. Generic remediation ("implement input validation," "follow OWASP best practices") is filler that offloads the hard thinking back onto you. Pass test: each critical and high finding names what to change, who owns it, and roughly how much work it is.
6. A retest path defined in writing
A finding is not closed until it is verified closed. The report, or the accompanying statement of work, should define how remediation gets retested: which findings qualify, the turnaround SLA, and whether retests are included or billed. Without this, you are trusting your own team's self-attestation that the critical bug is gone. Pass test: the deliverable states, in writing, how and when fixes will be independently retested.
7. Scope and methodology transparency
The report must state exactly what was tested, what was excluded, what standards guided the work (for example PTES, NIST SP 800-115, or the OWASP Web Security Testing Guide), the testing window, and the limitations. Scope transparency is not boilerplate; it is how you know whether the clean result means "we are secure" or "we only looked at one third of the estate." A report that is vague about what it did not test is hiding its own coverage gaps. Pass test: you can draw the boundary of what was and was not assessed from the report alone.
8. Coverage that proves a human went beyond the scanner
This is the criterion that catches the relabeled scan. Automated tools are excellent at the vulnerability floor: known CVEs, missing headers, outdated libraries, TLS misconfigurations. They are poor at the complex classes that require understanding the application, such as IDOR, broken authorization, business-logic flaws, and multi-step abuse. A report that contains only floor-level, scanner-detectable findings, and nothing that required reasoning about how the application actually works, was probably not a human-led pentest at all. Pass test: the findings include at least one complex, logic-or-authorization-class issue a scanner could not have found on its own.
9. Readable by both executives and engineers
A good report is layered so two audiences can each go straight to what they need: a business-language summary up front, a technical findings register in the body, and appendices for raw output. It should not force a developer to wade through board narrative to find the payload, nor bury the executive in packet captures. Pass test: both a non-technical leader and a hands-on engineer can each find their layer without reading the other's.
10. Actionable next steps beyond the findings
The best reports close with strategic recommendations that outlast the individual bugs: patterns worth fixing at the architecture level, control gaps worth investing in, and a suggested cadence for the next assessment. This is where a senior tester's judgment shows. A report that ends at the last finding, with no forward view, leaves value on the table. Pass test: the report recommends what to do structurally, not just which bugs to patch.
Anatomy of a strong finding
Six of the ten criteria live or die at the level of the individual finding. Here is what a defensible one contains. If your report's findings are missing three or more of these parts, criteria 3 through 5 are failing regardless of the cover-page polish.
Red flags: signs you overpaid for a scanner dump
Score the criteria first. These red flags are the fast triage, the patterns that should make you re-read the whole report with suspicion and, often, call the vendor.
Scanner output relabeled as a pentest. Findings that map one-to-one onto default Nessus, Nikto, or OWASP ZAP plugin names, with no chaining and no logic-class bugs, mean a tool did the work and a template wrote the report.
Raw CVSS with no business context. Severity columns that are pure Base scores, identical to what any scanner emits, with no environmental adjustment.
No reproduction steps. Findings asserted but not demonstrated. If your engineer cannot reproduce it, your vendor may not have either.
No retest path. Silence on how fixes get verified is silence on whether the vendor stands behind the work.
Boilerplate remediation. "Implement input validation" and "follow industry best practices" pasted under every finding, with nothing specific to your code.
False positives left in. Findings that do not hold up on inspection signal that nobody senior validated the tool output before shipping.
A findings count with no narrative. A report that is a sorted table and nothing else, with no attack story, no coverage discussion, and no strategic close.
Compliance overreach in the framing. A report sold as delivering a certification or attestation by itself, rather than as evidence that supports your audit, is misrepresenting what a pentest is.
How to turn a good report into fixes
A high-scoring report is only valuable if it changes what your engineers ship. The fastest way to lose the value is to let the PDF sit in a shared drive. Get the findings into the systems where work actually happens: open a ticket per finding in your tracker, tie each to an owner and a due date keyed to severity, and schedule the retest before the engagement closes. This is where the difference between a static PDF and a modern workflow shows. Stingrai's AI pentesting agent, Snipe, is built to close this loop directly: it hunts complex classes like IDOR and broken authorization, and its AutoFix capability turns a finding into a proposed code change as a pull request, so remediation starts as reviewable code rather than a paragraph an engineer has to translate. A finding that arrives as a PR is a finding that gets fixed.
Compliance is downstream of this, not the point of it. A rigorous, well-evidenced report gives your auditors the artifact they need for SOC 2, ISO 27001, or PCI DSS. But treat the audit checkmark as a byproduct of finding and fixing real issues, never as the goal, because a report optimized only to satisfy a checklist is exactly the kind of low-scoring deliverable this scorecard is designed to catch.
What this means for defenders
Score every report you receive. Run the ten criteria on your last deliverable this week. A number turns a vague sense of disappointment into a specific vendor conversation.
Push the failing criteria back to the vendor. A report weak on reproduction steps, business-impact severity, or retest path can often be revised. A serious vendor will fix it; the response tells you whether to rebook.
Buy the tradecraft, not the page count. Coverage of complex, logic-class issues (criterion 8) is the hardest thing to fake and the easiest to verify. Ask a shortlisted vendor for a sample report and grade it before you sign, using Stingrai's vendor-evaluation framework as a companion.
Wire findings into the workflow. A finding that lands as a ticket or a pull request gets fixed; a finding that lands as page 34 of a PDF does not. Prefer engagements built around web application penetration testing that integrate with your development pipeline.
Retest as policy, not as a favor. Make a written retest path a procurement requirement. An unverified fix is an assumed fix, and assumptions are what breaches are made of.
Frequently Asked Questions
What should a good penetration testing report include, and how do you evaluate its quality?
A good penetration testing report should include a bottom-line-up-front executive summary in business language, a clear scope and methodology statement, an attack narrative that chains findings into realistic kill chains, a findings register where each issue carries a business-impact-based severity plus reproduction steps and evidence, prioritized remediation with named owners, and a defined retest path. You evaluate quality by scoring the report against those elements. Grade it out of ten across communication, proof, and fixability; anything under 7 out of 10 means you likely received scanner output rather than a human-led pentest.
How do I read a pentest report if I am not technical?
Start with the executive summary, which in a good report is written for exactly you: one page, bottom-line-up-front, stating the overall risk posture and the two or three decisions leadership must make. If that page tells you how bad it is and what to do without requiring you to understand CVSS, the report passes its most important test. Hand the technical findings register to your engineers and ask them whether each critical finding includes reproduction steps they can follow.
What are the biggest red flags in a pentest report?
The loudest red flags are scanner output relabeled as a pentest (findings that map one-to-one onto default tool plugin names), raw CVSS Base scores presented as final severity with no business context, findings with no reproduction steps, no defined retest path, and boilerplate remediation like "implement input validation" copied under every finding. Any single one of these warrants re-reading the report with suspicion; several together mean you paid pentest prices for automation.
What is an attack narrative in a pentest report and why does it matter?
An attack narrative is a written walkthrough that connects individual findings into a realistic intrusion path: entry point, pivot, privilege escalation, and business impact. It matters because real attackers chain vulnerabilities rather than exploiting them in isolation, and because automated scanners cannot construct one. The presence of a coherent attack narrative is the clearest single signal that a human tester with adversarial intent, not just a tool, performed the assessment.
Is CVSS enough to rate the severity of a finding?
No. CVSS v4.0, published by FIRST, is a useful common vocabulary, but a raw Base score is not a risk rating for your organization. The same flaw can be trivial on an isolated internal host and critical on an internet-facing system holding regulated data. A quality report adjusts severity for exploitability in your environment, data sensitivity, and blast radius. A report that pastes raw CVSS Base scores as the final severity has outsourced its risk judgment to a formula.
How do I know whether a pentest was done by a human or an automated scanner?
Look for the things scanners cannot produce: an attack narrative chaining multiple findings, and at least one complex issue such as IDOR, broken authorization, or a business-logic flaw that requires understanding how the application works. If every finding is a floor-level, scanner-detectable issue (known CVEs, missing headers, outdated libraries) with no chaining and no logic-class bugs, a tool most likely did the work regardless of what the cover page says.
What is a fair retest policy, and should it be in the report?
A fair retest policy provides independent verification that every critical and high finding is actually closed, typically within a defined window after delivery and with a stated turnaround SLA. It should be documented in writing, either in the report or in the statement of work, including which findings qualify and whether retests are included or billed. Without a written retest path, closure rests on your own team's self-attestation rather than the tester's confirmation.
Can a pentest report deliver SOC 2 or ISO 27001 compliance?
A pentest report is evidence that supports a compliance program, not the certification itself. A rigorous, well-evidenced report gives your auditors what they need for SOC 2, ISO 27001, or PCI DSS, but the attestation or certificate is issued through the relevant audit process, not by the pentest. Treat a report that markets itself as delivering compliance certification on its own as a red flag; it is misrepresenting what a penetration test is.
Where can I learn how to choose the vendor behind the report?
The quality of the report follows from the quality of the vendor. Grade a prospective vendor's sample report against this ten-point scorecard before you sign, and pair it with a structured vendor-evaluation framework covering tester pedigree, CVE output, certifications, and retest policy. Stingrai maintains a companion buyer's guide, How to Choose the Best Penetration Testing Service Provider in 2026, and offers penetration testing services led by senior researchers with 18 published CVEs across the team.
References
IBM. Cost of a Data Breach Report 2025. 2025. https://www.ibm.com/reports/data-breach. Annual study of breach economics; source for the US$4.44M global average and US$10.22M US average breach cost figures cited above.
FIRST. Common Vulnerability Scoring System (CVSS) v4.0. November 2023. https://www.first.org/cvss/. The current CVSS specification and severity model referenced throughout the severity discussion.
The Penetration Testing Execution Standard (PTES). Technical Guidelines. http://www.pentest-standard.org/. Community methodology standard covering scoping, execution, and reporting phases of a penetration test.
NIST. SP 800-115: Technical Guide to Information Security Testing and Assessment. https://csrc.nist.gov/pubs/sp/800/115/final. US federal guidance on planning, executing, and reporting security assessments.
OWASP. Web Security Testing Guide (WSTG). https://owasp.org/www-project-web-security-testing-guide/. The canonical methodology reference for web application security testing scope and coverage.
