How to Write a Penetration Test Report

A penetration test report is the deliverable that turns authorized testing into decisions. Scope and penetration testing rules of engagement define what you may do; the report shows what you found, what it means to the business, and what to fix first.

Below you get section-by-section writing guidance, a finished executive summary example, a before-and-after wording table, one complete fictional finding example, and a copyable penetration test report template you can paste into Word or your report platform.

What a penetration test report should accomplish

Organizations commission penetration tests to understand whether weaknesses can be exploited and what those weaknesses could mean to the business. The report answers that question with evidence.

A useful report does three jobs at once:

• Gives executives a short, plain-language view of risk and priority fixes
• Gives engineers reproduction steps, impact, and remediation they can ticket
• Gives security leadership an audit trail: scope, methodology, dates, and who tested

PTES reporting and NIST SP 800-115 both treat the written report as a core assessment output, not an optional appendix. This guide also aligns with CompTIA PenTest+ reporting objectives if you are studying for the exam.

How reporting fits the engagement lifecycle

Reporting starts during the test, not the night before the deadline.

Tools such as Cervantes help store findings and export report sections. They do not remove the need for consistent wording, peer review, and client-specific scope language from penetration testing pre-engagement scoping.

Penetration test report structure

One PDF usually serves executives, engineers, and security operations. Each audience reads a different layer of the same facts.

Templates differ by firm, but the section order below appears in most client-ready reports.

Put scope and RoE near the front so a reader who joins six months later still knows what the numbers mean.

Write the executive summary

The executive summary is the most forwarded page. Many stakeholders never read past it.

Draft this section last, after findings are scored and reviewed. Keep it to roughly one or two pages.

Include:

• One paragraph on what was tested, when, and the assessment goal
• Overall risk posture in plain language (for example, "An external attacker could obtain customer records without authentication")
• A small table of finding counts by severity
• Two to four bullet points on the highest-impact risks, written as business outcomes, not CVE IDs
• Three to five strategic recommendations (themes such as "centralize secrets management," not "change line 42 in config.php")
• Optional note on strengths observed (MFA on VPN, timely patching on DMZ hosts)

Avoid in the executive summary:

• CVSS vector strings and tool output
• Long lists of every medium finding
• Jargon without translation ("Kerberoasting" alone means little to a CFO)

Penetration test report example: before and after

Weak wording states the vulnerability. Strong wording states what an attacker can do.

Example penetration test executive summary

The sample below uses the fictional Example Corp context from this guide (app.example.com, external gray-box web assessment). Adapt names, counts, and themes to your engagement.

Executive Summary — Example Corp External Web Assessment
Test dates: 2026-09-01 through 2026-09-15 | Report version 1.0 (Final)

Objective and scope
  Example Corp commissioned a gray-box external assessment of customer-facing
  web properties and the 198.51.100.0/24 perimeter per approved scope dated
  2026-08-28. The goal was to determine whether an Internet attacker could
  gain unauthorized access to customer data or production systems.

Overall posture
  Testing identified material weaknesses in the customer portal authentication
  layer. An unauthenticated attacker could access customer account data without
  valid credentials. Perimeter hardening on VPN and API endpoints was stronger;
  MFA on the corporate VPN prevented successful account access using
  password-only authentication during testing.

Findings summary: Critical 0 | High 1 | Medium 2 | Low 1 | Informational 1

Key business risks
  • Unauthenticated access to customer names and email addresses on the
    production portal (PT-001)
  • Outdated TLS configuration on a legacy API host that still accepts weak
    cipher suites (PT-003)
  • Missing security headers on the marketing site; standalone issue with
    limited direct data exposure (PT-004)

Strategic recommendations
  1. Remediate the portal SQL injection flaw immediately and retest
     authentication before the next release window
  2. Centralize TLS configuration review for all Internet-facing APIs
  3. Strengthen automated security testing for authentication and other
     high-risk application paths before deployment

Positive observations
  MFA enforcement on the corporate VPN prevented password-only authentication
  from resulting in remote access. Patch levels on DMZ Linux hosts were current
  for the September maintenance cycle.

If you practice on Metasploitable 2, draft one finding and one executive bullet from a real weakness you exploited. That habit transfers directly to client work.

Document scope, methodology, limitations, and assumptions

The methodology section defends your process. Auditors compare it to what the SoW promised.

State:

• Frameworks or standards you followed (PTES phases, OWASP WSTG categories, internal QA checklist)
• Assessment type from pre-engagement (external black-box, internal credentialed, web application only)
• Classes of tools (network scanner, web proxy, password audit, exploit framework) without turning the section into a vendor brochure
• CVSS version used for scoring, and whether report risk ratings derive from CVSS qualitative severity bands or use a separate client/firm methodology
• How you validated scanner output before reporting confirmed vulnerabilities

The scope section repeats or summarizes the approved asset list from the SoW, scope appendix, RoE, or other governing engagement document. It should match the language in those signed documents. If you discovered a host outside the listed range, note that you did not test it without written approval.

Limitations and assumptions

Record what constrained the assessment. Do not bury this only in a single methodology bullet.

Common limitations:

• Credentials for an admin portal or VPN were not provided
• One or more in-scope hosts were unreachable during the test window
• The engagement window was shortened after kickoff
• Destructive testing, denial-of-service, or social engineering was prohibited by the RoE
• A third-party SaaS platform was excluded even though the client uses it

Common assumptions:

• Staging configuration mirrors production for the components you tested
• Patches listed in the client's change window were applied before testing began
• Provided account roles match how staff actually use the application

Write technical findings

Each finding is a mini-report. Consistent field names make client ticketing easier.

Technical finding template

If your risk rating is derived directly from CVSS base score bands, say so in the methodology section. Otherwise keep risk rating (client or firm priority) separate from the CVSS base score.

Order findings by risk rating or exploitability, depending on what the client agreed in the SoW. Critical issues that chain to domain admin belong at the top even when a standalone medium finding has a higher CVSS base score on paper.

Reproduction quality bar

The steps to reproduce section is what separates a useful report from a scanner export.

Good reproduction steps name:

• The exact URL or host and port
• Required authentication context (role, cookie, API key placeholder)
• The request or command you ran
• What vulnerable behavior proves the issue
• What a fixed deployment should show instead

Manually validate scanner findings before reporting them as confirmed vulnerabilities. If a finding cannot be independently verified, document its validation status and supporting evidence rather than automatically assigning it a lower severity. A scanner hit may remain unconfirmed because of authentication requirements, intermittent conditions, inaccessible paths, environmental differences, RoE restrictions on exploitation, or evidence that supports the weakness without safe reproduction.

Complete example penetration test finding

The fictional finding below shows every field filled in. Hostnames and data are invented for app.example.com. The CVSS vector reflects only what the tester demonstrated: authentication bypass and read access to customer records. Integrity and availability impacts are set to None because modification or deletion was not shown.

Finding ID:     PT-001
Title:          Unauthenticated SQL injection in customer portal login
Risk rating:    High (derived from CVSS-B 7.0–8.9 = High per report methodology)
CVSS-B:         8.7 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N)
CWE:            CWE-89 (Improper Neutralization of Special Elements used in an
                SQL Command)
Affected asset: https://app.example.com/login

Description:
  The login endpoint processes the email parameter in a way that permits
  attacker-controlled input to alter the SQL query logic. Testing confirmed
  that an unauthenticated user could bypass authentication and access customer
  account data.

Evidence:
  - Burp Suite request/response pair BR-2026-0142 (stored in engagement vault)
  - Screenshot FIG-003 showing authenticated session without valid credentials
  - Screenshot FIG-004 showing customer name and email fields from /dashboard

Steps to reproduce:
  1. Open https://app.example.com/login in a browser or HTTP client.
  2. Submit POST /login with Content-Type: application/x-www-form-urlencoded
     and body: email=' OR '1'='1'--&password=anything
  3. Observe HTTP 302 to /dashboard with Set-Cookie: SESSION=...
  4. Request GET /dashboard with that cookie and confirm account data loads.
  5. Expected secure behavior: HTTP 401 or 403 with no session issued.

Impact:
  Unauthenticated authentication bypass and read access to customer account
  data displayed on the dashboard. In testing, customer names and email
  addresses from the application user table were visible. Database modification
  or deletion was not demonstrated during this assessment.

Remediation:
  - Replace SQL string concatenation with parameterized queries / prepared
    statements.
  - Validate the email field against expected application input as defense in
    depth; do not rely on validation as the SQL injection fix.
  - Deploy a temporary WAF rule only as a compensating control while the code
    fix is deployed.

References:
  - https://cwe.mitre.org/data/definitions/89.html
  - OWASP WSTG-INPV-05 (Testing for SQL Injection)

Status:         Open
Retest date:    N/A (initial delivery)
Retest result:  Pending

Build the attack narrative (when applicable)

Findings listed by severity help patching. When multiple weaknesses chain into a meaningful path, an attack narrative shows how they combine. Skip this section when findings are independent, such as several unrelated issues on a narrow web application assessment.

Use a short timeline or phased story when a chain exists:

1. Initial access (phished user, exposed service, stolen API key)
2. Privilege gain or credential access
3. Lateral movement or data access
4. Objective (domain admin, PII exfiltration simulation, payment tampering proof)

Name the finding IDs or titles at each step so engineers can map the story back to remediation tickets. The narrative should match evidence. Do not invent a dramatic path you did not demonstrate.

For lab practice, write a three-step narrative from your Metasploitable 2 session: weak SSH password, local privilege escalation, proof of access to sensitive files. Client reports use the same structure with different hostnames.

Score severity and prioritize business risk

CVSS provides a standardized technical-severity assessment based on the metrics included in the selected CVSS vector. The Base metrics describe intrinsic vulnerability characteristics; Threat and Environmental metrics can add current exploit context and deployment-specific context. CVSS does not, by itself, measure business risk or remediation priority for your client.

Do not alter a CVSS Base score simply to make it match your business-risk judgment. If the client uses a separate risk rating, document that rating and its rationale alongside the CVSS score.

Example finding header when risk rating is derived from CVSS v4.0:

Risk rating: High (per methodology: CVSS-B 7.0–8.9 = High)
CVSS-B:      8.7 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N)
CWE-89:      SQL Injection

Calculate vectors with the FIRST CVSS v4.0 calculator or your firm's approved tool. Copy the vector carefully; an invalid or mistyped metric can make the vector unusable or produce the wrong score.

Recommend remediation and document retesting

Remediation belongs in two places: a short fix under each finding, and a roadmap that respects client capacity. For control-type mapping, defense-in-depth layering, and worked examples across technical, administrative, operational, and physical controls, see pentest remediation and control mapping.

An example remediation roadmap might use:

These windows are planning examples, not universal SLAs. Some organizations require emergency mitigation for critical RCE within hours or days, while others align fixes to monthly change windows.

Note dependencies. Fixing session management before you close an authentication bypass can waste sprint time. Name suggested owners (application team, cloud platform, identity team) when the RoE allows it.

Each finding should carry status and retest fields from the template above. At the roadmap level, state which severities or finding IDs the contract includes for verification retest, and whether retest is a separate engagement.

Penetration test report template

Below is a copyable penetration test report template you can adapt for network, web application, internal, or external assessments.

Download: penetration-test-report-template.txt (plain text; paste into Word, Google Docs, or your report platform)

PENETRATION TEST REPORT TEMPLATE

[Client legal name]
Assessment: [External network / Web application / AD internal]
Report version: 1.0 (Final)
Classification: [Confidential]
Test dates: [YYYY-MM-DD] through [YYYY-MM-DD]
Lead tester: [Name, firm]

────────────────────────────────────────────────────────
1. EXECUTIVE SUMMARY

Scope: Testing covered [summary] per approved scope/SoW/RoE dated [date].
Overall result: [One sentence on risk to business objectives].

Findings summary:
  Critical: [n]   High: [n]   Medium: [n]   Low: [n]   Info: [n]

Key risks (business language):
  • [Outcome 1]
  • [Outcome 2]

Strategic recommendations:
  1. [Theme: identity hardening]
  2. [Theme: patch cadence]
  3. [Theme: monitoring]

────────────────────────────────────────────────────────
2. SCOPE, LIMITATIONS, AND ASSUMPTIONS

In scope: [CIDR, apps, cloud subs]
Out of scope: [Payroll, third-party SaaS, production DoS]
Limitations: [Credentials unavailable, hosts unreachable, etc.]
Assumptions: [Staging mirrors production, etc.]

────────────────────────────────────────────────────────
3. METHODOLOGY

Approach: [Gray-box external + credentialed internal]
Frameworks: [PTES, OWASP WSTG sections exercised]
CVSS version: [v4.0 / v3.1] — CVSS-B and risk rating mapping defined here

────────────────────────────────────────────────────────
4. FINDINGS SUMMARY

ID      Finding                              Severity   Status
PT-001  [Finding title]                      High       Open
PT-002  [Finding title]                      Medium     Remediated

────────────────────────────────────────────────────────
5. TECHNICAL FINDINGS (repeat per issue)

Finding ID: [PT-001]
Title / Risk rating / CVSS-B / CWE / Affected asset
Description / Evidence / Steps to reproduce / Impact / Remediation
References / Status / Retest date / Retest result

(See complete example finding above for a filled-in PT-001.)

────────────────────────────────────────────────────────
6. ATTACK NARRATIVE (when applicable)

Day 1 — [Step] (PT-00X)
Day 2 — [Step] (PT-00X)
Day 3 — [Step] (PT-00X)

[Omit this section when findings do not chain into a meaningful path.]

────────────────────────────────────────────────────────
7. REMEDIATION ROADMAP

0–30 days: [Immediate fixes]
30–90 days: [Short-term controls]
90+ days: [Long-term changes]
Retest scope: [Finding IDs or severities included]

────────────────────────────────────────────────────────
8. CONCLUSION AND POSITIVE OBSERVATIONS

Overall assessment: [One paragraph on residual risk and next steps]
Strengths observed: [Controls that worked; balanced close]

────────────────────────────────────────────────────────
9. APPENDICES

A. Scope asset list (from RoE)
B. Tool output (redacted)
C. Glossary

Store working notes in your project tool during the engagement so this outline fills in steadily rather than in one marathon session.

Quality control before delivery

QC catches wrong hostnames, stale screenshots, and severity drift between the executive summary and the findings table.

Run a structured review:

Peer review is not universal, but mature consulting teams commonly require peer or QA review before client delivery. Have a colleague attempt reproduction from your steps alone before you mark the report final.

Using AI safely when drafting reports

Generative AI can help with wording and organization. It cannot replace your evidence chain.

Acceptable uses:

• Turning rough bullet notes into clearer prose after you verify facts
• Checking readability of the executive summary on sanitized drafts

Unacceptable uses:

• Drafting reproduction steps you did not run
• Guessing CVSS vectors or CWE IDs
• Sending client hostnames, credentials, screenshots, or other engagement evidence to any AI service unless its use is explicitly permitted by your firm's policy, client agreement, and data-handling requirements

The signing tester owns accuracy. Run AI-assisted drafts through the same QC checklist as a fully manual report.

Common penetration test reporting mistakes

References

• NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment
• PTES — Reporting
• FIRST CVSS v4.0 specification
• FIRST CVSS v4.0 calculator
• FIRST CVSS v3.1 specification
• CWE — Common Weakness Enumeration
• OWASP Web Security Testing Guide

Summary

A penetration test report turns authorized work into priorities executives understand and fixes engineers can ship. Build it around two layers: a short executive summary in business language, and technical findings with evidence, CVSS-B scores (or other CVSS metric combinations you document), separate risk ratings where needed, and clear remediation.

Use the copyable template and the complete PT-001 example as starting points. Draft the executive summary after findings are final, add an attack narrative when multiple issues chain into business impact, and record retest status on every finding you expect the client to close.