What a Professional Pentest Report Should Include

I have seen companies pay for a pentest and receive a PDF generated by an automated tool with the vendor's logo on the cover. Technically, it is a "report". In practice, it is not good for much.

This is a real problem in the market. Someone buying the service for the first time has no way of knowing what they should be receiving — so anything looks good enough.

This post exists to change that. If you are evaluating vendors, or have just received a report and do not know whether what you are holding is any good, this content will help you make that call.

First: the report is not the pentest

Before discussing the document itself, one thing needs to be clear: the report is the record of what was done, not the pentest itself. A good report reflects good work. If the testing was shallow, the report will be shallow too — regardless of how many pages it has.

That said, the report is the only concrete deliverable you have in hand. It is what will guide remediation, serve as evidence for audits, and justify the investment internally. So it needs to be good.

What a professional report should contain

Executive summary

This section is for you, not for your technical team. It should be written in plain language, without acronyms that need explaining, and answer basically three questions: what was tested, what was found, and what the real risk to the business is.

If you are a manager or CTO and need 20 minutes to understand the executive summary, it was poorly written. That section should take 5 minutes to read and make it clear what needs immediate attention.

Severity ratings with context

Every report has some rating system — critical, high, medium, low. The problem is when everything shows up as critical, or when the rating ignores the company's context.

A vulnerability in an internal system reachable only through the VPN has a different impact than the same vulnerability on a public endpoint. A professional report makes that distinction. It is not just technical severity — it is the real risk given how your environment works.

Real evidence of exploitation

This is one of the things that most sets manual work apart from an automated scan. For each relevant vulnerability, there should be evidence that it was actually exploited — not merely detected.

That means screenshots, full HTTP requests, the payloads used, and the server's response. If the report says there is SQL Injection but does not show the query that was executed or the data that was extracted, you have no way of knowing whether it is a false positive or a real flaw.

Recommendations someone can actually follow

A recommendation like "implement more robust authentication" is useless. The developer reading it has no idea what to do with that information.

A good recommendation specifies the problem, explains why it exists, and describes how to fix it — preferably with a technical reference or an implementation example. It does not need to solve the problem for the client, but it does need to point to a clear path.

Separation between the executive view and the technical view

These are two different audiences with different needs. The CFO who will approve the remediation budget does not need to know what an IDOR is. The developer who will implement the fix does not need to read four pages of business context.

A well-structured report separates these two layers. You can share the executive section with leadership and the technical section with the development team without editing anything.

Documented scope and methodology

The report should make clear what was tested and what was out of scope. It sounds obvious, but many companies receive a "clean" report without realizing that half of their systems were not included.

Methodology matters too. Knowing that the test followed OWASP, PTES, or another recognized reference gives you a baseline for comparing it with other work and understanding the level of coverage that was applied.

What a bad report usually contains

For balance, it is worth listing what frequently shows up in low-quality work:

A list generated by Nessus or a similar tool with no manual analysis. Hundreds of vulnerabilities with no real prioritization. Generic recommendations that could have been written by anyone without ever seeing the system. No evidence of exploitation. And the classic: a report that could belong to any company, because it contains no specific reference to the environment that was tested.

If the report you received looks like this, it is worth questioning the vendor.

How to use the report afterwards

The report does not end when you finish reading it. The proper cycle is: receive the report, prioritize remediation by severity, implement the fixes, and retest to confirm the vulnerabilities have actually been closed.

A serious vendor offers support during this phase — at the very least to answer questions about the vulnerabilities and confirm whether the fixes were adequate. If they delivered the PDF and disappeared, that is a bad sign.