Writing Pentest Reports
The ability to communicate technical findings clearly and persuasively is what makes a penetration tester valuable to clients. You will learn the structure of a professional web application pentest report, how to write findings that developers can actually act on, and how to present risk in business terms. A well-written report is often the difference between a vulnerability being fixed and being ignored.
Learning Objectives — Deep Dive
Each objective below is broken down into plain English so you know exactly what you are learning, why it matters, and what you will be able to do when you are done. Mark each one complete as you work through the lesson.
Organize findings by severity
Review all your raw notes, screenshots, and Burp Suite logs and create one finding entry per unique vulnerability. Assign a severity rating to each finding using the CVSS v3.1 calculator at first.org/cvss/calculator/3.1 — input the attack vector, complexity, privileges required, user interaction, scope, and impact values to generate an objective score. Group findings into a summary table sorted by severity (Critical first, then High, Medium, Low, Informational). This table gives the client an immediate overview of their risk exposure before they read the detailed findings.
Write the executive summary
The executive summary should be one to two pages maximum and written for a business audience with no technical background. State the engagement dates, scope, overall risk rating, the number of findings by severity, and the two or three most critical issues in plain language. Avoid technical jargon — instead of 'SQL injection in the login endpoint', write 'an attacker can bypass the login page and access all customer data without a password'. End with a brief recommendation paragraph that prioritizes the most urgent remediation actions. The executive summary is often the only section that senior management reads, so it must accurately convey the severity of the situation.
Write each technical finding
For each finding, write a self-contained entry that includes: a descriptive title, the affected URL or component, the HTTP request and response that demonstrate the vulnerability (formatted as a code block), step-by-step reproduction instructions, the business impact (what an attacker could do if they exploited this), and a specific remediation recommendation. The reproduction steps should be detailed enough that a developer who was not present during the test can reproduce the issue in their own environment. Vague findings such as 'the application has XSS' without a specific payload and URL are not actionable and will frustrate the development team.
Add evidence
Every finding must be supported by evidence: screenshots showing the vulnerability being triggered, HTTP request/response pairs from Burp Suite, command output, or video recordings for complex multi-step vulnerabilities. Annotate screenshots with arrows or boxes to highlight the relevant part — a raw screenshot of a 500-error page is less clear than one with the error message circled and labeled. Organize evidence in a logical order that follows the reproduction steps. Clients use your evidence to verify that the vulnerability is real and to demonstrate it to their development team during remediation.
Write remediation recommendations
For each finding, provide a specific, actionable remediation recommendation rather than a generic one. Instead of 'sanitize user input', write 'use parameterized queries (prepared statements) for all database interactions — replace the current string concatenation in the login function at line 47 of auth.php with a PDO prepared statement'. Reference the relevant OWASP prevention cheat sheet for each vulnerability class. Where possible, provide a code example showing the vulnerable code alongside the corrected version. Specific recommendations are more valuable to the client and demonstrate deeper expertise than generic advice.