⬡ BREACHOPERATORS
Home/ Research/ Reporting for Operators
Research & Tradecraft /// Documentation

Reporting for Operators: Precision, Clarity, Impact Finding anatomy // information architecture // narrative arc // risk communication

How to write penetration testing reports that are technically dense, narratively compelling, and operationally actionable — a practitioner's guide to communication that respects both the craft and the audience, because a finding that never gets remediated isn't a finding, it's a paragraph nobody acted on.

Documentation Report Writing Risk Communication Stakeholder Comms Operator Craft
04 Documentation Series Read time: ~18 min Level: All Levels / Operator Status: Published
01

Reporting Is Part of the Craft

An engagement's technical work ends when the last shell closes. Its actual impact is decided entirely by what happens after — whether the report gets read, understood, and acted on by people who weren't in the room for any of it. Treating reporting as overhead tacked onto "the real work" produces exactly the kind of report that gets skimmed once and filed. Treating it as a continuation of the same craft — precision in a different medium — produces a report that changes what the client's environment looks like six months later.

Three qualities separate a report that gets acted on from one that doesn't: technical density that respects a skilled reader's time and doesn't dumb down the mechanism, narrative clarity that lets a non-technical stakeholder follow the stakes without needing the mechanism explained, and operational actionability — a reader always knows exactly what to do next, for whom, and in what order.

Operating principle A finding nobody understood well enough to fix is functionally the same as a finding nobody found. The report is the deliverable that actually determines whether the engagement mattered.
/// the report is the deliverable, not the appendix to it /// density for the technical reader, clarity for everyone else /// unread findings and unfound findings are the same outcome ///
02

Anatomy of a Finding

Every finding, regardless of severity, should answer the same five questions in the same order — consistency here is what lets a reader build a mental model once and reuse it across forty findings instead of re-orienting on every page.

Diagram 01 — Finding Anatomy
01 What the vulnerability or misconfig, stated plainly in one line 02 Where exact asset, endpoint, or object — precise enough to locate fast 03 How reproduction steps, evidence, exact request/response 04 So What business impact — what an attacker actually gains from it 05 Now What specific remediation, owner, priority — not "patch system" Every finding — Critical or Informational — walks this same five-step order. Consistency is what lets a reader build one mental model and reuse it across the whole report.
Read: "What" and "Where" orient the reader fast, "How" carries the technical proof a skilled reviewer needs to trust the finding, and "So What" / "Now What" are what actually get a ticket created — they're the two most frequently rushed or omitted sections, and the two that determine whether anything happens next.

"So What" Is the Section Most Reports Get Wrong

A finding that stops at the technical mechanism leaves the business-impact translation as homework for the reader — and most readers with remediation authority don't have the context to do that translation themselves. Spelling out the concrete consequence ("this credential, combined with the trust misconfiguration in Finding 07, yields domain-wide access") does the reader's risk assessment for them instead of assuming they'll connect the dots across a forty-page document.

Weak

"The application is vulnerable to SQL injection in the login parameter."

Strong

"An unauthenticated attacker can extract the full customer credentials table via SQL injection in the login form, enabling account takeover across all ~40,000 registered users."

/// what/where/how/so-what/now-what, every time /// so-what is the reader's risk assessment done for them /// consistency is what makes forty findings readable, not thirty-nine ///
03

Report Information Architecture

Different readers of the same report need fundamentally different things from it, and a report that forces every reader through the same linear path fails most of them. An executive sponsor needs three minutes and a risk picture. A remediation engineer needs exact reproduction steps. Structuring the document in layers — each one self-contained enough to be read alone — serves both without duplicating effort or bloating length.

Diagram 02 — Layered Report Architecture
Executive Summary risk posture, business language, no jargon — readable in 3 minutes Audience: Sponsors / Execs Findings Overview severity-ranked table, one line per finding, cross-references between chained findings Audience: Security Leads Detailed Findings full five-part anatomy per finding — evidence, reproduction, remediation, owner Audience: Engineers Appendix — raw scan output, methodology notes, scope, tooling versions ( Audience: Auditors / Future re-testers )
Read: each layer is self-contained — an executive reading only the summary and a security lead reading only the findings overview both walk away with what they need, without either being forced through the other's layer.

Cross-Referencing Chained Findings

Real compromises are rarely a single finding — they're a chain (see our AD Tradecraft writeup for exactly this kind of chain). The findings overview layer should make chains visible at a glance, not bury the connection in prose three pages into each individual finding. A reader skimming the overview table should be able to see that Finding 03 plus Finding 07 equals domain compromise without reading either in full.

/// different readers need different layers, not the same document twice /// each layer should stand alone /// make finding chains visible at a glance, not buried in prose ///
04

The Narrative Arc

Findings presented as an alphabetized or purely severity-sorted list lose the thing that makes an engagement's impact land: the story of how a real attacker would actually walk from initial foothold to objective. A narrative section — distinct from the findings list, positioned right after the executive summary — reconstructs that path in plain sequence.

Diagram 03 — Attack Narrative Arc
Foothold phishing / exposed svc Local Access shell / credential cache Priv Escalation ADCS / ACL abuse Lateral Movement trust abuse / DCSync Objective data / domain control Each node = one paragraph, plain language, cross-referenced to the finding number that proves it — not the finding's technical detail restated. This section is prose, not a table. Its job is to make the cumulative risk visceral before the reader hits the itemized findings list — severity sorting alone can't do that.
Read: the narrative arc walks the same path the operator actually took, in plain language, with each stage pointing back to the finding number that substantiates it — separate from, and read before, the itemized findings list.
Operator note Write the narrative section in past tense, active voice, first person plural where appropriate ("we obtained," "this allowed us to") — it should read like an account of what happened, not a hypothetical. That's what makes cumulative risk land emotionally as well as technically, without exaggerating anything that didn't actually occur.
/// severity sorting alone can't make risk feel real /// narrative is prose, findings list is reference /// write what happened, not what could theoretically happen ///
05

Communicating Risk Clearly

A CVSS score alone tells a business stakeholder almost nothing about what they should actually do. Risk communication that lands combines a standardized technical score with explicit business context — and states the combination transparently, so the reader can see how the final rating was derived rather than trusting a black box.

InputWhat It CapturesWhat It Misses Alone
CVSS Base ScoreTechnical exploitability and impact in a vacuumWhether the asset actually matters to this business
Exploitability in contextWhether this specific environment's controls change real-world likelihoodLong-term business consequence of exploitation
Business criticality of assetWhat the asset is worth to this specific organizationTechnical severity of the flaw itself
Combined ratingA defensible, reproducible final priorityNuance — always pair with a one-line rationale, not just a number

Whatever scoring model gets used, state the inputs that produced each rating explicitly next to the finding — "Critical: CVSS 9.8, elevated from High due to direct path to the customer PII database" — so remediation prioritization conversations start from shared, visible reasoning instead of a disputed number.

/// a score without context is a number nobody can act on /// show your rating math, don't hide it behind the label /// context turns a CVSS score into a prioritization decision ///
06

Editing for Precision

The gap between a technically accurate finding and a well-written one is almost always an editing pass, not a drafting problem. Three cuts catch most of the density that dilutes a report's impact.

Cut Hedging

"It may be possible that an attacker could potentially..." — say what was actually demonstrated. Hedge only where genuine uncertainty exists, and say so plainly when it does.

Cut Passive Voice on Actions

"The credential was obtained" hides who did what. "We extracted the credential via X" keeps the reader oriented on cause and actor.

Cut Restated Mechanism

Don't re-explain the "How" inside the "So What." Trust the reader who just read the reproduction steps; move straight to consequence.

Cut Adjective Inflation

"Extremely critical," "highly severe" — the severity label already carries that weight. Let the evidence, not the adjectives, do the persuading.

Before

"It was found that the system may potentially be susceptible to a highly critical vulnerability that could allow an attacker to possibly gain unauthorized access under certain conditions."

After

"We gained unauthorized administrative access by exploiting an unpatched service on the exposed host at 10.20.3.14."

Operator note Read every finding's "So What" section out loud. If it doesn't sound like something a person would actually say to a colleague to explain why they should care, it needs another pass.
07

Closing Notes

The technical work of an engagement and the report describing it are not two separate skill sets competing for an operator's time — they're the same discipline of precision, applied to two different mediums. A report built on consistent finding anatomy, layered for its actual audiences, carried by a real narrative arc, and edited down to what actually happened is what turns an engagement's technical findings into an organization's remediated environment.

This writeup is part of the ongoing BreachOperators research archive. Future entries in this series will cover report templating systems for consistency across a growing team, and communicating remediation-verification results after a re-test.

⬡
BreachOperators Research
Offensive Security Research Collective — Documentation Series, Vol. 04
08

References & Further Reading

  • 01 FIRST.org — Common Vulnerability Scoring System (CVSS) v3.1 specification
  • 02 PTES — Penetration Testing Execution Standard, Reporting section
  • 03 NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment
  • 04 Google Developer Documentation Style Guide — precision and active-voice guidance, adapted for security writing
  • 05 SANS — Writing a Penetration Testing Report whitepaper