What Does a Penetration Test Report Actually Look Like?

Most clients see a penetration test report for the first time after their engagement ends. The test is done, the tester has left the environment, and now there's a document sitting in their inbox — sometimes 40 pages, sometimes 80 — and nobody on the client side was ever told how to read it.

That's a waste of an expensive assessment. The report is the deliverable. It's what you bought. If your team doesn't know what each section means, which findings require action this week versus next quarter, or what to bring to leadership vs. what to hand to IT — the intelligence you paid for stays locked in a PDF that nobody fully acts on.

This guide explains what a professional penetration test report actually contains, what each section is supposed to do, and what separates a high-quality report from one that's mostly automated output with a cover page.

The Executive Summary — What Leadership Needs to Read

The executive summary is the first section and the one most people skip, assuming it's boilerplate. In a well-written report, it's the most important part of the document for anyone who isn't in IT.

A good executive summary does three things. It gives a plain-language risk rating for the engagement — not a CVSS score, not a count of findings, but an honest statement about the overall security posture of the environment that was tested. It highlights the top two or three findings in terms that a non-technical reader can understand. And it describes what an attacker could realistically accomplish if they exploited the most significant vulnerabilities found during testing.

What the executive summary should not be: a page of logos, a glossary of security terms, or a paragraph that says "the assessment identified several areas for improvement." That last phrase appears in reports that are protecting the provider, not informing the client. A real executive summary will name the findings and their consequences.

If your executive summary could apply to any company's network without changing a word, it wasn't written for your engagement — it was copied from a template.

Leadership needs to understand whether their business is at serious risk right now or not. That answer belongs in the first page of the report, not buried in the technical appendix.

The Findings Section — What Each Finding Actually Contains

The technical findings section is the core of the report. Each finding is a discrete vulnerability or weakness that was identified and, in a proper pentest, actually tested for exploitability. Here is what every finding entry should contain.

If any of those elements is missing, the finding is incomplete. A finding that says "misconfigured admin interface detected" with no evidence and no remediation guidance is not actionable. Your IT team can't fix something they can't locate, and leadership can't prioritize something they can't understand the impact of.

Critical vs. High vs. Medium — What Severity Ratings Actually Mean

Severity ratings matter because they determine remediation priority. But they're frequently misunderstood, and sometimes misapplied by testers who want to soften difficult findings or inflate a report with more impressive-sounding results.

Here is what each severity level actually means in practical terms.

Critical means the vulnerability is exploitable right now, without authentication, and gives an attacker significant access to your environment. Remote code execution on an externally facing server is critical. An unauthenticated admin interface exposed to the internet is critical. These represent immediate risk of a real breach. Remediation should begin within 24 to 72 hours of receiving the report, not at the next change management meeting.

High means significant access is possible, but typically requires either authentication, insider access, or some additional condition to exploit. An attacker who is already inside your network and finds a high-severity finding can escalate dramatically from there. High findings should be remediated within 30 days.

Medium means the vulnerability requires multiple conditions to exploit, or its direct impact is limited without chaining other findings. Mediums are not benign — they become high or critical when combined with other findings. But they don't require emergency response.

Low is security hygiene. Informational issues, minor misconfigurations, outdated software that isn't publicly known to be exploitable. Handle these in your normal patch cycle, but don't deprioritize them forever.

One warning sign in a low-quality report: all findings clustered in the medium range with nothing critical or high. This happens when a tester runs automated scanning tools and reports the output without doing any manual exploitation work. Real environments, tested by humans, almost always produce at least a few high-severity findings. An absence of them usually means the test wasn't thorough, not that your environment is perfect.

Evidence — Why Screenshots Matter

A quality penetration test shows you what was accessible, not just that a vulnerability existed. This is not a minor distinction.

If a report says "administrative panel accessible via unauthenticated HTTP endpoint" but provides no evidence, you have no way to verify whether the tester actually accessed the admin panel or just identified a potential path to it. Those are very different findings. The first means an attacker was, demonstrably, inside your management interface. The second means a tool flagged something that might be a problem.

Good evidence in a pentest report looks like this: a screenshot of the admin panel with the tester's session visible, showing the exact level of access they achieved. Or a terminal output showing a privilege escalation from a standard user account to domain administrator, with each command and its result. Or a document showing that the tester was able to read a sensitive file that should have been inaccessible — with the file name, path, and content visible in the screenshot.

Evidence also makes the report credible to leadership and to auditors. If your cyber insurance carrier or a compliance auditor asks you to demonstrate that the test was conducted properly, evidence-backed findings provide that documentation. A report with no screenshots and no command output is difficult to defend in either context.

The Remediation Section — What You Are Expected to Do With This

Most professional pentest reports include remediation guidance for each finding. What clients sometimes miss is that the guidance is meant to be acted on, not filed.

Prioritizing remediation correctly is straightforward in principle: start with critical findings, then high, then medium, then low. In practice, there are two common mistakes. The first is trying to fix everything at once — which usually means nothing gets fixed properly because the team is context-switching between too many issues simultaneously. The second is handling all findings as a batch, running them through a slow change management process that pushes even critical fixes out six or eight weeks.

Critical and high findings do not belong in a normal change management queue. They should be reviewed by IT leadership the day the report arrives and assigned to specific owners with specific deadlines. Medium and low findings can follow your standard process.

One practical approach: export the findings into a spreadsheet with four columns — finding name, severity, assigned owner, and target remediation date. Share it with IT leadership at the debrief meeting. That single document transforms the report from a PDF that sits in an inbox into a remediation project with accountability.

The Retest — And Why It Matters

After you remediate the findings, the work is not finished until a retest confirms that the fixes actually worked. This step is frequently skipped, and it's one of the more common ways that findings that appeared to be resolved turn out to still be exploitable.

Retests are usually scoped as a subset of the original engagement — the tester revisits only the specific findings that were remediated and verifies that the vulnerability no longer exists or is no longer exploitable. This is different from a full re-engagement, and it's typically much shorter and less expensive.

Before you sign the scope of work for a penetration test, ask whether a retest is included or available as an add-on. Some providers include it in the flat engagement price. Others offer it as a separate, smaller engagement. Either is acceptable. What's not acceptable is completing remediation work and having no way to verify that it was effective.

For compliance purposes — PCI DSS, in particular — a documented retest showing that remediated findings are resolved is often required as part of the evidence package. Understanding how pentests differ from vulnerability scans helps clarify why the retest matters: a scanner can tell you that a patch was applied, but only a manual retest can confirm that the underlying access path is actually closed.

Red Flags in Low-Quality Pentest Reports

Not all penetration test reports are created equal. Here is what to look for when evaluating whether the report you received represents real testing or automated scanning with a branded cover page.

If you received a report that matches several of these descriptions, you may have paid for automated scanning rather than a manual penetration test. Before your next engagement, ask the provider directly: will a human tester attempt to exploit the findings, and will the report include evidence of what was accessed? Get the answer in writing as part of the scope of work.

A thorough internal network test, conducted properly, should surface findings that no scanner would catch — misconfigurations, credential reuse, overpermissioned accounts, trust relationships that create lateral movement paths. If your report contains nothing but CVEs matched against a patch database, ask your provider what manual testing was actually performed. Understanding what happens during an internal network penetration test gives you the right questions to ask before you sign.