What A Good Penetration Testing Report Looks Like (And Red Flags In A Bad One)
Dominic Tarn
Head Writer - ReVerb
10.22.2026
A good penetration testing report proves what the testers actually exploited, explains why each finding matters to your business, and tells your engineers exactly how to reproduce and fix it. It pairs a short executive summary with detailed, evidence-backed findings, attack narratives that show how weaknesses chain together, and retest results that confirm the fixes worked. A bad one reads like scanner output with a logo on the cover.
The report is the only thing you keep after an engagement ends. Your auditors will read it, your engineers will work from it, and your customers may ask for a version of it. This guide covers the sections every strong pentest report should contain, how severity ratings should work in 2026, the red flags that signal a low-effort test, and a short checklist of what to request before you sign a contract.
Why The Penetration Testing Report Matters More Than The Test
Two vendors can run the same five-day test and hand you very different value. The difference is almost always in the write-up. A tester who found a privilege escalation path but documented it as a one-line “missing patch” finding has left you with a ticket nobody will prioritize. A tester who showed the full path from a phishing-prone user account to domain admin, with screenshots and timestamps, has given you a reason to act this sprint.
The penetration test report also serves several audiences at once. Leadership wants to know whether the organization is exposed and what it will cost to fix. Engineering wants reproduction steps and specific remediation. Compliance teams and auditors want evidence that testing was scoped correctly, performed by qualified people and followed up. A report that only serves one of those readers forces the others to guess. If you are new to how engagements are structured, our primer on what penetration testing is covers the basics before you get to the deliverable.
The Sections Every Good Pentest Report Contains
Layouts vary by vendor, but strong reports share the same core building blocks. Use the table below as a reference when you review a sample report or a finished deliverable.
Section
What It Should Contain
Primary Reader
Warning Sign If Missing Or Weak
Executive summary
Overall risk posture, most serious issues in plain language, business impact, top recommendations
Leadership, board, customers
Jargon-heavy, no clear verdict, or just a count of findings by severity
Scope and methodology
Targets in and out of scope, test dates, test type (black, gray, white box), standards followed, tester names or roles, constraints
Auditors, security team
Vague scope, no dates, no mention of what was excluded
Findings with severity
Title, affected assets, severity rating with CVSS vector or documented method, business impact, likelihood
Security and engineering leads
Severity copied from a scanner with no context for your environment
Reproduction steps and evidence
Step-by-step instructions, requests and responses, screenshots, command output, timestamps
Engineers
No proof of exploitation, only “potentially vulnerable” language
Remediation guidance
Specific fix for your stack, short-term mitigations, references, verification steps
Engineers, product owners
Generic advice such as “apply patches” or “validate input”
Attack narratives and paths
How individual weaknesses were chained to reach a meaningful objective
Security team, leadership
Findings listed in isolation with no story of impact
Retest results
Status of each finding after fixes (resolved, partially resolved, open), retest date and evidence
Auditors, compliance, engineering
No retest offered, or a retest that only says “fixed” without evidence
Appendices
Tool list, full asset inventory, raw output where useful, glossary, positive observations
Security team
Appendices padded with hundreds of pages of unfiltered scan data
Executive Summary
The executive summary should fit on one or two pages and answer three questions: how exposed are we, what are the few things that matter most, and what should we do first. It should be written for someone who will never read the technical findings. A good one names the real-world consequence (“an external attacker could read customer payment records”) rather than the vulnerability class (“SQL injection in the search parameter”).
Scope And Methodology
This section is what auditors check first. It should list the exact targets (domains, IP ranges, applications, cloud accounts), the testing window, the accounts or access provided, and anything explicitly out of scope. It should also name the methodology or standards the team followed, such as the OWASP Web Security Testing Guide, PTES or NIST SP 800-115, and describe any limitations, such as a production environment where denial-of-service testing was not allowed. Without this context, a clean result means nothing: you cannot tell whether a system was tested and found secure or simply never tested.
Findings With Severity And Business Impact
Each finding should be a self-contained record: a clear title, the affected assets, a severity rating, a description of the weakness, the business impact, and a likelihood assessment. The business impact line is where most weak reports fall down. “Stored XSS” is a vulnerability class. “Any authenticated user can run script in an administrator’s browser session and change payout bank details” is an impact your finance team will understand.
Reproduction Steps And Evidence
Your engineers need to see the issue themselves before they can fix it with confidence. Strong reports include numbered reproduction steps, the exact HTTP requests and responses or commands used, redacted screenshots, and timestamps that match your logs. Timestamps matter more than people expect: they let your detection team check whether the activity was seen, which turns the pentest into a free test of your monitoring as well.
Remediation Guidance
Good remediation advice is specific to your technology and realistic about timelines. It often includes a short-term mitigation (a WAF rule, a configuration change, disabling a feature) alongside the long-term fix (parameterized queries, a framework upgrade, a redesigned authorization check). It should also say how to verify the fix, so engineering can close the ticket with evidence rather than hope.
Attack Narratives And Attack Paths
Real attackers rarely win with one critical bug. They chain a medium-severity information leak, a weak password policy and an over-permissioned service account into a full compromise. Attack narratives show that chain step by step, often with a simple diagram, and they are the clearest signal that a human tester did real work. They also change prioritization: breaking one link in a chain can be cheaper than fixing every individual finding, and the narrative shows you which link to break.
Retest Results
After you remediate, the vendor should retest the original findings and issue an updated report or retest letter that marks each one as resolved, partially resolved or still open, with fresh evidence. For many compliance programs this is not optional. PCI DSS v4.0, for example, requires that exploitable vulnerabilities found during penetration testing are corrected and that testing is repeated to verify the corrections. A report that ends at “here are your findings” leaves you without proof that anything was fixed.
Appendices
Appendices hold the supporting material: the tools used, the full list of tested hosts or endpoints, informational findings, and sometimes positive observations about controls that held up. That last item is underrated. Knowing that your MFA enforcement or network segmentation stopped the testers is useful evidence for auditors and helps you avoid weakening a control that works.
How Severity Should Be Rated: CVSS v4.0 And Beyond
Most reports rate findings with the Common Vulnerability Scoring System (CVSS), maintained by FIRST. The current version, CVSS v4.0, was officially released on November 1, 2023, replacing v3.1. If a vendor is still scoring exclusively in v3.1 in 2026, ask why; it is not automatically wrong, but it suggests the reporting template has not been updated in a while.
What Changed In CVSS v4.0
CVSS v4.0 organizes metrics into four groups. Base metrics describe the intrinsic characteristics of the vulnerability. Threat metrics capture exploit maturity, meaning whether exploitation is theoretical, proven or seen in the wild. Environmental metrics adjust the score for your specific systems and controls. Supplemental metrics, such as Safety, Automatable and Recovery, add context without changing the score. Version 4.0 also introduced naming that tells you which groups were used: CVSS-B for Base only, CVSS-BT for Base plus Threat, CVSS-BE for Base plus Environmental, and CVSS-BTE for all three.
That naming is useful when you read a pentest report. A finding labeled CVSS-B 9.3 is a generic severity. A finding labeled CVSS-BTE has been adjusted for real exploitability and your environment, which is what you actually want from a paid test. The FIRST specification itself recommends that consumers enrich Base scores with Threat and Environmental values, and it is explicit that factors such as regulatory exposure and breach costs sit outside what CVSS measures.
The Qualitative Scale
CVSS scores map to a standard qualitative scale: None (0.0), Low (0.1 to 3.9), Medium (4.0 to 6.9), High (7.0 to 8.9) and Critical (9.0 to 10.0). Your remediation SLAs are probably tied to these bands, which is exactly why inflated or deflated scores cause problems. Everything marked Critical means nothing is, and engineering learns to ignore the labels.
Other Rating Approaches
Some firms use their own risk matrix (likelihood multiplied by impact), the OWASP Risk Rating Methodology for application work, or a blend that shows CVSS alongside a business risk rating. Any of these is acceptable as long as the report documents the method and applies it consistently. What you should push back on is severity with no stated method at all, or a rating that ignores the context the tester saw firsthand. A good report will say something like “CVSS rates this High, but because the endpoint is only reachable from the admin VPN we rate the business risk Medium,” and explain why.
Red Flags In A Bad Penetration Testing Report
Weak reports tend to fail in predictable ways. If you see several of the following in a sample report or a finished deliverable, the engagement was probably closer to an automated scan than a real penetration test. Our guide to vulnerability scanning vs penetration testing explains why that distinction matters for both security and compliance.
Scanner Output Pasted In
Tell-tale signs include plugin IDs, identical boilerplate across findings, dozens of informational items about TLS cipher ordering, and findings that use phrases like “the remote host may be affected.” Scanners are a legitimate starting point, but their output should be validated, deduplicated and rewritten in the context of your environment. If a page reads like it was exported from a tool, it probably was.
No Exploitation Evidence
A penetration test is supposed to prove exploitability. Findings with no screenshots, no request and response pairs and no proof of access are claims, not evidence. Watch for hedged language such as “could potentially allow” on findings rated High or Critical. If the tester exploited it, they should show it. If they chose not to (for safety reasons, for example), the report should say so and explain why.
Generic Remediation
“Apply vendor patches,” “implement input validation” and “follow security best practices” are not remediation guidance. They are filler. Good advice names the component, the version, the configuration setting or the code pattern, and it fits the stack the tester actually saw.
No Attack Chains
A long list of isolated findings with no narrative suggests nobody tried to move from one weakness to the next. That is the core of what you pay a human tester to do. For internal network and Active Directory work in particular, the absence of an attack path section is a strong signal that the test stayed shallow.
Other Warning Signs
Scope and dates are missing, or the scope does not match what you contracted.
Severity ratings with no CVSS vector string or documented method.
Another client’s name, hostnames or screenshots left in the template.
Zero findings on a complex application, with no explanation of what was tested and how.
Hundreds of pages of raw output with no prioritization.
No mention of who performed the work or their qualifications.
[EXPERT QUOTE: White Knight Labs, John Stigerwalt, on the difference between a pentest report that shows real exploitation and attack paths and one that is mostly scanner output]
How To Use The Report With Auditors And Engineering
With Auditors And Compliance Teams
Auditors generally care about four things: that the scope covered the systems the framework requires, that the test was performed by qualified and independent people, that findings were tracked, and that serious issues were fixed and verified. The scope section, the tester details, your remediation tickets and the retest report together answer all four. PCI DSS v4.0 also expects penetration test results to be retained for at least 12 months, so store the final report and retest letter where you can retrieve them during the next assessment.
For external audiences such as customers and procurement teams, most firms issue a separate attestation letter (sometimes called a letter of attestation or completion letter). It confirms that testing happened, summarizes scope, dates, methodology and high-level results, and may confirm remediation, while leaving out exploit details, IP addresses and screenshots. Share the letter externally and keep the full report internal. Our guide to penetration testing for compliance covers what SOC 2, ISO 27001, PCI DSS and HIPAA programs typically expect.
With Engineering Teams
The fastest way to lose the value of a test is to drop a PDF into a shared drive. Instead, convert each finding into a ticket in the team’s normal tracker, with the reproduction steps, evidence and remediation guidance copied in, and an owner and due date tied to the severity band. Hold a readout call with the testers so engineers can ask questions while the details are fresh. Many vendors include this call at no extra cost, and it often surfaces context that never made it into the written report.
Then look for patterns. Five injection findings across different endpoints usually point to one missing framework control, not five separate bugs. Fixing the pattern is cheaper than fixing the instances, and it prevents the same findings from returning next year.
Scheduling The Retest
Agree on a retest window before the engagement starts. Many vendors include one retest within a fixed period (often 30 to 90 days) and charge for later or broader retests. Retests generally verify the original findings rather than re-examining the whole scope, so if you have shipped significant changes since the test, you may need a new engagement rather than a retest.
Penetration Testing Checklist: What To Ask For Before You Sign
You can judge the deliverable before you buy it. Use this penetration testing checklist when you compare vendors, and pair it with our breakdown of penetration testing cost so you know which of these items are usually included and which are billed separately.
A redacted sample report. Any established firm should be able to share one. Review it against the section table above and the red flags list.
The severity method. Ask whether they score in CVSS v4.0, whether they apply Threat and Environmental metrics, and how they handle business risk adjustments.
The retest policy. How many retests are included, within what window, what they cover and whether you get an updated report or a separate letter.
An attestation letter. Confirm one is included and ask to see a sample, especially if customers or auditors will request proof of testing.
Methodology and standards. Which frameworks they follow (OWASP WSTG, PTES, NIST SP 800-115 or their own documented approach) and how much of the work is manual.
Who does the work. Names or roles of the testers, their relevant experience and certifications, and whether any work is subcontracted.
Report formats and delivery. PDF only, or also CSV, JSON or a portal export you can import into your ticketing system.
Readout and critical finding notification. Whether a debrief call is included and how fast they will alert you to a critical issue during testing rather than waiting for the final report.
Report handling. How the report is encrypted in transit, how long the vendor retains your data and evidence, and who on their side can access it.
If you are still building a shortlist, our ranking of the top penetration testing companies in 2026 is a good place to start, and you can run every name on it through the checklist above.
Frequently Asked Questions
How Long Should A Penetration Testing Report Be?
There is no right page count. A focused web application test might produce 20 to 40 pages; a large internal network engagement can run much longer. Judge it on density rather than length: every finding should carry evidence and specific remediation, and the executive summary should stay short regardless of the overall size.
Should I Share My Pentest Report With Customers?
Usually not the full version. The full pentest report contains exploit details that would help an attacker. Share an attestation letter or executive summary instead, and if a customer insists on more, provide a redacted version under NDA.
What Is The Difference Between CVSS v3.1 And CVSS v4.0 In A Report?
CVSS v4.0 adds new Base metrics such as Attack Requirements, separates impact on the vulnerable system from impact on subsequent systems, replaces the old Temporal group with a Threat group focused on exploit maturity, and adds Supplemental metrics. It also uses labels like CVSS-BTE to show which metric groups were applied, which makes it easier to tell a generic score from one tailored to your environment.
Is A Retest Always Included?
No. Many vendors include one retest within a set window, but some charge separately or limit it to Critical and High findings. Confirm the retest terms in writing before the engagement, especially if you need remediation evidence for PCI DSS or a customer audit.
Can An Automated Tool Produce A Valid Penetration Test Report?
Automated tools and PTaaS platforms can produce useful, well-formatted findings, and many combine automation with human testers. What matters is whether the report shows validated exploitation, attack chains and context-specific remediation. Our comparison of PTaaS vs traditional penetration testing looks at how the two delivery models differ in practice.
Conclusion
A good penetration testing report proves exploitation, rates severity with a documented method such as CVSS v4.0, explains business impact, shows how weaknesses chain together and closes the loop with retest evidence. A bad one is unvalidated scanner output with generic advice. Ask for a sample report, the retest policy and an attestation letter before you sign, and you will know which kind you are buying.
