Pentest report writing — deep

Pentest report writing — deep

TL;DR: A pentest report is the deliverable the client actually pays for; everything else is plumbing. This note is the deep practitioner companion to report-writing-for-pentesters and report-writing-step-by-step — covering structure, per-finding templates, audience-specific tone, screenshot discipline, severity rationale, multi-engagement tracking, and the recurring mistakes that get reports sent back for rework.

Why it matters

A great test with a bad report is indistinguishable from a bad test. Clients read the executive summary, skim the findings table, and then forward the document to remediation teams who will read individual findings out of context months later. The report has to survive that journey: it has to be legible to a CFO, technically precise enough for an engineer to fix the bug from the description, and self-contained enough that an auditor in twelve months can verify what was tested.

If you are building toward oscp-roadmap, osep-roadmap, or oswe-roadmap certifications, the exam report is graded with the same rigor — see oscp-exam-methodology. Bug bounty hunters submit a different shape of document but face the same problems around impact and reproducibility; see h1-disclosed-report-reading-method and demonstrating-impact.

Report structure

The canonical structure most consultancies converge on, in order:

Cover page and document control

Client name, engagement name, report version, date, classification (e.g. CONFIDENTIAL), and a document control table tracking revisions, authors, and reviewers. Sounds bureaucratic; legal teams will reject reports without it.

Executive summary

One to two pages, written for a non-technical executive. Answer four questions:

  1. What did you test and during what window?
  2. What is the overall risk posture in plain English?
  3. What are the top three to five themes (not findings — themes)?
  4. What is the single most important action the client should take this quarter?

Avoid CVE numbers, CVSS vectors, payloads, or tool names here. If a board director cannot read this section aloud in a meeting, rewrite it.

Scope and rules of engagement

Exact IP ranges, domains, applications, user roles, source IPs used, test windows, out-of-scope assets, and any agreed exclusions (e.g. denial-of-service, social engineering of named staff). This section protects both parties when something breaks or when a finding is contested later. Cross-reference program-scope-reading for how scope ambiguity bites you.

Methodology

Describe the approach at a level that maps to a recognised framework (PTES, OWASP WSTG, MITRE ATT&CK, NIST SP 800-115) without copy-pasting the framework. State what classes of testing you performed (unauthenticated network, authenticated web with each role, segmentation check, etc.) and any tooling baseline. Link to your internal testing-methodology-checklists mentally — the report version is the abridged form.

Risk summary and findings table

A single table with finding ID, title, severity, CVSS base score, affected asset/component, and status (open/remediated/risk-accepted). This is the page people screenshot into tickets. Sort by severity descending, then by asset.

Detailed findings

The bulk of the report. One finding per page or per section, using a consistent template (next section).

Strategic recommendations

Cross-cutting recommendations that no single finding captures: “patch cadence for internet-facing assets is 90+ days, target 14”, “no MFA enforcement on VPN”, “no SOC visibility into M365 audit logs — see siem-detection-use-case-catalog”. This is where the consultant earns their fee beyond bug-hunting.

Appendices

Tool versions, full port-scan output, hash lists, screenshots of evidence too large for the body, a glossary, and a retest log if applicable.

Per-finding template

Every finding uses the same fields, in the same order, every time. Consistency lets readers skim:

Title

A factual phrase, not a marketing line. Good: Unauthenticated SQL injection in /api/v1/search. Bad: Critical database compromise risk. Include the location.

Severity and CVSS

Provide both a qualitative rating (Critical / High / Medium / Low / Informational) and the CVSS v3.1 or v4.0 vector string and base score. The vector matters more than the number — a reviewer should be able to audit your reasoning from AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Note environmental adjustments separately; do not silently re-score.

Description

Two to four paragraphs. What the vulnerability is in general (one paragraph), then how it manifests in this specific application (the rest). Avoid generic OWASP boilerplate.

Impact

The business consequence. Not “an attacker could read the database” — that is the technical effect. Impact is “an attacker can enumerate every customer’s PII and payment metadata, triggering breach notification under GDPR (see gdpr-incident-implications) and PCI DSS 4 reporting obligations (see pci-dss-4-implementation).” See demonstrating-impact for the discipline of escalating from “I got a shell” to “this is what it means for the business”.

Steps to reproduce / evidence

Numbered steps, exact requests/responses, command lines, and screenshots. A junior engineer on the client side must be able to reproduce the issue from this section alone. Redact session tokens, customer data, and credentials — but preserve enough that the reproduction is unambiguous.

Remediation

Specific, not generic. “Use parameterised queries” is generic. “In SearchController.java line 142, replace the string concatenation with a PreparedStatement and bind searchTerm as a parameter; the existing input validation does not cover Unicode normalisation bypass” is specific. Where multiple remediation paths exist (quick fix vs. architectural fix), list both with trade-offs.

References

CWE ID, CVE if applicable, vendor advisory links, OWASP cheat sheet, internal ticket ID once one exists. Two to five links, all https.

Affected assets

List every host, URL, or component the finding applies to. If you found it on one endpoint but the pattern exists across twenty, say so explicitly — and either test the others or call out the assumption.

Tone: executive vs technical

The executive summary, strategic recommendations, and impact paragraphs are for non-technical readers. Rules:

  • No acronyms without expansion on first use.
  • No tool names (Burp, nmap, mimikatz) — describe what you did, not what you used.
  • Active voice, present tense, short sentences.
  • Quantify when possible: “12 of 47 internet-facing hosts” beats “many hosts”.
  • No hedging weasel words (“could potentially possibly”). Either the issue is exploitable or it is not.

The findings detail, evidence, and remediation sections are for engineers. Rules:

  • Be precise: file names, line numbers, parameter names, header values.
  • Show the exact request and response. Do not paraphrase HTTP.
  • Use code blocks for anything copy-pasteable.
  • Do not explain what HTTP is. Respect the reader.

The same vulnerability described twice — once for the CFO and once for the senior engineer — is not redundancy, it is the job.

Screenshot discipline

Screenshots are evidence, not decoration. Standards that hold up under audit:

  • Capture the full browser window or terminal, including the URL bar, timestamp, and any session indicator.
  • Red boxes/arrows for the specific element being demonstrated; nothing else annotated.
  • Crop to remove unrelated tabs, bookmarks, personal email previews, internal Slack notifications.
  • Redact customer PII with solid black rectangles, not blur — blur is reversible.
  • Number screenshots and reference them inline: (see Figure 4.2).
  • Prefer text/HTTP transcripts over screenshots for requests; screenshots for UI state and visual confirmations only.
  • Never include a screenshot of your own desktop wallpaper, browser bookmarks, or note-taking app. This happens more often than anyone admits.

Severity rationale: CVSS vs business impact

CVSS gives you a defensible baseline but lies about business impact. A 9.8 Critical unauthenticated RCE on an isolated developer sandbox with no data is operationally lower-risk than a 6.5 Medium IDOR exposing every customer’s invoice. Report both:

  • CVSS base as the universal yardstick — never skip it; auditors expect it.
  • Adjusted severity with explicit reasoning when business context overrides the CVSS rating.

Document the reasoning: “CVSS base 7.5; adjusted to Critical due to direct exposure of regulated cardholder data and absence of compensating controls (no WAF, no SIEM alerting — see siem-detection-use-case-catalog).” When you raise or lower severity, name the factor and the evidence. Never silently downgrade because “the client will push back”.

For chained findings, score the chain at the highest realistic outcome, not the sum. A reflected XSS plus a CSRF token leak plus a privilege escalation is one Critical chained finding with three component findings cross-referenced, not three Mediums.

Tracking findings across engagements

Most clients are recurring. The report from year two must reconcile against year one. Maintain:

  • A persistent finding ID scheme scoped to the client, not the engagement (ACME-2024-007 not Pentest-Q3-Finding-7).
  • A status field in the executive summary table: New, Recurring, Previously remediated — regression, Risk accepted.
  • A diff section comparing this report to the last: what was closed, what regressed, what is new. Clients love this. Their auditors love it more.
  • A retest appendix noting which previously reported items were re-verified and the method.

Recurring findings across multiple engagements are a strategic finding in themselves: “patch hygiene has not improved year over year” belongs in strategic recommendations.

Workflow to study

  1. Pick a public sample report (NCC Group, Trail of Bits, Cure53, NetSPI, Doyensec all publish them) and reverse-engineer its structure.
  2. Take one of your own htb-machine-walkthrough-methodology or vulnhub-walkthrough-pattern notes and rewrite it as a single finding using the template above. You will discover gaps in your evidence collection.
  3. Write the executive summary first, before the findings detail. It forces you to identify themes early. Most consultants do this last and the seams show.
  4. Have someone non-technical read the executive summary aloud. If they stumble, rewrite.
  5. Have an engineer who was not on the engagement try to reproduce one finding from the report alone. If they cannot, the steps are insufficient.
  6. Run a spell/grammar pass and a links-and-references pass as separate reviews. They catch different errors.
  7. Maintain a personal report style guide — your own conventions for terminology, severity thresholds, and phrasing. Reuse it.

Common report-writing mistakes

  • Burying the impact. The impact paragraph reads like a technical description. Rewrite for the business reader.
  • Inconsistent severity across findings. Two similar SQLi findings rated differently with no rationale. Use a rubric.
  • Generic remediation. “Apply secure coding practices” is not remediation. Be specific or admit you do not know.
  • Missing affected-asset lists. A finding without an explicit asset list invites scope arguments at retest.
  • Screenshot leaks. Burp Suite license email visible in the screenshot. Slack notification for #client-acme-private visible in the taskbar. Career-limiting.
  • CVSS hand-waving. Severity Critical with no vector string. Reviewers cannot audit your reasoning.
  • Tool-output dumps. Pasting nmap or nuclei output as a finding without interpretation. Tools find candidates; you confirm and contextualise.
  • Inconsistent voice. Half the report in past tense, half in present; some findings in passive, some active. Pick one and enforce.
  • No retest plan. Every finding should state what evidence will demonstrate remediation. Saves arguments later.
  • Over-promising scope coverage. Reporting “the application is secure” when you tested two of seven user roles. State exactly what you covered and what you did not.
  • Forgetting the appendix. Auditors and SOC engineers live in the appendix. A thin appendix signals a thin test.
  • Confusing the report with disclosure. Internal consulting reports are not responsible-disclosure-across-jurisdictions advisories — different audience, different rules. Do not paste advisory boilerplate into a private engagement.

Defensive baseline for the consultant

  • Template-driven Markdown or DOCX with a linter (vale, markdownlint) and a CVSS vector validator in CI.
  • Evidence captured live into a structured note system (Obsidian, Logseq, CherryTree), not screenshot folders.
  • Reports peer-reviewed by another consultant before client delivery — no exceptions, even for trivial retests.
  • Versioned reports in a private git repo per client, never email-only.
  • Reports sent over encrypted channels (PGP, client portal, SecureDrop), never plain attachments. See disclosure-and-comms.
  • A personal post-engagement retro: what did the client push back on, and how do I prevent that in the next report?

References

  • PTES Technical Guidelines — https://web.archive.org/web/2024/http://www.pentest-standard.org/index.php/PTES_Technical_Guidelines
  • NIST SP 800-115, Technical Guide to Information Security Testing — https://csrc.nist.gov/publications/detail/sp/800-115/final
  • FIRST CVSS v3.1 specification — https://www.first.org/cvss/v3.1/specification-document
  • FIRST CVSS v4.0 specification — https://www.first.org/cvss/v4.0/specification-document
  • OWASP Web Security Testing Guide — https://owasp.org/www-project-web-security-testing-guide/
  • NCC Group public technical reports — https://www.nccgroup.com/us/research-blog/public-report-archive/