Penetration Testing Report Template: Every Section, With Examples

A penetration testing report has three readers with three different questions. Leadership wants to know how bad it is. Engineers want to know how to reproduce and fix each finding. Auditors and customers want to know what was tested, by whom, and whether the serious findings were closed. The template below serves all three, and it is the structure every Invadel report follows. Copy it, adapt the wording, and use it to judge the reports you receive from any vendor.

If you would rather see the finished article, our sample penetration testing report shows the template filled in.

The template at a glance

1. Cover and document control
2. Executive summary
3. Scope and rules of engagement
4. Methodology and standards
5. Summary of findings
6. Detailed findings (one entry per finding)
7. Attack narrative
8. Remediation roadmap
9. Retest results
10. Appendices

1. Cover and document control

Keep it boring and complete: client name, engagement name, report version, date issued, classification (typically Confidential), the testing firm, and a document history table. Auditors check dates and versions first.

2. Executive summary

One to two pages, written for someone who will read nothing else. It should answer five questions in plain language.

Template wording:

Between [start date] and [end date], [Firm] performed a [type] penetration test of [scope in one line] on behalf of [Client]. The objective was to identify vulnerabilities an attacker could exploit to [reach the assets that matter].

Overall risk: [Critical / High / Medium / Low]. [One sentence on the most significant attack path found.]

We identified [N] findings: [x] critical, [y] high, [z] medium, [w] low, and [v] informational. [One paragraph describing the top two or three findings and their business impact, without technical detail.]

What was done well. [Two or three controls that held, so the summary is honest rather than only alarming.]

Recommended priorities. [Three to five actions in order, each in one line.]

Status at time of issue. [Findings fixed and verified during the engagement, if any, and the retest schedule.]

Include a small table of findings by severity and a single chart if the audience likes them. Avoid CVE numbers, tool names, and payloads here.

3. Scope and rules of engagement

State exactly what was in scope and what was excluded, so nobody later assumes a system was tested when it was not.

• In scope: hostnames, IP ranges, applications with URLs, API base paths, mobile app versions, cloud account identifiers.
• Out of scope: anything explicitly excluded and why.
• Test accounts and roles provided, and whether testing was authenticated.
• Environment: production, staging, or both.
• Testing window and any constraints (business hours only, systems to handle with care, denial-of-service excluded).
• Rules of engagement: points of contact, emergency stop procedure, data handling.
• Assumptions and limitations: access that was not granted, systems unavailable during the window, anything that reduced coverage.

4. Methodology and standards

Name the standards the test followed so the reader can cite them: OWASP Web Security Testing Guide and ASVS for web applications, OWASP API Security Top 10 for APIs, MASVS and MASTG for mobile, PTES and NIST SP 800-115 for engagement structure, MITRE ATT&CK for network and adversary techniques. Describe the phases briefly (reconnaissance, enumeration, vulnerability analysis, exploitation, post-exploitation, reporting) and state how severity was rated.

Template wording for severity:

Severity ratings combine CVSS v3.1 base scores with an assessment of business impact and exploitability in [Client]’s environment. A finding may be rated above or below its CVSS score where the context justifies it; each such adjustment is explained in the finding.

5. Summary of findings

A single table that engineers and auditors will both use as an index.

ID	Title	Severity	Affected asset	Status
F-01	Broken object-level authorization on /api/invoices	Critical	api.example.com	Open
F-02	Password reset token predictable	High	app.example.com	Fixed, verified
F-03	Missing rate limiting on login	Medium	app.example.com	Open

6. Detailed findings

One entry per finding, always in the same format. This is the part engineers read, so precision matters more than prose.

Template:

F-01: Broken object-level authorization on /api/invoices

Severity: Critical (CVSS 9.1). Status: Open.

Affected: GET /api/v2/invoices/{id} on api.example.com.

Description. The endpoint returns any invoice by numeric identifier without checking that the invoice belongs to the authenticated user’s organization. Identifiers are sequential.

Impact. Any authenticated user can read every customer’s invoices, including names, addresses, and amounts. Combined with F-04, an unauthenticated attacker can reach the same data.

Evidence. Request and response excerpts with sensitive values redacted, or a screenshot, showing account A retrieving account B’s record. Include the exact steps to reproduce.

Remediation. Enforce an ownership check server-side on every object access; return 404 rather than 403 to avoid confirming existence; replace sequential identifiers with random ones; add an authorization test to the API test suite.

References. OWASP API1:2023 Broken Object Level Authorization; CWE-639.

Two rules keep this section honest. Every finding must be proven, with the evidence in the entry. And every finding gets a remediation that names the fix, not just the flaw.

7. Attack narrative

For network and red team engagements especially, a short story of how the testers moved from first access to the objective, with a diagram if it helps. It connects the findings into the path an attacker would use and shows leadership why a medium and a low together were a critical.

8. Remediation roadmap

Findings grouped into what to fix now, this month, and this quarter, with root causes called out where several findings share one (for example, “no server-side authorization layer” behind F-01, F-05, and F-07). A roadmap turns a list into a plan.

9. Retest results

After fixes, the same findings table with updated status and a note on each retested item: verified fixed, partially fixed, or not fixed, with evidence. At Invadel the retest is included and the report is reissued with this section completed, which is the version auditors and customers should receive.

10. Appendices

• Full list of hosts, URLs, and endpoints tested.
• Tools used and their versions.
• Raw scanner output if the client wants it, clearly marked as unvalidated.
• Glossary for non-technical readers.
• The attestation letter, if issued as part of the report package.

What a bad report looks like

Use the template in reverse to judge what you receive. Warning signs:

• Findings with no evidence or reproduction steps.
• Severities copied from a scanner with no context.
• A “finding” that is a list of missing headers padded to fill pages.
• No scope section, or a scope that does not match what you asked for.
• No retest, or a retest that costs extra.
• An executive summary that is a paragraph of boilerplate.

Our guide to what a penetration testing report should contain covers the reasoning behind each section, and the sample report shows the finished product. If you are choosing a vendor, the RFP template asks for a sample report before you sign, which is the quickest way to find out whether you will get this template or the bad version.