Writing a Penetration Test Report

Prerequisites: Completion of all four previous projects in this roadmap, with at least one documented finding from each; Pandoc installed for the Markdown-to-PDF mission step (optional but recommended).

Targeted versions: Verified against the Penetration Testing Execution Standard (PTES) reporting phase structure, the OWASP Web Security Testing Guide's reporting guidance, and FIRST's CVSS documentation — CVSS v4.0 has been the current FIRST standard since November 2023, though CVSS v3.1 remains extremely common in vendor advisories, CISA KEV entries, and compliance-driven reports (PCI DSS-oriented engagements in particular still frequently report v3.1 primarily), so real-world reports often include both. This project teaches v4.0 as the current standard while noting where and why v3.1 still shows up in practice.

Here's an uncomfortable truth every working pentester learns eventually: the exploitation is the interesting part, but the report is the actual product a client is paying for — nobody outside your own team will ever see your terminal history, they'll only ever see the document you hand them. A brilliant exploit chain that gets summarized as "found SQL injection, medium severity" in a report a stakeholder can't parse is a wasted engagement. This project takes the findings you've already produced across this roadmap's four previous projects and assembles them into a real, PTES-structured report — the same skeleton, CVSS scoring approach, and executive-summary discipline used in actual industry engagements.