What to Expect in a Penetration Test Report
A penetration test can last a few days or several weeks, but what remains afterwards is the report. It is the document your engineers use to fix vulnerabilities, your leadership uses to understand risk, and your auditors and customers use as evidence that your systems have been independently tested. A strong penetration test report turns a test into real security improvements. A weak one ends up in a shared folder and changes nothing.
This guide walks through what a professional penetration test report contains, section by section, how findings are rated, what separates a good report from a poor one and how to act on the results once you receive it.
Why the Penetration Test Report Matters
The testing itself is invisible to most of your organization. The report is the only lasting output, and it has to serve several different readers at once:
- Executives and board members need to understand the overall level of risk and what it means for the business, in a few minutes and without technical detail.
- Security and IT managers need to prioritize remediation, assign owners and plan resources.
- Developers and system administrators need precise, reproducible technical detail to understand and fix each issue.
- Auditors, regulators and customers need evidence of what was tested, when, by whom and how, and proof that critical issues were addressed.
A good report is structured so that each of these readers can find what they need quickly. If you are new to penetration testing, start with our overview: What Is Penetration Testing?
The Structure of a Penetration Test Report
Providers format reports differently, but professional reports contain the same core sections.
1. Document Control and Confidentiality
The first pages identify the client, the provider, the report version, the distribution list and the classification of the document. A penetration test report describes exactly how to attack your systems, so it should be treated as confidential, delivered through a secure channel and shared only with people who need it.
2. Executive Summary
The executive summary is written for non-technical readers and is usually one or two pages. It should answer:
- What was tested, and why?
- What is the overall security posture and risk level?
- What are the most important findings, described in business terms?
- What should the organization do first?
A strong executive summary avoids jargon. Instead of “IDOR in /api/v2/invoices”, it says “any customer can access other customers’ invoices, including personal and payment data”. Many reports also include a summary chart showing the number of findings by severity.
3. Scope and Methodology
This section records exactly what was in scope (applications, URLs, IP ranges, user roles, cloud accounts), what was out of scope, the testing window, the source IP addresses used by testers, the testing approach (black, gray or white box) and the methodologies followed, such as the OWASP Web Security Testing Guide, PTES or NIST SP 800-115. Any limitations, such as systems that were unavailable during testing, should also be stated. Auditors look closely at this section, because a report is only valid evidence for the assets it actually covers.
4. Risk Rating Methodology
The report should explain how severity was determined, so that “high” means the same thing to every reader. Most providers use CVSS, often adjusted for business context. The next section explains this in more detail.
5. Attack Narrative
The attack narrative tells the story of the test: how testers gained initial access, which weaknesses they combined and how far they got. This is often the most valuable part of a report, because it shows how individually moderate issues can chain into a serious compromise. It is also what distinguishes a penetration test from a vulnerability assessment.
6. Detailed Findings
Each finding is documented on its own, typically with:
- Title and severity rating
- Affected assets: URLs, endpoints, hosts or accounts
- Description: what the vulnerability is and why it exists
- Steps to reproduce: precise enough for a developer to confirm the issue
- Evidence: HTTP requests and responses, command output or screenshots, with sensitive data masked
- Impact: what an attacker could do with it, in business terms
- Remediation: specific guidance on how to fix it, with references
- References: for example CWE identifiers or OWASP guidance
7. Remediation Roadmap
Good reports go beyond individual fixes and group recommendations into a prioritized plan: quick wins that should be fixed immediately, issues for the next development cycle and structural improvements such as changes to authentication design or network segmentation.
8. Appendices
Appendices typically contain tool output, lists of tested endpoints or hosts, informational observations and, after a retest, the status of each finding.
How Findings Are Rated
The most widely used scoring system is the Common Vulnerability Scoring System (CVSS), maintained by FIRST (the Forum of Incident Response and Security Teams). The current version, CVSS v4.0, was released on 1 November 2023, and many reports still use the previous version, 3.1. Both produce a score from 0.0 to 10.0 that maps to a qualitative severity:
Severity | CVSS score |
|---|---|
None | 0.0 |
Low | 0.1 – 3.9 |
Medium | 4.0 – 6.9 |
High | 7.0 – 8.9 |
Critical | 9.0 – 10.0 |
CVSS v4.0 organizes its metrics into four groups: Base (the intrinsic characteristics of the vulnerability), Threat (for example whether exploitation has been observed), Environmental (how the vulnerability affects your specific environment) and Supplemental (additional context that does not change the score). It also introduces names that show which groups a score includes, such as CVSS-B for a base-only score and CVSS-BTE for a score using Base, Threat and Environmental metrics.
Why Context Matters More Than the Score
A CVSS base score describes a vulnerability in general, not in your environment. An experienced tester adjusts severity for context: a SQL injection in an internal test system with dummy data is not the same risk as one in your production customer database. Good reports explain these adjustments, and some providers combine CVSS with a business impact rating or the OWASP Risk Rating Methodology. When prioritizing, it can also help to check whether a vulnerability is known to be exploited in the wild, for example in CISA’s Known Exploited Vulnerabilities catalog.
Example: What a Well-Documented Finding Looks Like
Below is a simplified example of how a single finding might appear in a report.
Finding 3: Broken object level authorization in invoice API Severity: High Affected asset:
GET /api/v2/invoices/{invoiceId}on app.example.comDescription: The API returns invoice details based only on the invoice ID supplied in the request. It does not check whether the invoice belongs to the authenticated user.
Steps to reproduce:
- Log in as User A and request one of User A’s own invoices.
- Replace the invoice ID with an ID belonging to User B.
- The API returns User B’s invoice with HTTP 200.
Evidence: Request and response excerpts showing User B’s data returned to User A’s session (personal data masked).
Impact: Any registered customer can retrieve other customers’ invoices, including names, addresses and partial payment details, which could constitute a reportable personal data breach.
Remediation: Enforce an ownership check on the server for every object request, ideally through a central authorization layer rather than per endpoint. Prefer non-sequential identifiers as defense in depth, but do not rely on them as the fix.
References: CWE-639; OWASP API Security Top 10, API1: Broken Object Level Authorization.
A developer reading this finding knows exactly where the problem is, how to confirm it, why it matters and how to fix it. That is the standard every finding in your report should meet.
Signs of a Good Penetration Test Report
A good report | A weak report |
|---|---|
Executive summary written in business language | Executive summary is a list of vulnerability names |
Clear scope, dates and methodology | Vague or missing scope |
Attack narrative showing how issues were chained | Isolated findings with no context |
Evidence for every finding (requests, responses, screenshots) | Findings copied from scanner output without proof |
Severity adjusted for your environment | Raw tool severities applied mechanically |
Specific, actionable remediation | Generic advice such as “follow best practices” |
Authorization and business logic findings | Only missing patches and headers |
Retest results included | No way to confirm what was fixed |
Red Flags
- The report looks like exported scanner output with a cover page and no evidence of manual testing.
- Every finding is critical, or every finding is low. Neither reflects a careful assessment.
- There are dozens of informational findings padding the report, while the real issues are hard to find.
- The remediation advice is the same for every finding.
- Nobody can explain a finding when your developers ask follow-up questions.
If you see these signs, you have likely paid for a vulnerability scan rather than a penetration test.
How to Act on Your Penetration Test Report
The report is the start of the work, not the end. A practical approach:
- Hold a debrief meeting. Walk through the findings with the testers, your security team and the engineers who will fix them. Most providers offer this, and it clears up questions faster than email.
- Fix critical issues immediately. Critical findings are usually reported during testing; do not wait for the final report to start.
- Assign an owner and a deadline to every finding. Track them in your normal ticketing system, not in a separate spreadsheet that nobody opens. Many organizations use remediation targets by severity, for example days for critical, weeks for high and the next release cycle for medium.
- Look for root causes. If testers found authorization flaws in three endpoints, the problem is probably the authorization design, not three individual bugs. Fixing the pattern prevents the next finding.
- Request a retest. Once fixes are deployed, the testers verify them and update the report. This gives you confidence that the issues are closed and evidence for auditors.
- Feed lessons back into development. Recurring issues are a signal for developer training, secure coding standards or new automated checks in the pipeline. See our guide to shift left security.
Sharing Results with Customers and Auditors
Avoid sending the full technical report to external parties: it is effectively a guide to attacking your systems. Instead, many providers issue a short attestation letter or a summary report that confirms the scope, dates, methodology and the remediation status of findings, without technical details. Ask your provider whether this is included.
Frequently asked questions
Conclusion
A penetration test report is the deliverable you keep, use and show to others long after testing ends. A good one speaks to executives and engineers at the same time: it explains the business risk clearly, proves every finding with evidence, shows how weaknesses combine into real attack paths and gives specific guidance on how to fix them. When you choose a provider, ask to see a sample report first. It will tell you more about the quality of their work than anything else.
Want to see what our reports look like? Contact us to request a redacted sample report, or explore our penetration testing services.
Subscribe to our cyber security newsletter