This chapter covers the critical domain of writing penetration test reports for the CompTIA PenTest+ PT0-002 exam. Effective reporting is the primary deliverable of any penetration test and is heavily tested on the exam, accounting for approximately 10–15% of the questions. You will learn the structure, content, and best practices for producing professional, clear, and actionable reports that meet client needs and comply with industry standards. Mastery of this topic ensures you can communicate findings effectively, a skill that distinguishes competent penetration testers.
Jump to a section
A penetration test report is like the final autopsy report prepared by a medical examiner after a complete post-mortem investigation. The examiner doesn't just list the cause of death; they document every finding—each incision, each organ examined, each toxicology result—in a structured, reproducible manner. The report must be so precise that another examiner could repeat the exact procedure and reach the same conclusions. In the same way, a penetration test report must detail every step taken, every tool used, every command executed, and every finding discovered, with enough clarity that a peer reviewer or client could replicate the test. The autopsy report prioritizes findings: the immediate cause of death (critical finding), contributing factors (high/medium findings), and incidental observations (low/informational findings). It also includes a timeline, chain of custody, and recommendations for prevention. Similarly, a pen test report ranks vulnerabilities by severity, includes a timeline of activities, maintains evidence integrity, and provides remediation guidance. Just as an autopsy report is a legal document that must withstand scrutiny, a pen test report is a contractual deliverable that must be defensible in court or audit. The medical examiner does not speculate—they only report what the evidence supports. Likewise, a penetration tester must avoid overstating risk or making unsubstantiated claims; every statement must be backed by evidence. The analogy breaks down only in that a pen test report is proactive for security improvement, whereas an autopsy is reactive to a death, but both share the core purpose of thorough, objective documentation for accountability and future prevention.
What is a Penetration Test Report?
A penetration test report is the formal document that communicates the results of a security assessment. It is the primary deliverable to the client and serves as a record of the test methodology, findings, evidence, and recommendations. The report must be comprehensive, accurate, and understandable to both technical and non-technical stakeholders. It typically includes an executive summary, a technical findings section, and appendices with supporting data.
Why the Report is Critical
While the technical execution of a penetration test is important, the report is what the client pays for. A poor report can undermine even the most thorough test. The report serves multiple purposes:
It provides legal and compliance documentation.
It guides remediation efforts.
It demonstrates the value of the test to management.
It can be used as evidence in audits or legal proceedings.
Report Structure (CompTIA PenTest+ Recommended)
The PT0-002 exam emphasizes a standard report structure. The following components are typically included:
1. Executive Summary - Target audience: Senior management, C-suite, non-technical stakeholders. - Content: High-level overview of the test scope, objectives, and key findings. It should avoid technical jargon. Include a risk rating summary (e.g., Critical, High, Medium, Low) and an overall risk posture statement. - Example: "The assessment identified 2 critical vulnerabilities that could allow an external attacker to gain full administrative access to the internal network. Immediate remediation is recommended for these issues."
2. Methodology - Describes the approach used, including reconnaissance, scanning, exploitation, and post-exploitation phases. - References standards such as NIST SP 800-115, OWASP Testing Guide, or PTES. - Should be detailed enough for repeatability.
3. Findings and Vulnerabilities - The core technical section. Each finding should include: - Title: Clear, descriptive name (e.g., "SQL Injection in Login Form"). - Severity: Critical, High, Medium, Low, Informational. - CVSS Score: If using CVSS v3.1, include the vector string. - Description: Technical explanation of the vulnerability. - Affected Systems: IP addresses, hostnames, applications. - Impact: Potential business or security impact. - Evidence: Screenshots, logs, command outputs, proof-of-concept code. - Remediation: Step-by-step fix instructions. - References: CVE numbers, CWE IDs, external links.
4. Risk Rating - Typically uses a matrix combining likelihood and impact. Common frameworks: CVSS, DREAD, or custom client-defined. - The exam expects familiarity with CVSS v3.1 scoring and its components (Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope, Confidentiality, Integrity, Availability).
5. Recommendations - Prioritized list of remediation actions based on risk. - Should be actionable and specific (e.g., "Apply patch KB5001234 to all Windows servers" rather than "Keep systems updated").
6. Appendices - Detailed logs, tool output, scan results (e.g., Nmap, Nessus, Burp Suite). - Glossary of terms. - List of tools used with versions. - Screenshots and code snippets.
Writing Style and Best Practices
Be objective: State facts, not opinions. Use phrases like "The scan revealed" instead of "We think."
Be clear: Avoid ambiguous language. Define acronyms on first use.
Be concise: Use bullet points and tables where possible. Keep sentences short.
Be actionable: Every finding should have a clear remediation step.
Be professional: Use proper grammar, spelling, and formatting. The report represents your company.
Common Pitfalls (Exam Traps)
Overstating risk: Do not label a low-severity issue as critical just to sound impressive. The exam tests if you can correctly apply CVSS or risk rating.
Missing evidence: A finding without supporting evidence is weak. The exam may present a scenario where a finding lacks screenshots or logs, and you must identify the deficiency.
Ignoring the audience: The executive summary must be non-technical; the technical section must be detailed. Mixing them up is a common mistake.
Not including a methodology: Without a methodology, the report lacks credibility. The exam may ask what is missing from a sample report.
Key Components in Detail
#### Executive Summary - Length: Usually 1–2 pages. - Key elements: Test objectives, scope, overall risk level, top findings (top 3–5), and a high-level remediation roadmap. - Example language: "During the engagement, testers successfully exploited a critical vulnerability in the web application that allowed access to the customer database. This could lead to data breach and regulatory fines. Immediate patching is recommended."
#### Technical Findings - Each finding should be individually numbered or referenced. - Use a consistent template. Example: - Finding ID: F-001 - Title: Unauthenticated Remote Code Execution in Apache Struts - Severity: Critical - CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - CVSS Score: 9.8 - Affected Systems: 192.168.1.10:8080 (Apache Struts 2.3.30) - Description: The application is vulnerable to CVE-2017-5638, which allows unauthenticated remote code execution via the Content-Type header. - Evidence: See Appendix A for proof-of-concept exploit and screenshot. - Remediation: Upgrade Apache Struts to version 2.3.32 or later. - References: CVE-2017-5638, CWE-94
#### Risk Rating - The exam expects you to calculate or interpret CVSS scores. Remember:
- Critical: 9.0–10.0 - High: 7.0–8.9 - Medium: 4.0–6.9 - Low: 0.1–3.9 - Informational: 0.0 - Know the base metric groups: Exploitability metrics (AV, AC, PR, UI), Impact metrics (C, I, A), and Scope (S).
#### Remediation - Should be specific: include exact commands, configuration changes, or patch versions. - Example: "Disable directory listing in the web server by setting 'Options -Indexes' in the Apache configuration." - Prioritize by risk: critical first, then high, etc.
Report Delivery and Handling
Reports are often delivered in PDF format with password protection.
The client may require a debrief meeting to walk through findings.
Follow data handling policies: encrypt the report in transit and at rest, and ensure only authorized recipients have access.
Some clients require a sanitized version for distribution to a wider audience (e.g., removing sensitive details).
Legal and Ethical Considerations
The report should include a disclaimer limiting liability.
Include a confidentiality statement.
The report is the property of the client; do not share without permission.
Ensure all testing was authorized and within scope.
Interaction with Other Domains
Reporting ties into the entire penetration test lifecycle: from scoping and rules of engagement to the final deliverable.
The report must reflect the methodology used (e.g., black-box, white-box) and any limitations encountered.
Communication skills are tested in the Reporting and Communication domain (Objective 4.1).
Verification and Quality Assurance
Before delivery, the report should be reviewed by a peer or lead tester.
Verify that all findings are reproducible and evidence is accurate.
Check for consistency in severity ratings and terminology.
Ensure no client confidential data is leaked (e.g., passwords in screenshots).
Tools for Report Generation
Many penetration testers use templates in Microsoft Word, LaTeX, or Markdown.
Automated tools like Dradis, Faraday, or Serpico can help aggregate findings from multiple tools and generate reports.
The exam does not require specific tool knowledge, but familiarity with common report-generation tools is beneficial.
Exam Focus on Report Components
The PT0-002 exam will present scenarios where you must identify missing sections, correct errors, or choose the best wording for a report. For example:
A sample report lacks an executive summary. What should you add?
A finding is rated as Critical but the CVSS score is 6.5. Is this correct? (No; 6.5 is Medium.)
The report includes technical jargon in the executive summary. What is the issue? (It should be understandable to non-technical management.)
Conclusion
Mastering report writing is essential for passing the PT0-002 exam and for a successful career in penetration testing. The report is the final product that demonstrates your professionalism and technical competence. Focus on structure, clarity, and evidence-based findings. Practice by creating sample reports from your own lab exercises.
Gather and Organize Evidence
Before writing, collect all evidence from the engagement: screenshots, logs, command outputs, tool reports (e.g., Nmap, Nessus, Burp Suite), and notes. Organize findings by severity or by attack path. Ensure each piece of evidence is timestamped and linked to a specific finding. This step is critical because missing evidence weakens the report. Use a folder structure like /Evidence/Critical/, /Evidence/High/, etc. Also, verify that no sensitive data (e.g., real passwords, PII) is included in evidence that will be shared with the client.
Write the Executive Summary
Draft a high-level overview for management. Summarize the test scope, objectives, and overall risk posture. List the top 3–5 most critical findings in plain language. Avoid technical terms like 'SQL injection'—instead say 'a flaw in the login page that could allow an attacker to access the database.' Include a risk rating (e.g., 'Overall risk is High due to two critical vulnerabilities'). Keep it to 1–2 pages. This section is often the only part read by executives, so it must be clear and impactful.
Detail the Methodology
Describe the testing approach: reconnaissance, scanning, exploitation, post-exploitation, and reporting. Reference a standard methodology like NIST SP 800-115 or OWASP Testing Guide. Include the tools used (with versions) and any limitations (e.g., 'Testing was limited to business hours only'). This section adds credibility and allows the client to understand how findings were obtained. It should be detailed enough that another tester could replicate the test.
Document Each Finding
For each vulnerability, create a structured entry with title, severity, CVSS score, description, affected systems, impact, evidence, remediation, and references. Use a consistent template. Provide enough detail for the client's technical team to understand and fix the issue. Include proof-of-concept code or screenshots as evidence. For example, for a SQL injection, show the malicious input and the resulting data leak. Ensure each finding is independently verifiable.
Review and Deliver the Report
Perform a quality assurance review: check for spelling/grammar errors, verify CVSS scores, ensure evidence matches findings, and confirm that no confidential data is exposed. Have a peer review the report for technical accuracy. Then, convert to a secure PDF (password-protected) and deliver via an encrypted channel (e.g., SFTP, encrypted email). Schedule a debrief meeting to walk through findings with the client. Finally, securely delete or archive the report according to the data handling policy.
Enterprise Scenario 1: Financial Institution PCI DSS Compliance
A large bank requires an annual penetration test for PCI DSS compliance. The report must be structured to satisfy both the QSA (Qualified Security Assessor) and the bank's security team. The executive summary highlights that the bank's external perimeter is secure, but internal segmentation testing revealed a critical vulnerability allowing lateral movement from the DMZ to the cardholder data environment (CDE). The technical section includes detailed CVSS scores, evidence of pivot via a vulnerable web application, and step-by-step remediation (e.g., 'Implement firewall rules to restrict traffic from DMZ to CDE to only required ports'). The report also includes a 'Compensating Controls' section for findings that cannot be immediately remediated. Common pitfalls: overstating risk to force remediation, or failing to include enough evidence for the QSA. The report is delivered as a password-protected PDF with a separate signed letter of attestation.
Enterprise Scenario 2: Healthcare Provider After Merger
A hospital network recently merged with another entity and needs a post-merger security assessment. The penetration test covers both legacy systems and new cloud-based patient portals. The report must be understandable to both technical staff and the board of directors. The executive summary emphasizes that the merger introduced several high-risk misconfigurations in Active Directory, allowing potential privilege escalation. The technical section includes findings from internal network scans, Active Directory enumeration, and web application tests. A critical finding is that the legacy patient portal uses outdated TLS 1.0, which is a violation of HIPAA security rules. Remediation includes specific configuration changes (e.g., 'Disable TLS 1.0 and enable TLS 1.2 on IIS server 192.168.2.50'). The report also includes a risk acceptance form for findings the client chooses not to fix. Common mistakes: using overly technical language in the executive summary, or failing to prioritize findings by business impact.
Scenario 3: E-commerce Company During Peak Season
An online retailer hires a penetration tester to assess their web application before Black Friday. The test is time-boxed to one week. The report must be delivered quickly, so the tester uses a template and automated report generation from tools like Dradis. The executive summary highlights that the payment page is vulnerable to cross-site scripting (XSS), which could lead to session hijacking. The technical section includes CVSS scores, screenshots of the XSS payload executing, and remediation code (e.g., 'Add output encoding using OWASP Java Encoder'). The report also includes a 'Critical Patch' section for findings that must be fixed immediately. The tester schedules a debrief the day after delivery. A common pitfall is rushing and making calculation errors in CVSS scores, which the client's security team catches. The report must be accurate to maintain credibility.
PT0-002 Exam Focus on Report Writing
Objective 4.1: Explain the importance of communication during the penetration testing process. This objective directly covers report writing. The exam tests your ability to identify proper report structure, correct errors in sample reports, and choose appropriate language for different audiences.
Common Wrong Answers and Why Candidates Choose Them: 1. Choosing 'Technical Details' for the Executive Summary: Candidates often think executives want technical depth, but the executive summary must be non-technical. The exam presents a sample executive summary with technical jargon; the correct answer is that it should be simplified. 2. Selecting 'Low' Risk for a Finding with CVSS 8.5: A CVSS score of 8.5 is High, not Low or Critical. Candidates may misremember the CVSS ranges. Remember: 7.0–8.9 is High, 9.0–10.0 is Critical. 3. Omitting Evidence from a Finding: The exam may show a finding without screenshots or logs, and ask what is missing. The correct answer is 'Evidence' or 'Proof of concept.' 4. Including Remediation in the Executive Summary: While the executive summary may mention high-level steps, detailed remediation belongs in the technical section. The exam tests proper placement.
Specific Numbers and Terms That Appear on the Exam: - CVSS v3.1 scoring ranges (Critical 9.0–10.0, High 7.0–8.9, etc.) - The five phases of penetration testing: Reconnaissance, Scanning, Exploitation, Post-Exploitation, Reporting. - Common report sections: Executive Summary, Methodology, Findings, Recommendations, Appendices. - Terms: 'Risk Rating', 'CVSS Vector', 'Severity', 'Remediation', 'Evidence'.
Edge Cases the Exam Loves: - Informational Findings: The exam may present a finding with CVSS 0.0 and ask for the correct severity rating. Answer: Informational. - Scope Creep in Report: If a finding is out of scope, it should be documented separately or noted as an observation, not included in the main findings. - False Positives: The report should note if a finding is a false positive and why. - Multiple Audiences: The same report must serve both technical and non-technical readers. The exam may ask how to achieve this (e.g., separate executive summary and technical sections).
How to Eliminate Wrong Answers: - If a question asks about the executive summary, eliminate options that include technical details or specific IP addresses. - If a question involves CVSS, calculate the score or know the ranges. The exam often provides the CVSS vector string; you must interpret it. - If a question asks what is missing from a report, look for the absence of an executive summary, methodology, or evidence. - Use the 'audience' rule: management gets summary, technical team gets details.
The penetration test report must include an executive summary, methodology, findings with evidence, risk ratings, remediation, and appendices.
CVSS v3.1 severity ranges: Critical 9.0-10.0, High 7.0-8.9, Medium 4.0-6.9, Low 0.1-3.9, Informational 0.0.
Every finding must be supported by evidence such as screenshots, logs, or proof-of-concept code.
The executive summary should be written for non-technical management, avoiding jargon and focusing on business impact.
Risk rating should consider both CVSS score and environmental/business context; not just the base score.
Remediation steps must be specific and actionable, including exact commands, patches, or configuration changes.
A methodology section referencing standards like NIST SP 800-115 or OWASP adds credibility and repeatability.
Reports should be delivered securely (encrypted PDF) and followed by a debrief meeting with the client.
These come up on the exam all the time. Here's how to tell them apart.
Executive Summary
Audience: Senior management, non-technical stakeholders
Content: High-level overview, risk posture, top findings
Length: 1-2 pages
Language: Non-technical, business-focused
Purpose: Provide quick understanding of overall security state
Technical Findings Section
Audience: IT staff, security engineers, developers
Content: Detailed vulnerability descriptions, evidence, remediation steps
Length: Can be dozens of pages
Language: Technical, includes commands, code, and configurations
Purpose: Enable precise remediation and verification
Mistake
The executive summary should include all technical details.
Correct
The executive summary is for non-technical management and should only include high-level findings, risk posture, and business impact. Technical details belong in the findings section.
Mistake
CVSS score is the only factor in risk rating.
Correct
CVSS provides a base score, but risk rating also considers environmental and temporal factors, as well as business context. The exam may ask you to adjust risk based on client-specific factors.
Mistake
Findings without evidence are acceptable if the tester is confident.
Correct
Every finding must be supported by evidence (screenshots, logs, etc.). Without evidence, the finding is not verifiable and may be dismissed. The exam tests this by presenting a finding lacking evidence.
Mistake
The report should only include vulnerabilities that were successfully exploited.
Correct
The report should include all findings, including those not exploited but identified as potential risks. For example, an open port that was not exploited should still be documented as an informational finding.
Mistake
Remediation steps can be vague, like 'apply patches'.
Correct
Remediation must be specific and actionable. For example, 'Apply Microsoft security patch KB5001234 to all Windows Server 2019 systems' is better than 'Keep systems updated.'
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A standard penetration test report should include an executive summary, a methodology section, a detailed findings section (with severity, CVSS scores, evidence, and remediation), recommendations, and appendices. The PT0-002 exam expects this structure. The executive summary is for management; findings are for technical teams. Without any of these sections, the report is incomplete.
The CVSS v3.1 vector string (e.g., CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) contains metrics that determine the base score. The exam may provide the vector and ask for severity. You can use the CVSS calculator online, but for the exam, know that a score of 9.0-10.0 is Critical, 7.0-8.9 is High, etc. The vector above yields 9.8 (Critical). Practice interpreting vectors.
Yes, but document them separately, often in an appendix or as an observation. Clearly state why they are false positives. This demonstrates thoroughness and avoids confusion. The exam may test this by presenting a finding that was not actually exploitable; the correct response is to note it as a false positive.
Out-of-scope findings should be documented in a separate section or an appendix, clearly labeled as 'Out of Scope.' Do not include them in the main findings. The exam may present a scenario where a tester discovered a vulnerability in an out-of-scope system; the correct action is to note it separately and inform the client verbally.
The executive summary is for non-technical stakeholders and focuses on business risk, top findings, and high-level recommendations. A technical summary (sometimes called 'Technical Findings Overview') is for the technical team and may include more detail but still less than the full findings section. The exam expects you to know that the executive summary should avoid jargon.
Yes, tools like Dradis, Faraday, or Serpico can aggregate findings and generate reports. However, you must review and customize the output to ensure accuracy and clarity. The exam does not require tool-specific knowledge, but you should be aware that automated reports may need manual refinement.
Prioritize based on risk severity: Critical and High findings first, then Medium, then Low. Also consider business impact, ease of exploitation, and asset value. The exam may ask you to order recommendations correctly in a sample report.
You've just covered Writing Penetration Test Reports — now see how well it sticks with free PT0-002 practice questions. Full explanations included, no account needed.
Done with this chapter?