What a Penetration Testing Report Should Contain (With Example Structure)

The report is the penetration test. Everything else, the scoping, the weeks of testing, the exploitation, exists to produce one document that your engineers can fix from, your executives can decide from, and your auditors can accept. Yet most buyers never see a report until they have already paid for one, and many discover only then that they bought thirty pages of scanner output with a logo on the front.

This guide covers what a penetration testing report should contain, section by section, how each audience uses it, the structure a good one follows, and the red flags that tell you a report is not worth the paper. If you want to see the real thing, you can request our redacted sample report and hold any vendor’s deliverable to the same standard.

Who reads a penetration testing report

A good report serves three audiences at once, and its structure exists to keep them from tripping over each other.

• Executives and the board want to know how exposed the organization is, what it would cost if the worst finding were exploited, and whether the situation is under control. They read one to two pages.
• Engineers and IT want to reproduce each finding, understand exactly what to change, and verify the fix. They read the technical findings in detail.
• Auditors and customers want evidence that testing happened, that it was independent, what it covered, and that findings were remediated. They read scope, methodology, and the retest section, and they map findings to their framework.

A report that serves only one of these audiences fails the other two. The most common failure is a report written for engineers that leaves executives with nothing they can act on, followed closely by the reverse.

The anatomy of a good report

1. Executive summary

One to two pages, written in plain language, that a non-technical director can read in five minutes. It should state the overall risk posture, the number of findings by severity, the two or three issues that matter most and what an attacker could do with them expressed in business terms (“an attacker could read every customer’s invoices,” not “insecure direct object reference”), and the recommended priorities. If the executive summary is a table of CVSS scores, the report was not written for its audience.

2. Scope and methodology

Exactly what was tested: applications, URLs, IP ranges, environments, user roles, and the dates of testing. Equally important, what was excluded and why. Then the methodology followed, ideally mapped to a recognized standard such as the Penetration Testing Execution Standard or OWASP, and the type of test (black, gray, or white box). Auditors rely on this section to confirm the test covered the systems in their framework’s scope, so vagueness here creates audit problems months later.

3. Findings, one per issue

Each finding is the core unit of the report and should contain the same fields every time:

• Title and unique identifier, so the finding can be tracked in your ticketing system
• Severity rating, with the rationale (see the next section)
• Description of the weakness in the context of your system, not a generic definition pasted from a database
• Evidence: the request and response, screenshot, or command output that proves the finding is real
• Reproduction steps precise enough for your developer to trigger the issue independently
• Business impact: what an attacker could actually achieve, in terms your leadership understands
• Remediation guidance specific to your stack and situation, not a copied OWASP link
• References to the relevant standard, CWE, or vendor advisory

The evidence and reproduction fields are where scanner-based “reports” collapse. A tool can name a vulnerability; it cannot show you a working exploit against your application with the exact steps.

4. Risk ratings that mean something

Most reports use CVSS scores, which are useful as a common language but misleading on their own. A CVSS 9.8 on an isolated test server may matter less than a CVSS 6.5 that exposes your production customer database. A good report presents both the technical score and a business-adjusted severity that accounts for the asset’s importance, the exploitability in your specific environment, and whether the finding chains into something worse. The rating scale should be defined in the report so everyone reads it the same way.

5. Attack chains and narrative

The clearest signal of genuine manual testing. Where several individually modest findings combined into a serious path, a good report tells that story: the exposed service that revealed a version, the version that had a known weakness, the weakness that yielded credentials, the credentials that reached the domain. Attack narratives, ideally mapped to MITRE ATT&CK techniques, are what turn a list of issues into an understanding of how your organization would actually be breached. Scanners cannot produce them.

6. Positive findings and coverage

What was tested and found to be sound. This section is undervalued by buyers and essential to auditors, because coverage evidence is what proves the test was thorough rather than lucky. A report that lists only problems gives no way to distinguish “we tested authentication and it held” from “we never got to authentication.”

7. Remediation roadmap

A prioritized plan, not just a list. Which findings to fix first and why, which can be batched, quick wins versus structural changes, and any compensating controls for issues that cannot be fixed immediately. This is the section your engineering leads plan sprints from.

8. Retest results

After you remediate, a good engagement includes a retest that verifies each fix actually closed the finding and did not introduce a regression. The final report should reflect the retested status of every finding, so the document your auditor receives shows remediation verified rather than claimed. At Invadel the retest is included in every penetration test rather than sold separately, which is also why our pricing is fixed rather than a running meter.

9. Appendices

Full tool output where relevant, complete lists of tested endpoints or hosts, the rules of engagement, and any raw data your team may want. Appendices keep the main body readable while preserving everything for the engineers who want it.

Example structure

A well-organized report generally follows this outline:

1. Cover page: client, engagement, dates, version, confidentiality marking
2. Document control and distribution
3. Executive summary
4. Scope, rules of engagement, and methodology
5. Summary of findings by severity (table)
6. Attack narrative and chained findings
7. Detailed findings (one section per finding, consistent fields)
8. Positive findings and coverage
9. Remediation roadmap
10. Retest results
11. Appendices

The length varies enormously with scope; what should not vary is that every one of these sections exists. Our sample report follows this structure and is available on request before you commit to anything.

How auditors use the report

If your test exists for compliance, the report needs to be consumable by the people checking the box.

• SOC 2 auditors look for independence, scope covering the in-scope systems, methodology, and evidence that findings were tracked to remediation. The retest section is what closes that loop. See SOC 2 penetration testing.
• PCI DSS requires the report to show internal and external testing, segmentation validation where applicable, and the methodology used, with findings remediated and retested. See PCI DSS penetration testing.
• ISO 27001 treats the report as evidence of technical vulnerability management and control effectiveness for the ISMS.
• NYDFS 23 NYCRR 500 examiners expect annual testing with documented scope and remediation for covered financial firms.

A report that maps findings to the relevant controls saves your compliance team from doing that translation by hand, which is why we format ours for the framework you tell us about during scoping.

Red flags of a bad report

• Findings with no evidence and no reproduction steps
• Generic descriptions copied from a vulnerability database with no reference to your system
• Severity ratings that are raw CVSS with no business context
• No attack narrative and no chained findings, only a flat list
• No positive findings or coverage section, so you cannot tell what was actually tested
• Remediation guidance that is a link to an OWASP page
• An “executive summary” that is a chart of scanner counts
• No retest, or a retest sold as a separate line item

If a sample report shows several of these, the underlying “penetration test” was almost certainly an automated scan. Our comparison of penetration testing vs vulnerability scanning explains why that distinction determines whether real breaches get found.

Frequently asked questions

How long is a typical penetration testing report? Anywhere from fifteen pages for a small, clean application to well over a hundred for a large network with many findings. Length is not a quality signal; structure and evidence are.

Should I get a sample report before hiring a vendor? Yes, and a serious vendor will offer one unprompted. It is the single most reliable way to judge what you will receive. If a firm will not show a redacted sample, treat that as the answer.

Can the report be shared with customers or auditors? The full report contains sensitive detail and is usually shared only with auditors under confidentiality. Many organizations request a separate attestation letter or summary for customers, which a good vendor will provide.

What is the difference between a penetration testing report and a vulnerability assessment report? A vulnerability assessment report lists identified weaknesses, often from automated scanning, without proving exploitability. A penetration testing report demonstrates which weaknesses are exploitable, chains them, and shows real impact. The VAPT guide covers how the two fit together.

The short version

A penetration testing report should let an executive decide, an engineer fix, and an auditor accept, all from one document. Look for an actionable executive summary, precise scope, findings with evidence and reproduction steps, business-adjusted severity, attack narratives, coverage evidence, a remediation roadmap, and verified retest results. Judge every vendor by their sample before you sign.

Request Invadel’s redacted sample report to see the standard, or scope your assessment to get a fixed price.