Penetration Test Report Writing

Prerequisites

• Understanding of the vulnerability classes you'll document
• Note-taking throughout the engagement — you cannot reconstruct quality evidence after the fact
• Completed engagement — report writing starts during testing, not after

Report Structure Overview

A professional penetration test report has two distinct audiences within the same document.

The Executive Summary

The executive summary is the most-read section. Most executives will read only this.

Write for a non-technical audience. Assume they understand business risk, not SQL injection.

What to Include

What NOT to Include

• CVE numbers or CVSS scores
• Tool names or technical exploit details
• Raw command output
• Jargon ("SQL injection", "Remote Code Execution") — translate to business impact instead

CVSS Scoring

CVSS (Common Vulnerability Scoring System) v3.1 is the standard for vulnerability severity. Use it consistently.

Base Score Metrics

Severity Ranges

Example: Unauthenticated RCE via public API
AV:N / AC:L / PR:N / UI:N / S:C / C:H / I:H / A:H
Score: 10.0 (Critical)

Writing a Technical Finding

Each finding should follow a consistent structure. Inconsistency between findings looks unprofessional.

Finding Template

## [Finding Title]

**Severity**: Critical / High / Medium / Low / Informational
**CVSS Score**: 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
**CWE**: CWE-89 (SQL Injection)
**Affected Asset(s)**: https://api.target.com/users/search

---

### Description

What the vulnerability is. 2-3 sentences, technically accurate.
Explain the root cause.

### Impact

What an attacker can do if they exploit this. Be concrete.
Quantify where possible: "access to 50,000 user records".

### Evidence

[Screenshot of the exploit working]
[Command used and output]

Request:
GET /api/search?q=' OR 1=1--

Response:
HTTP/1.1 200 OK
{"users": [{"id":1,"email":"admin@target.com"...}]}

### Remediation

Specific, actionable fix steps.

1. Use parameterised queries / prepared statements
2. Validate and sanitise all user input
3. Apply principle of least privilege to database account

### References

- https://owasp.org/www-community/attacks/SQL_Injection
- CWE-89: https://cwe.mitre.org/data/definitions/89.html

Taking Notes During Testing

Quality evidence requires systematic note-taking during the engagement — not after.

Finding Severity: Common Mistakes

Remediation Writing

Bad remediation advice destroys a finding's value. Your client needs to know exactly what to do.

Bad: "Fix the SQL injection vulnerability."

Good:

1. Replace string concatenation in the login function (auth.php, line 47) with
   PDO prepared statements.
2. Apply input validation: reject non-alphanumeric characters in the username field.
3. Configure the database user (app_user) to have SELECT/INSERT only on the
   users table — revoke EXECUTE and admin privileges.
4. Review all other database queries in the codebase for the same pattern using:
   grep -n "SELECT.*\$" *.php

Report Quality Checklist

Operational Notes

• Take notes live — the quality of your evidence correlates directly with how consistently you capture it during testing. There's no recovering a fuzzy screenshot or half-remembered command after the engagement.
• One finding per issue — don't bundle five SQL injection instances into one finding to save time. List them separately or clearly note all affected endpoints. Clients need to track remediation per item.
• Retest and update — if the client fixes findings and you retest, mark each finding Resolved / Partially Resolved / Open with a comment. Retested reports have a higher perceived value.
• Sensitivity — your report contains instructions to compromise the client's systems. Handle delivery securely: encrypt the PDF (password-protected + key delivered separately), use a secure file transfer, confirm the recipient.
• Client calls — always offer a debrief call to walk through findings. Many clients won't fully understand written findings until explained verbally.

What to Read Next

• Reconnaissance — the engagement methodology section should document your recon approach
• Exploitation — the evidence you document in findings comes directly from your exploitation steps
• OWASP Testing Guide — the standard reference for web application findings and remediation