What to Expect in a Penetration Test Report

Executive Summary

The executive summary is written for non-technical readers like the CEO or board. It includes:

• Overall risk rating (e.g., Critical, High, Medium, Low) based on the average severity of findings.
• Business impact summary: what an attacker could achieve (data breach, account takeover, service disruption).
• Scope and methodology: what was tested (URLs, APIs, user roles) and the testing approach (black box, gray box, white box).
• Key metrics: number of findings by severity, hours spent, and sometimes a graph.

Technical Findings

This is the core of the report. Each finding is presented in a structured way. A typical finding includes:

• Vulnerability ID (e.g., VULN-001) and title (e.g., Stored XSS in User Profile).
• CVSS score (e.g., 8.2 High) with vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:N).
• Affected endpoint (e.g., POST /api/profile/update).
• Description of the vulnerability and its impact.
• Proof of Concept (PoC): step-by-step instructions and often a code snippet or screenshot showing the exploit.
• Remediation: specific fix (e.g., sanitize input, use parameterized queries, add CSRF token).

Proof of Concept (PoC) Details

Testers must prove each vulnerability is real. Expect to see:

• HTTP request/response examples (raw or via Burp Suite screenshots).
• Code snippets for custom exploits (e.g., a Python script for SQL injection).
• Browser screenshots showing the vulnerable state (e.g., XSS alert popup).
• Step-by-step instructions so your engineers can reproduce the issue in their own environment.

If the report lacks PoC, the finding may be a false positive. Always ask for reproduction steps.

Risk Ratings and Prioritization

Findings are ranked using the Common Vulnerability Scoring System (CVSS) v3.1. The report should include:

Note: CVSS doesn't always reflect business context. A medium-severity issue in a critical function may be more urgent than a high-severity issue in an isolated feature. Good reports include contextual risk commentary.

Remediation Guidance

Each finding should come with clear, actionable remediation steps. Examples:

• For SQL injection: Use parameterized queries or prepared statements. Validate input length and type.
• For broken access control: Implement server-side authorization checks for every request. Test with different user roles.
• For XSS: Output-encode user input based on context (HTML, JavaScript, CSS). Use Content Security Policy headers.

Good reports also provide a remediation summary grouping fixes by effort (quick wins vs. Architectural changes).

Retest Results

After you fix the reported vulnerabilities, you should request a retest. The final report usually includes a retest section that confirms which findings are closed, partially fixed, or still open. Some testers provide a separate retest report. Always ensure retesting covers all originally reported issues.

What a Good Report Looks Like

A professional penetration test report is clear, organized, and actionable. Look for:

• Consistent formatting with page numbers and table of contents.
• No vague language like "potential risk" without evidence.
• Realistic remediation timelines that match your development cycle.
• Contact information for the tester for follow-up questions.

If you want to get a feel for your own app's vulnerabilities before a full pentest, you can start a free scan with Kyro, an AI penetration tester that continuously hunts for real, reproducible vulnerabilities and emails you the findings.