Article contents
A good penetration test report contains a short executive summary, the scope and dates of the test, the method, and every finding with its severity, evidence, steps to reproduce, business impact and how to fix it. Once fixes are in, a retest result is added: what is closed and what is not.
Below you will find the report broken down section by section, a table of who reads what and what must be there, how severity is rated, an example of one finding and the signs of a report you should not pay for.
In short
- The executive summary explains in plain words what was found and what it means for the business. No jargon.
- Scope, dates and limitations show what was tested and what was not. Without them you cannot show the report to a partner or an auditor.
- Every finding has a title, severity, description, evidence, reproduction steps, impact and a remediation recommendation.
- Severity is usually scored with CVSS from FIRST and then adjusted for your business.
- A retest confirms the fixes work. Its result is added to the report or issued as a separate document.
- A scanner export with a new cover page is not a pentest report.
The report section by section: who reads it and what must be there
Different people read the report: management decides on money and time, developers fix, an auditor or partner checks that the test happened. NIST says plainly that a report may have several audiences and may need several formats to serve them. [2] PTES splits the report into two main parts: an executive summary and a technical report. [3] The OWASP WSTG suggests a similar structure: an introduction with scope and limitations, an executive summary, findings and appendices. [4]
| Section | Who reads it | What it must contain | Red flag if missing |
|---|---|---|---|
| Executive summary | Owner, CEO, CTO | Goal of the test, key findings in business terms, overall posture, priority actions | Management does not know what to do, and the report goes in a drawer |
| Scope, dates, limitations | CTO, auditor, partner | Systems, addresses and roles tested, test period, what was not tested and why | You cannot prove what was actually tested |
| Method | CISO, auditor | Approach and standards (OWASP WSTG, PTES, NIST SP 800-115), manual and automated parts | Unclear whether it was a pentest or a scanner run |
| Findings summary table | CTO, engineering lead | ID, title and severity of every finding | Hard to plan the work and assign tasks |
| Finding details | Developers, admins | Description, evidence, reproduction steps, impact, recommendation, references | The team cannot reproduce the issue and does not believe it |
| Risk rating explanation | CISO, auditor | How severity was scored: CVSS, business context | Severity levels look arbitrary |
| Appendices | Technical team | Cleaned tool output, list of tests performed | No trace that the tests were run at all |
| Retest result | Everyone who read the report | Status of each finding after fixes | Nobody knows whether the fixes worked |
The WSTG also recommends a disclaimer in the introduction: the test shows a point in time and does not guarantee completeness. [4] That is honest: a pentest is limited by scope and time.
What every finding must contain
The finding is the core unit of the report. A developer should be able to open it and, without calling the tester, understand what is broken, how to check it and how to fix it. The WSTG lists these fields: reference ID, title, likelihood or exploitability, impact, risk rating, description, remediation and additional resources. [4]
In practice a good finding includes:
- an ID and a short title that says what is wrong: "Customers can see other customers' orders", not "Authorization issue";
- severity and, if agreed, the CVSS vector;
- where exactly: URL, parameter, user role;
- a plain description: what is wrong and why it is dangerous;
- evidence: request and response, screenshot, command output that shows the result, with sensitive data masked;
- reproduction steps a developer can follow alone;
- business impact: which data, money or processes are at risk;
- a recommendation: what exactly to change, not a generic "update the system";
- references: CWE, documentation, a fix guide.
Example of a well-written finding
The example is fictional and only shows the format.
| Field | Content |
|---|---|
| ID and title | VT-03. Customers can see other customers' orders (IDOR) |
| Severity | High |
| Where | GET /orders/{id}, role "customer" |
| Description | The server does not check whether the order belongs to the user requesting it. Changing the number in the URL is enough. |
| Evidence | User A opens /orders/1045 (their own order), changes the URL to /orders/1046 and gets a 200 response with user B's name, phone and delivery address. Screenshot and request attached, personal data masked. |
| Reproduction steps | 1. Log in as test customer A. 2. Open your own order. 3. Change the number in the URL to the next one. 4. See someone else's order. |
| Impact | Any registered customer can download all customers' data one by one. That is a personal data leak and a question for you from the regulator. |
| Recommendation | Check the order owner on the server for every request. Do not rely on the number being "hard to guess". Add an automated test for access to another user's object. |
| References | CWE-639: Authorization Bypass Through User-Controlled Key |
| Retest | Fixed. A request for another user's order now returns 404. |
The difference between a finding like this and a scanner line is shown in pentest vs vulnerability scan.
How severity is rated
The most common scoring system is CVSS, maintained by FIRST. The current version, CVSS v4.0, was published in November 2023. [1]
CVSS v4.0 has four metric groups: [1]
- Base: the intrinsic qualities of the vulnerability, constant over time and across environments;
- Threat: what changes over time, such as whether a working exploit exists;
- Environmental: what is specific to your environment, such as security controls;
- Supplemental: extra context that does not change the score.
The 0 to 10 score maps to ratings: 0.1–3.9 Low, 4.0–6.9 Medium, 7.0–8.9 High, 9.0–10.0 Critical. [1] The specification asks consumers to enrich the Base score with Threat and Environmental metrics. A Base score alone does not describe the risk to your company. [1]
That is why a good report puts business context next to CVSS. The same vulnerability in a test environment with no data and in a payment module has a different priority. An honest vendor explains why they raised or lowered a rating.
An alternative to CVSS is the OWASP Risk Rating Methodology. It estimates risk from likelihood and impact, each on a 0 to 9 scale, with separate factors for technical and business impact. [5] Its authors state that business impact matters more. [5] Both approaches are fine. What matters is that the report explains how severity was scored.
Signs of a weak report
- A scanner export under a new name. Hundreds of "possible vulnerability" lines, identical recommendations, no manual verification. That is a scan, not a pentest.
- No evidence. The finding is described in words, but there is no request, response or screenshot. The team cannot confirm the issue exists.
- No reproduction steps. Developers cannot repeat the issue, and later cannot check their fix.
- Everything is "critical". When everything is on fire, nobody knows where to start. Ratings should differ and be explained.
- No scope. Nobody knows which systems were tested. Such a report proves nothing to a partner or auditor.
- No recommendations, or only generic ones. "Follow best practices" is not a task anyone can pick up.
- No retest. Without a second check nobody knows whether the fixes worked. NIST describes retesting as a way to validate that remediation actions were completed. [2]
What to do with the report next
NIST recommends that internal reports include the test method, results, analysis and a plan of action with specific steps and milestones. [2] In plain terms:
- Walk through the report with the vendor in a meeting while questions are fresh.
- Turn findings into tasks with owners and deadlines, starting with critical and high.
- Fix, check on your side, then order a retest.
How to organise that work is covered in after a pentest: how to fix findings and pass the retest. If you are still choosing a vendor, ask for an anonymised sample report before signing. More questions to ask are in how to choose a penetration testing company.
A Veiltrack report includes an executive summary, findings tables by risk level, and for each finding its category, CWE, a CVSS 3.1 or 4.0 score (the client chooses), technical description, evidence and screenshots, plus a remediation order. More on the pentest page.
Checklist: review the report before you accept it
Download the preparation checklist (PDF)PDF · A4
FAQ
What must a pentest report always include?
An executive summary, scope and dates, method, a findings summary table and the details of each finding: severity, evidence, reproduction steps, impact and recommendation. After fixes, a retest result is added.
How is a pentest report different from a scanner report?
A scanner report lists possible issues without manual verification. In a pentest report every finding is confirmed by a person and has evidence, reproduction steps and an explanation of what it means for you.
Do you have to use CVSS?
No. CVSS is the most common, but the OWASP Risk Rating Methodology or your own scale also work. What matters is that the report explains how ratings were scored and takes your business into account.
Who in the company should read the report?
Management reads the summary to decide on resources. Developers and admins read the finding details to fix them. An auditor or partner checks the scope and method.
Can you share the report with a customer or partner?
Yes, but usually you share the summary, scope and retest status, not the technical details. The full report with reproduction steps goes only to people who need it for their work.
References
- FIRST: CVSS v4.0 Specification Document first.org
- NIST SP 800-115: Technical Guide to Information Security Testing and Assessment nvlpubs.nist.gov
- PTES Technical Guidelines: Reporting pentest-standard.readthedocs.io
- OWASP WSTG: Reporting Structure wstg.owasp.org
- OWASP Risk Rating Methodology community.owasp.org
