Writing a Complete, Professional Pentest Report

Everything you have done so far, planning, reconnaissance, analysis, exploitation and post-exploitation, has value only once it reaches the client in a form they can actually use. The report is the real deliverable of a penetration test. This lesson walks through the structure of a professional report and how to write each section well.

A surprising truth of this profession: many experienced testers consider report writing their single most important skill, more than any specific exploitation technique. A brilliant technical finding, badly explained, gets ignored or misunderstood. A clearly explained, well-prioritised moderate finding gets fixed. This lesson teaches you to write the former kind.

Who actually reads a pentest report

A single report usually serves at least three very different readers, and a good structure serves all three at once:

• Executives and decision-makers, who need to understand business risk and decide on budget and priority, without necessarily understanding technical detail.
• Technical teams, who need enough precise detail to actually reproduce and fix each finding.
• Auditors or compliance reviewers, who may need to confirm that a specific scope was tested thoroughly and that findings are tracked over time.

The standard structure

1. Executive summary

A short section, usually one page or less, written entirely without jargon, for the first reader type above. It states the overall objective of the test, the general level of risk found, the number of findings by severity, and the single most important message the client should take away. A good test: could a non-technical reader explain the main risk after reading only this section?

2. Scope and methodology

A clear restatement of what was tested, when, by whom, and following which approach (recall chapter 1's black, grey or white box discussion), referencing the signed authorisation. This section also states, honestly, the balance between automated and manual testing (chapter 3) and any limitation on time or coverage, exactly the transparency principle discussed earlier in this course.

3. Findings, from highest to lowest severity

This is the technical heart of the report. Each finding should follow a consistent template, so that the reader can quickly find the information they need:

• Title: short, specific, descriptive (not "web vulnerability" but something that names the actual issue and its location).
• Severity: using a clear, explained scale (for example critical, high, medium, low, informational), ideally grounded in the same kind of reasoning as chapter 3's prioritisation factors: technical severity combined with real exposure and business value, not a raw score alone.
• Description: what the weakness is, in plain but precise language.
• Evidence: the specific proof, screenshots, saved tool output, or safe confirmation commands and their results, exactly the kind of evidence your journal and evidence folder have been accumulating since chapter 1.
• Impact: what a real attacker could realistically achieve, grounded in what you actually confirmed, not in speculation beyond what you tested.
• Recommendation: a specific, realistic, actionable fix, following the "finding leads to specific action" principle from chapter 5.
• References: links to relevant, authoritative sources, limited to this course's allowed list, such as the specific OWASP page describing the category of weakness, or the specific CVE record if applicable.

4. Risk summary table

A single table listing every finding with its severity, affected system, and a short status field (left blank for the client to track remediation over time), giving a quick, scannable overview that complements the detailed findings section.

5. Conclusion and overall recommendations

Beyond the individual findings, broader, strategic observations: patterns noticed across several findings (for example, "several issues trace back to a lack of network segmentation", echoing chapter 4's pivoting lesson), and recommendations for improving security processes over time, not just fixing the specific items found this time.

6. Appendices

Detailed technical output, full tool logs, and the list of in-scope systems actually tested, useful to technical teams and auditors without cluttering the main body of the report for other readers.

Writing each finding well: a worked example

Compare these two ways of describing the same finding:

Weak version: "The login page has a problem with passwords. This should be fixed soon."

Strong version: "Title: Missing account lockout on the customer login page. Severity: Medium (exploitation requires sustained effort and network access, but the data accessible afterwards is customer personal data). Description: during testing, a controlled, limited number of incorrect login attempts were submitted against a test account, within the scope and intensity agreed with the client; no lockout or rate limiting was observed after multiple failures. Evidence: timestamped log of attempts and responses (see Appendix B). Impact: an attacker with a plausible candidate password list could attempt many guesses without being slowed down or locked out, increasing the likelihood of a successful account takeover over time. Recommendation: implement progressive rate limiting and account lockout after a reasonable number of failed attempts, combined with multi-factor authentication so that a guessed password alone cannot grant access. References: OWASP guidance on authentication (owasp.org)."

The strong version is specific, evidenced, honestly scoped, and immediately actionable, exactly the qualities a good report needs throughout.

Tone and honesty

A professional report is calm, factual and precise, never alarmist and never falsely reassuring. It clearly separates what was directly confirmed from what is a reasonable but unconfirmed hypothesis (recall chapter 3's distinction), and it explicitly states the limits of the test, since no test, however thorough, can ever claim to have found "all" vulnerabilities. This honesty protects the client from a false sense of total security, and protects the tester's own professional credibility.

Your fil rouge: writing the Lighthouse Labs report

Using everything collected throughout Project Lighthouse (your journal entries, your priority list, your exploitation and post-exploitation notes), write a complete, short report following the six-section structure above. Keep the executive summary to a few sentences, include at least two findings written in the "strong version" style shown above (reusing your actual fictional lab findings from earlier chapters), and include an honest methodology section describing what was and was not tested. Save it as 06-report/lighthouse-report.md. This is the single most important deliverable of this entire course.

Your turn: rewrite a weak finding

Rewrite the following weak finding using the strong-version template from this lesson: "Found an old version of something running on a server. Could be bad. Suggest updating it."

See a solution

A possible strong rewrite: "Title: Outdated service version identified on [specific host from scope]. Severity: Medium (a plausible candidate weakness was identified based on version information, but could not be definitively confirmed as exploitable within the agreed test window; see methodology section). Description: service fingerprinting (see Appendix A) indicated a version of [service] that falls within a range potentially affected by publicly documented weaknesses; this could not be independently confirmed through direct testing due to time constraints. Evidence: banner and scan output showing the observed version. Impact: if confirmed, this could allow an attacker with network access to [the general category of impact associated with that kind of weakness, for example a service disruption or unauthorised access], though this was not verified directly. Recommendation: update the service to a current supported version, and schedule a follow-up test to confirm whether the underlying weakness is actually present and exploitable in this specific environment. References: the relevant CVE record and vendor advisory." Notice how this version is honest about what was and was not actually confirmed, rather than overstating certainty.

Writing the report is only half the job; the next lesson covers how to present it and communicate with the client afterwards.