Penetration Testing Report Template: Every Section, With Examples

A penetration testing report has to work for leadership, engineers, and auditors from one document. The template below does that, 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.

The complete template, with all ten sections pre-filled, is at the end of this page as Markdown you can paste into any editor: see copy the full template, or download the Word version (DOCX). If you would rather see the finished article, our sample penetration testing report shows the template filled in. Reporting on a vulnerability scan instead? Use our vulnerability assessment report template, which is built around scan results, validation and risk ranking rather than exploitation.

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 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, and it should describe impact in business terms (“an attacker could read every customer’s invoices”), not vulnerability classes (“insecure direct object reference”).

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. Our PTES explainer covers the engagement structure most reports follow. 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.

Severity definitions

Define the scale inside the report so every reader applies it the same way. The score bands below are the CVSS v3.1 qualitative rating scale published by FIRST. The other two columns are the definitions we use, and you can adapt them.

Severity	CVSS v3.1 score	What it usually means	Suggested priority
Critical	9.0 to 10.0	Direct compromise of sensitive data or systems with little effort, often without authentication or from any user account	Fix now; escalated the day it is confirmed
High	7.0 to 8.9	Serious impact that needs one precondition, such as a valid account or a second weakness	Fix in the current release cycle
Medium	4.0 to 6.9	A real weakness with limited impact alone, or one that becomes serious when chained	Plan into the next cycle
Low	0.1 to 3.9	A minor exposure or hardening gap with little direct impact	Fix as capacity allows
Informational	0.0 (None)	An observation or best-practice note with no direct security impact	Review; no fix required

A raw score alone misleads. A CVSS 9.8 on an isolated test server may matter less than a CVSS 6.5 that exposes your production customer database. That is why the template pairs the score with a business-adjusted severity that accounts for the asset, the exploitability in your environment, and whether the finding chains into something worse.

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

Add a short coverage note under the table: what was tested and held. Auditors need it, because it is what separates “we tested authentication and it held” from “we never got to authentication.”

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. The evidence and reproduction fields are where scanner-based “reports” collapse: a tool can name a vulnerability, but it cannot show a working exploit against your application with the exact steps.

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. Mapping each step to MITRE ATT&CK techniques also shows your defenders where detection should have fired.

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, and it is the section your engineering leads plan sprints from. Our guide to vulnerability remediation covers how to set the fix deadlines behind it.

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.

Want to see it filled in? Read the sample report, or get a fixed price for your own test. Every Invadel penetration test ships in this format, with the retest included.

Adapting the template: web app, API, network, cloud and mobile

The ten sections stay the same for every kind of test. What changes is the detail in the scope section, what each finding references, and where the report needs the most care.

Test type	Add to the scope section	Each finding references	Where to put the most care
Web application	URLs, application version, and every user role tested	OWASP Top 10 category, WSTG test ID, CWE	Detailed findings, with request and response evidence
API	Base paths, specification version, authentication methods, and the roles or tenants tested	OWASP API Security Top 10, CWE	Detailed findings, showing the same request made as each role
Internal network	IP ranges, Active Directory domains, and the starting access, such as a standard user account	MITRE ATT&CK technique, and the CVE where one applies	Attack narrative, from first foothold to Domain Admin or the agreed objective
External network	IP ranges and domains provided, plus assets found during reconnaissance and whether they were confirmed in scope	CVE, exposed service and version	Scope section and Appendix A, because a forgotten exposed asset is often a finding in itself
Cloud	Account, subscription or project IDs, regions, services, and the access role granted for the review	The CIS Benchmark control for that provider, where one applies	Detailed findings on identity and access paths
Mobile	App identifiers, build versions, platforms, and the backend API	OWASP MASVS control, MASTG test ID	Detailed findings, split between the app on the device and the API behind it

A red team report adds one more element: a timeline of what the team did and when, set against what your security team detected, so gaps in detection are as visible as the findings.

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. See ISO 27001 penetration testing.
• NYDFS 23 NYCRR 500 examiners expect annual testing from inside and outside the boundaries, with documented scope and remediation for covered financial firms. Our NYDFS cybersecurity regulation guide covers the rest of the regulation.

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

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.
• Generic descriptions pasted from a vulnerability database with no reference to your system.
• A “finding” that is a list of missing headers padded to fill pages.
• No attack narrative and no coverage note, only a flat list.
• 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 or a chart of scanner counts.

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 decides whether real breaches get found. 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.

Copy the full template

Paste this into your editor, replace everything in square brackets, and delete what does not apply. Prefer Word? Download the penetration testing report template (DOCX).

# Penetration Test Report: [Client], [Engagement name]

## 1. Cover and document control
Client: [Client] | Testing firm: [Firm]
Report version: [1.0] | Date issued: [date] | Classification: Confidential

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 | [date] | [name] | Initial report |
| 1.1 | [date] | [name] | Retest results added |

## 2. Executive summary
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.]

| Critical | High | Medium | Low | Informational |
|---|---|---|---|---|
| [x] | [y] | [z] | [w] | [v] |

Top findings and business impact: [one paragraph, no technical detail]
What was done well: [two or three controls that held]
Recommended priorities: [three to five actions, in order]
Status at time of issue: [findings already fixed and verified; retest date]

## 3. Scope and rules of engagement
In scope: [hostnames, IP ranges, URLs, API base paths, app versions, cloud accounts]
Out of scope: [exclusions and why]
Test accounts and roles: [roles provided; authenticated or unauthenticated]
Environment: [production / staging]
Testing window: [dates, hours, constraints]
Contacts and emergency stop: [names and phone numbers]
Assumptions and limitations: [anything that reduced coverage]

## 4. Methodology and standards
Standards: [OWASP WSTG / OWASP API Security Top 10 / MASVS / PTES /
NIST SP 800-115 / MITRE ATT&CK]
Phases: reconnaissance, enumeration, vulnerability analysis, exploitation,
post-exploitation, reporting.
Severity: CVSS v3.1 base score, adjusted for business impact and
exploitability in [Client]'s environment. Each adjustment is explained
in the finding.

| Severity | CVSS v3.1 | Definition |
|---|---|---|
| Critical | 9.0 to 10.0 | [definition] |
| High | 7.0 to 8.9 | [definition] |
| Medium | 4.0 to 6.9 | [definition] |
| Low | 0.1 to 3.9 | [definition] |
| Informational | 0.0 | [definition] |

## 5. Summary of findings
| ID | Title | Severity | Affected asset | Status |
|---|---|---|---|---|
| F-01 | [title] | [severity] | [asset] | [Open / Fixed, verified] |

Coverage: [areas tested that held]

## 6. Detailed findings
### F-01: [Title]
Severity: [rating] (CVSS [score], [vector]) | Status: [Open]
Affected: [endpoint, host, or component]
Description: [the weakness, in the context of this system]
Impact: [what an attacker can achieve, in business terms]
Evidence: [redacted request and response, or screenshot]
Steps to reproduce:
1. [step]
2. [step]
Remediation: [the specific fix]
References: [OWASP / CWE / vendor advisory]

## 7. Attack narrative
[How the testers moved from first access to the objective, step by step,
citing the finding IDs and MITRE ATT&CK techniques used at each step.]

## 8. Remediation roadmap
Fix now: [finding IDs]
This month: [finding IDs]
This quarter: [finding IDs]
Root causes: [shared causes behind several findings]

## 9. Retest results
| ID | Original severity | Retest date | Result | Evidence |
|---|---|---|---|---|
| F-01 | [severity] | [date] | [Fixed / Partially fixed / Not fixed] | [note] |

## 10. Appendices
A. Hosts, URLs, and endpoints tested
B. Tools and versions
C. Raw scanner output (unvalidated)
D. Glossary
E. Attestation letter

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. In a deal, the buyer’s cybersecurity due diligence review usually asks for the latest report and the retest results.

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.

Which severity scale should the report use? The CVSS bands shown above, adjusted for business context, are the usual choice, and CVSS v4.0 keeps the same score bands as v3.1. What matters most is that the scale is defined in the report and applied the same way to every finding.

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, an attack narrative, a coverage note, a remediation roadmap, and verified retest results.

See Invadel’s sample penetration testing report for the standard in practice, or scope your assessment to get a fixed price.