A penetration test report serves three audiences with different needs: engineers who have to fix things, leadership who have to decide what matters, and auditors who have to evidence a control. A report that only serves one creates translation work after the engagement ends.
Three people read a penetration test report and want different things from it.
An engineer needs to reproduce the issue and know what to change. Leadership needs to know which findings matter and what the exposure is. An auditor needs scope, method, dates and closure. A report written for one of them makes the other two do translation work, and that translation becomes an unplanned project after the engagement ends.
The sections that earn their place
Executive summary. What was tested, what was found, what it means, in language a non-technical reader can act on. Not a severity count. A count answers "how many" when the question is "how bad".
Scope and method. What was in scope and what was excluded, both named explicitly. What access the tester had. When testing ran. What approach was taken. This section is what an auditor reads first and what makes the report usable as evidence.
Findings, individually. Each one needs: what was observed, how to reproduce it safely, why the impact matters in your context, and a practical remediation direction. Reproduction steps are the difference between a finding an engineer can act on and a finding an engineer has to first prove.
Remediation and retest record. What was fixed, when, verified how. The closed-loop record is the single most valuable page in the report for audit purposes, because it demonstrates the vulnerability management control functioning rather than merely the existence of a vulnerability.
Appendices. Tool output, request and response captures, enumeration results. Useful, and correctly placed at the back.
What makes a finding good
A finding worth its page answers four questions.
What. Not a category name. The specific observation, in this system.
How. Steps someone else can follow. If a finding cannot be reproduced from the report, the first thing an engineer does is spend an afternoon establishing whether it is real.
So what. Impact in context. A reflected cross-site scripting issue on an unauthenticated marketing page and the same class of issue in an authenticated application are not the same problem, and a severity label alone does not distinguish them.
Now what. A remediation direction, not just a link to a generic reference. "Validate the object identifier against the session's tenant in this endpoint" beats "implement proper access control".
Severity that reflects your system
CVSS measures technical severity. It does not know what your product does. A CVSS 9.8 on a host with no data and no network path is less urgent than a 6.5 on your authentication flow.
A report that ranks purely by CVSS has handed the prioritization work back to you. A report that ranks by exploitability and business impact, and explains the reasoning, has done the job. Both numbers can appear; the ordering should reflect the second.
How to tell a report from a scan with a cover page
Three checks.
Is anything in it specific to your application's logic? Not a library version or a missing header, which a tool found. Something about how your product works: a role that can reach something it should not, a workflow step that can be skipped, a tenant boundary that does not hold. If nothing in the report required understanding your product, nobody understood your product.
Were findings validated? A list of potential issues with no confirmation of exploitability is scanner output. Validation is what you are paying a person for.
Could this report have been produced against a different company? Swap the hostname. If it would read identically, it is a template.
The one-page version
Ask for a summary page you can hand to a customer or a prospect: scope, dates, method, the fact that findings were remediated and retested, with technical detail removed. Enterprise buyers ask for evidence of testing constantly, and a redacted summary answers them without circulating a map of how to attack you.
Separately: never send the full report to a prospect. It is a document describing how to compromise your system, and its distribution list should be short and deliberate.
Questions people ask
What should be in a penetration test report?
An executive summary in non-technical language, an explicit scope and methodology section with testing dates and the access level used, individual findings with reproduction steps and contextual impact, a remediation and retest record, and technical appendices.
How can you tell if a penetration test was actually performed by a person?
Look for findings specific to your application's logic rather than software versions and headers, evidence that findings were validated for exploitability, and detail that could not have been produced against a different company by swapping the hostname.
Can you share a penetration test report with customers?
Share a redacted summary covering scope, dates, method and the fact that findings were remediated and retested. The full report describes how to compromise your system and should have a short, deliberate distribution list.