The pentest report

Authorization first: a report is a record, not just a deliverable

Everything in this unit assumes the work was authorized — a signed scope, rules of engagement, and a defined window, the way the PTES pre-engagement phase requires before a single packet is sent. The report is where that authorization becomes a permanent record. A good report restates the scope and the dates at the top precisely because, months later, it is the document that proves you tested only what you were permitted to, when you were permitted to. A finding without the scope context around it is an accusation; a finding inside a clearly-bounded engagement is evidence. So the report is not only a list of bugs — it is the artifact that ties every observation back to the authorization that made it legal, and that framing is what lets a defender trust and act on it rather than treat it as a threat.

Two readers, one document

A penetration test report has two primary audiences who never read the same page, and the central skill is serving both in one document without diluting either.

The executive — a VP, a CISO, a customer’s board — reads to make a decision: is our risk acceptable, do we need to spend, are we exposed before a launch or an audit. They have minutes, not hours, and they do not read HTTP requests. What they need is on the first page: an honest overall risk posture, a count of findings by severity, the two or three issues that actually matter to the business, and a clear “here is what could happen and here is roughly what it costs to fix.” Bury that under technical detail and the decision-maker never reaches it.

The engineer — the backend dev, the SRE, the security champion — reads to act: which handler, what exact change, how do I verify it’s fixed. They will read the deep technical section, and for them brevity is the enemy; they need the full reproduction, the precise request, the root-cause remediation, and the evidence. What’s noise to the executive is the entire value of the report to them.

The architecture that serves both is layered, not split: one document, ordered from least technical to most. The executive summary sits up front and is self-contained — readable on its own with zero security background. Behind it, a findings table acts as the bridge both audiences share. Behind that, the detailed findings carry everything an engineer needs. Nobody is forced to read the layer that isn’t theirs, and the same artifact answers both questions.

What goes in each layer

The executive summary is the highest-leverage page in the report and the one juniors write worst. It is prose, not a table, and it answers four questions in business terms: what did we test and when (the scope and dates, one line), what is the overall risk posture (a defensible sentence, e.g. “the application is well-built but one configuration issue exposes cloud credentials”), what are the few things that actually matter (name the two or three findings whose impact a non-technical reader will feel — “an attacker could read every customer’s billing data”), and what’s the shape of the work (rough effort, are these quick fixes or architectural). No request bodies, no CVSS vectors, no jargon — if a smart non-engineer can’t act on it, it has failed.

The findings table is the bridge. One row per finding, sorted by severity, with just enough to triage: title, severity, affected component, and a one-line impact. The executive scans it to sanity-check the summary; the engineer scans it to build a work queue and clicks into the rows that are theirs. The detailed findings behind it carry the full anatomy you learned to write — reproduction with expected-vs-actual, concrete impact, justified severity, root-cause remediation — one self-contained section per finding. And the appendices hold what neither audience needs inline but both occasionally need: raw request/response evidence, the methodology and tools used (so the test is repeatable and the coverage is auditable), and the exact scope and authorization.

Communicating risk without crying wolf

The executive summary lives or dies on calibration. Two failure modes mirror each other. Over-stating — painting a competent application as a five-alarm fire to look thorough — gets the report distrusted and the relationship burned; the next report’s real critical gets discounted because last time everything was a crisis. Under-stating — softening the one genuinely serious finding so the readout feels comfortable — is worse, because it lets the business unknowingly ship the risk that ends it. The senior move is an honest posture sentence that separates the signal from the noise: “the application is generally well-built; the eight low and informational findings are routine hardening, but one configuration issue lets an attacker read cloud credentials and should be fixed before launch.” That sentence lets a non-technical reader allocate attention correctly — which is the entire job of the summary.

Risk has to be expressed in consequence, not mechanism. An executive does not act on “SSRF to the metadata endpoint”; they act on “an attacker could obtain the keys to our cloud account and access all customer data.” Translate every headline finding from what it is into what it lets someone do to the business — and put a number on likelihood and effort where you honestly can, because “high impact, low effort to fix” is a sentence a VP can fund in the meeting they’re reading it in.

How a defender reads the report

A defender — the team that owns the system — reads the report differently from both the exec and the implementing engineer, and understanding their lens makes you write a better one. They read it as a prioritized remediation roadmap and a coverage map. They take the severity-sorted table and turn it into a backlog ordered by risk-reduced-per-effort, not raw rank: the cheap high-impact fixes first, the architectural ones scheduled. They read the methodology appendix to learn what was not tested, because the gaps in your coverage are their next blind spots — an untested admin panel is a risk they now know to model. They mine the patterns: three separate IDOR findings aren’t three bugs, they’re one missing authorization pattern, and the defender’s durable fix is a shared access-control layer, not three one-off patches. And they feed the findings back into their own threat model, so the same class doesn’t recur. The report you write for the attacker’s-eye view becomes the defender’s prioritization input — which is exactly why structure, calibrated severity, and an auditable methodology aren’t formatting niceties; they’re what makes the document usable on the other side.