When it comes to information security and protecting your infrastructure, or simply preparing for compliance, ordering a penetration test is only half the job. The other half is working through the results and fixing the vulnerabilities listed in the penetration testing report.
The way a report is written can largely determine how priorities for fixing vulnerabilities are set and how long it takes to work through it. That is why it is a good idea to ask a vendor for a sample pentest report before signing a contract.
We recommend doing exactly that, as it can save you from many unpleasant surprises later on. In this article, we look at what a report should include, what makes it easy to work with, and which signs suggest a vendor is not a good choice, or that it is the right fit for your goals.
In case you missed: What Is a Pentest and How to Choose the Right One in 2026.
Pentest report: what it should look like and why you need it
Pentest reports can vary significantly from one vendor to another. One may contain dozens of pages of Burp Suite screenshots, CVE lists and technical jargon. Another may be a few pages long, with statements like “no critical vulnerabilities found; we recommend keeping your software up to date.” Technically, both documents count as penetration test reports. But neither is likely to meet the real needs of the business. So what does?
Let’s start with a simple but not always obvious point: why you need a report. A pentest is the process of finding vulnerabilities, and the report is the result of that process. It is the document that should tell CISOs, engineers, auditors and management what was tested, which issues were found and how much they matter to the business.
The quality of a pentest is hard to judge by the number of vulnerabilities alone. You can receive dozens of findings and still have no answers to simple questions. What actually matters to the business? How can the issue be reproduced? How do you fix it? And what should you fix first? The client should not have to figure this out on their own. The answers should be in the report.
So, ideally, a good pentest report includes:
- an executive summary for management;
- scope and testing methodology;
- a description of each vulnerability with a CVSS score;
- reproduction steps and evidence;
- business impact;
- specific recommendations and remediation priorities;
- technical appendices.
Let’s go through them one by one.
Executive summary in a pentest report: what management wants to know
The executive summary is usually read by department heads, CISOs or auditors. At this level, the focus shifts from specific technical details (such as XXE or IDOR) to the overall risk assessment, the components covered and the potential business impact.
That is why a good executive summary is not just a shortened copy of the technical section. It explains the results in terms of risk. For example, instead of “SQL injection in the id parameter,” management needs to know that an attacker could use this issue to access customer data.
A good report gives a brief overview of the big picture in this section: which risks were identified, how critical they are, what was in scope and, for a follow-up pentest, what has changed since the previous test. If the executive summary opens with CVSS vectors, CVE IDs and technical details, the author most likely just moved part of the technical report into the first section.
Pentest methodology and scope: what was tested and what was left out
On its own, the phrase “no critical vulnerabilities found” says little about real risk. To understand what it means, you need to know what exactly was tested.
The report should make clear which assets were in scope: domains, IP addresses, APIs, mobile apps or other components. It should also state the type of testing (black box, grey box or white box) and the methodology the team followed.
For web applications, for example, this might be the OWASP Testing Guide or OWASP ASVS. For the overall structure of a penetration test, it might be PTES or NIST SP 800-115. Simply listing standards is not enough, though. The document should show how they actually shaped the testing.
The report should also show what the team did not test. For example, the report might say that denial-of-service (DoS) attacks were not performed to avoid disrupting live systems, or that phishing tests and other social engineering techniques were not part of the agreed scope.
Testing dates matter too. A report describes the state of a system at a specific point in time. Cyber threats evolve, and a new vulnerability may appear a month later.
Without all these details, even a good technical result is hard to interpret correctly.
Vulnerability findings: every finding must be reproducible
The main value of the technical section is not the fact that the pentester found something. What matters is that the client’s team can understand what happened, verify it themselves and fix the issue.
That is why a vulnerability description normally starts with a clear title and classification, followed by where the issue is located and how it shows up. If vulnerabilities are rated using CVSS, writing “High” or “Critical” is not enough. The report should show which parameters produced the score (this is the CVSS vector) and explain why the vulnerability received that rating.
Next come the reproduction steps. Engineers need complete information without having to ask follow-up questions. For web applications, this usually includes specific URLs and parameters, HTTP requests and responses, and test data. For infrastructure testing, it includes the relevant commands, configurations or other artifacts needed to confirm the result.
Artifacts and evidence are another key part of the report. Visual materials such as screenshots or log excerpts help verify a finding objectively and speed up the handover to the people fixing it.
The final key element of a vulnerability description is impact. A technical statement like “arbitrary code execution is possible” does not explain what this means for a specific company. If the issue threatens data security, for example by exposing customer data, allowing changes to financial information or compromising other systems, the report should state this separately.
It is this chain of issue → evidence → reproduction → impact that turns a technical finding into a result you can act on.
Recommendations: not “improve security,” but what exactly to change
After the report describes the issue, the next question is: what should we do about it? General advice like “update your software” or “strengthen access control” does not help much on its own. A good penetration testing report explains how to fix the cause of the specific problem.
If the issue comes from missing server-side validation, the report should specify where validation is needed. If a vulnerable library version is in use, it should name the component and the recommended version or another way to reduce the risk. If the issue is caused by a misconfiguration, it should show which setting needs to change.
Prioritization matters just as much. CVSS is a useful standardized metric, but it does not always reflect the real priority for a specific company. A vulnerability in an internet-facing component and the same issue in an internal system with restricted access may need to be fixed in a different order. We covered this in more detail in “What to Do After a Pentest.”
A good report is more than a list of tasks to fix. It helps set priorities and shows the team where to start.
Appendices: everything management doesn’t need, but engineers do
Not all technical details need to be in the main part of the report. Full HTTP requests and responses, additional evidence, the list of tested components, raw scan results and information about the tools used can go into appendices.
This makes the report easier to use for both audiences. Management gets a clear document without pages of technical noise, and engineers get the details they need to verify and fix the issues.
Red flags in a pentest report: when to send it back for revision
Some signs suggest the results need further discussion or clarification with the vendor:
- There is no clear description of the scope or of what was left out of it.
- The methodology is described as a formality, without explaining what was actually tested.
- The Executive Summary is full of technical jargon.
- Vulnerability severity ratings are not clearly justified.
- Reproduction steps or evidence are missing.
- Recommendations are too general, for example “improve security.”
- The fixes are not prioritized.
- It is impossible to understand which components were tested.
- The report looks like a template with only the company name and a few technical details changed.
- There is no way to ask the vendor questions about the findings after the report is delivered.
One or two of these issues do not necessarily mean the work is poor. But if a report lacks a clear scope, gives no reproduction details and offers only generic advice, it may need significant revision.
AI Pentest report
Automation can significantly cut the time needed for certain stages of a pentest, but it should not mean that the final report is produced without human review.
In AI Pentest, automation handles not only attack surface discovery and vulnerability detection, but also exploitation and building attack chains. A penetration tester then verifies the findings, takes responsibility for the final result and signs the penetration test report.
The report is designed to be useful not only as proof that a test was performed, but also as a working document for remediation. It is suitable for meeting international compliance requirements once the vulnerabilities are fixed. You receive it as soon as the pentest is complete, within four working days of placing your order.
Request an AI Pentest report sample
About AI Pentest: a42.tech/ai-pentest
