Penetration Test Report Writing: From Findings to Executive Summary

A penetration test is only as valuable as its report. You can chain together a critical RCE and pivot through the entire internal network, but if your findings aren't documented clearly, the client won't understand the risk — and they won't fix it. This guide covers everything you need to produce professional, actionable pentest reports that hold up to scrutiny.

Report Structure Overview

A well-structured report has five core sections:

1. Cover Page & Table of Contents — client name, engagement dates, classification, author contact
2. Executive Summary — business-language overview for C-suite readers
3. Methodology & Scope — what was tested, how, and any limitations
4. Findings — the technical meat, one section per vulnerability
5. Appendix — raw tool output, full payloads, nmap scans, scope targets

Writing the Executive Summary

The executive summary is the most-read section, and it's written for people who won't read the rest. Keep it to one page. It should answer three questions:

• What was tested? — "A black-box external assessment of api.example.com covering authentication, authorization, and business logic."
• What did we find? — High-level severity breakdown with one-sentence descriptions
• What is the business risk? — Frame findings in terms of data breach potential, regulatory exposure, and operational impact

Avoid technical jargon here. Write "An attacker could access any customer's order history without authentication" instead of "IDOR via predictable integer IDs in the /api/orders endpoint."

CVSS Scoring Your Findings

Use CVSS v3.1 for every finding. The CVSS Calculator handles the math, but you must understand the vector string to justify your scores. The key metrics are:

• Attack Vector (AV) — Network, Adjacent, Local, or Physical
• Attack Complexity (AC) — Low (no special conditions) or High (specific conditions required)
• Privileges Required (PR) — None, Low, or High
• User Interaction (UI) — None or Required
• Scope (S) — Unchanged or Changed (can the attack affect components beyond the vulnerable component?)
• CIA Impact — None, Low, or High for Confidentiality, Integrity, Availability

A common mistake is inflating scores. An IDOR exposing non-sensitive data is not a 9.8. Use Temporal and Environmental metrics to adjust the base score for patch availability and client-specific context. Always include both the numeric score and the vector string: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N (7.5 High).

Writing Reproducible Steps to Reproduce

Every finding needs a complete, numbered steps-to-reproduce section that a developer can follow without your help. Include:

1. Prerequisites — authenticated as what role, what account state
2. Exact HTTP requests or tool commands
3. What to observe (the vulnerable response)
4. Expected behavior (what should happen instead)

Format HTTP requests in full:

POST /api/v2/users/1337/profile HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGc...<attacker_token>
Content-Type: application/json

{"email":"[email protected]"}

Then show the vulnerable response that confirms exploitation. Developers should be able to replay this in under five minutes using a tool like Burp Suite or curl.

Evidence Collection Best Practices

Good evidence removes all doubt. Collect evidence at the time of discovery — going back later often fails because sessions expire or state changes.

• Screenshots — Annotate with arrows or boxes to draw attention to the critical part. Include the URL bar.
• HTTP request/response pairs — Paste raw Burp Repeater output. Redact sensitive data that isn't needed to demonstrate impact (e.g., real PII once you've proved access).
• Video — For complex multi-step attacks or business logic flaws, a short screen recording (OBS, Loom) is far more convincing than screenshots alone.
• Tool output — Include nmap scan results, nuclei hits, and sqlmap extracts in the appendix. Use the Pentest Findings Documenter to structure and store this evidence as you work.

Risk Rating Justification

CVSS gives you a number, but risk ratings (Critical / High / Medium / Low / Informational) require judgment. A 7.5 CVSS base score on an internal-only endpoint with compensating controls may be rated Medium in context. Always document your reasoning:

Risk Rating: High
CVSS Base Score: 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N)
Justification: Any authenticated user (including free-tier accounts) can
modify or delete other users' records by changing the numeric ID in the
request. No compensating controls were observed. The application holds
PII covered by GDPR, making unauthorized access a reportable data breach.

Writing Specific Remediation Recommendations

Generic remediations are useless. "Sanitize user input" tells a developer nothing. Write actionable, technology-specific recommendations:

• Bad: "Implement proper access controls."
• Good: "On every request to /api/v2/users/:id, verify that the authenticated user's ID matches the :id path parameter before returning or modifying the record. Implement this check server-side in the authorization middleware (see UserController.js line 47)."

Where appropriate, include code snippets, CVE references, OWASP Testing Guide links, and estimated remediation effort (hours).

Common Reporting Mistakes

• Treating "I found something" as proof of impact — Always demonstrate actual impact, not just existence of the vulnerability.
• Inconsistent severity ratings — If you rate IDOR as Critical in one finding and High in another, justify the difference.
• Missing context for false positives — Scanner findings need manual validation. Never include tool output verbatim as a finding.
• Passive voice throughout — "An attacker can access..." is stronger and clearer than "Data may be exposed."
• No remediation verification section — Note whether the assessment included a remediation retest, and if so, what was confirmed fixed.

Deliverable Formats

Most clients expect a PDF with password protection (minimum AES-128). Some larger engagements also want an HTML version or a platform export for tools like Dradis or PlexTrac, which allow findings to be tracked through remediation workflows. Always include:

• A machine-readable findings summary (CSV or JSON) for vulnerability management ingestion
• Raw evidence files referenced in the report, organized by finding ID

Use the Pentest Findings Documenter throughout the engagement to capture findings in structured format as you discover them, making final report assembly much faster.