DVWA Pentest Report Lab 2026 — Write a Professional Penetration Test Report From Your DVWA Findings | Hacking Lab2

This article is a practical guide for writing professional penetration test reports, using DVWA (Damn Vulnerable Web Application) as the practice target. It addresses the critical gap between finding vulnerabilities technically and communicating those findings in a way that drives client action and business decisions. The article argues that report writing is the professional skill that separates practitioners who discover vulnerabilities from those who get hired to find them, and provides a complete template, structure, and worked examples for creating portfolio-quality pentest deliverables.

• Professional pentest reports follow fixed section structureThe article specifies an exact industry-standard section order: cover page, executive summary (one page maximum), scope and methodology, findings summary table, technical findings organized by severity, remediation roadmap, and appendices. Deviating from this structure adds friction because clients and security teams expect to find specific information in predictable locations. This consistency applies across findings too—the CVSS score placement must be identical in finding 8 as in finding 2.
• Executive summary must eliminate all technical jargonThe article emphasizes replacing vulnerability names with business impact statements. Instead of 'SQL injection,' write 'the ability to read the entire user database.' Instead of 'stored XSS,' write 'code that runs in any visitor's browser and can steal their login session.' The opening should lead with overall risk level (not finding count), and end with one specific, named, achievable action the client should take immediately. The article notes this section is the most-read and least-well-written part of most reports.
• CVSS v3.1 scores must be calculated preciselyThe article forbids guessing at CVSS scores and requires using the calculator at first.org/cvss/calculator/3.1 for every finding. It covers the six base metrics: Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope, and the three impact metrics (Confidentiality, Integrity, Availability). A critical distinction highlighted: Scope = Changed (boundary violation, such as web app to OS) significantly increases scores—command injection with Scope = Changed scores 9.0 instead of 8.8, reflecting real-world OS-level compromise impact.
• Each technical finding requires standardized complete formatEvery finding must include: title, severity level, CVSS score with vector string, affected URL/parameter, description, numbered reproduction steps, evidence references (figure numbers), business impact statement, and remediation recommendation citing specific source code file and line. The article provides a worked example for SQL injection showing this format. The finding write-up explains what an attacker can DO, not what the vulnerability IS—this distinction is emphasized as critical for client comprehension.
• Evidence requirements scale with severity levelCritical findings require maximum evidence: screenshot of exploit payload, screenshot of response with sensitive data, Burp Suite request and response captures, and numbered reproduction steps. High findings need a screenshot, Burp request, and reproduction steps. Medium findings need screenshot or request plus steps. Low/informational findings need only a brief description with optional screenshot. Screenshots must include URL bar for verification, be annotated with red boxes pointing to key details, and be captioned with figure numbers referenced in the report text.
• Remediation recommendations must cite source code specificsGeneric guidance like 'implement proper input validation' is unacceptable. Instead, recommendations must name the exact file, line number, and correct implementation—for example, citing DVWA's Impossible security level source code (sqli/source/impossible.php) to show the specific prepared statement syntax that fixes the SQL injection vulnerability. This specificity demonstrates professional rigor and gives developers a concrete fix to implement, not abstract principles.
• Three exercises build the complete report progressivelyExercise 1 (20 minutes) triages all findings by severity and creates a one-sentence business impact statement for each, producing the Findings Summary Table. Exercise 2 (25 minutes) calculates CVSS scores for all findings using the calculator. Exercise 3 (30 minutes) writes the complete report using the accumulated materials, building sections in order: structure setup, findings table, technical findings (Critical first), scope/methodology, then executive summary last. By this sequence, all scoring and evidence work is complete before narrative writing begins.
• Report writing skill determines marketability and retentionThe article argues that junior practitioners often find vulnerabilities correctly but fail to communicate findings in ways that make clients act or hiring managers understand their competency. The author reports reviewing hundreds of applications where technical work was solid but reports did not tell a story clients could act on. A completed DVWA pentest report serves as a portfolio piece for interviews and a template adaptable to first paid engagements. The owner's own first consultancy role came from a self-directed DVWA report written as practice.

Bottom line: A complete, professionally structured penetration test report with clear executive summary, accurate CVSS scores, evidence-backed technical findings, and source-informed remediation recommendations is the deliverable that separates vulnerability researchers from hired security professionals; the specific section structure, non-technical business language, and standardized finding format transform raw technical findings into documents that drive client action and demonstrate professional competen