The report is the engagement — not the testing. What gets fixed is determined by what gets written.
Clients pay testers to change what gets fixed — the report is the artefact that produces the change.
| Purpose | Audience |
|---|---|
| Operational input | Engineering teams doing the fixing |
| Decision input | Management allocating resources, accepting residual risk |
| Evidence of work | Client showing they commissioned and received a test |
| Compliance artefact | Auditors and regulators |
| Legal / contractual artefact | What was done, found, and recommended |
| Historical record | Future retests, next year's engagement, incident review |
A well-structured report routes different content to different sections — serving all audiences simultaneously.
Read by everyone, including readers who will read nothing else. Typically 1–2 pages. Strict.
The executive summary often determines whether action follows. Treat it as the most important writing of the engagement.
Key findings overview: a bridge before detailed findings — typically a table of title, severity, one-line summary, affected asset. Lets a technical reader skim the landscape first.
For chained findings — tells the end-to-end story:
Each step references a finding ID. ATT&CK tags enable direct blue-team coverage analysis. Many engagements live or die in the perceived quality of this section.
Consolidated, prioritized view:
A table or matrix is typically most usable. Each entry references underlying finding(s).
/checkout endpoint", not "the application"Common gaps: pre-state not stated, implicit configuration, timing dependence, required tools not listed.
Inconsistent severity — Criticals that don't justify the rating, Lows that should be Highs — erodes trust with every reader.
Findings from the report become entries in the client's tracker: status (open / in-progress / fixed / accepted), owner, due date, remediation evidence. A well-formed finding transfers cleanly into a ticket. Some engagements deliver findings directly into the tracker; the report is then a summary over those tickets.
Document generators (Word, LaTeX, Markdown-to-PDF); engagement platforms (Plextrac, Faraday, AttackForge, Dradis, Serpico). Tooling decisions are organizational — the principles apply regardless.
A delta document over the original:
A finding's title is "XSS". What is wrong with this, and what makes a good title? Propose two improvements.
Bad: names only the technique. The client cannot assess priority from the title alone. Better (1): "Reflected XSS in product-search parameter" — adds location. Better (2): "Reflected XSS enables session hijacking" — adds impact. Best: "Reflected XSS in product-search parameter enables session hijacking of authenticated users" — combines location and impact; the client can decide priority without opening the body.
Next: Topic 23 — Bad vs. good reporting. What separates a report that produces change from one that doesn't.