One engagement, two readers
A penetration-test report is an unusual document: two very different people open it looking for completely different things. The executive wants to know what the engagement means for the business — is the organization exposed, how badly, and what should be done about it — and they want that in the time it takes to drink a coffee. The engineer wants the opposite: the exact host, the exact version, the exact request, and the precise steps to remediate. Both are right to want what they want. The structure of the report exists to give each of them their part without making either wade through the other's.
The skill is not writing two reports. It is writing one report whose layers are pitched at different altitudes — and keeping those layers perfectly consistent with each other.
The executive summary
The executive summary is a high-level overview of the entire engagement, and it has a hard length budget: a page or two at most. A good test of one is whether it could be physically removed from the report and handed to a senior executive as a standalone brief — because that is exactly what often happens. Executives are not concerned with the mechanics of the engagement; they want the absolute highlights. Your ability to be succinct while still conveying the main points is the whole game.
However short it is, a complete executive summary covers four things at minimum:
| Element | The question it answers |
|---|---|
| Goals & Objectives | What was the purpose of the engagement? What were the testers trying to accomplish, and why? |
| Dates & Times | When did the engagement take place — when did testing begin, and when did it end? |
| Scope | Which systems or groups of systems were tested? Were any explicitly excluded or off-limits? |
| High-Level Results | What happened? Was the test successful or not, and how? What is the recommended course of action moving forward? |
Get those four right, in plain language, and a busy executive can read your summary and walk into a budget meeting able to speak to the engagement with confidence. That is the entire point of the section.
Writing for executives
Pitching to leadership is a writing discipline, not a dumbing-down. A few rules keep an executive summary on target:
- Speak business, not jargon. Leadership does not need a CVE number or a tool name; they need the consequence. "An attacker could access patient records from the internal network" lands; "CVE-2022-23808 affects the phpMyAdmin instance" does not.
- Always answer "so what?" Every sentence in the summary should connect to business impact — money, data, downtime, reputation, or compliance. If it does not, it belongs in the technical detail.
- Calibrate the tone. Neither fear-mongering nor false comfort. Overhype and you lose credibility; soft-pedal and you fail the client. State the risk plainly and proportionately.
- Quantify where you can. "Three of five tested systems allowed full administrative takeover" is far stronger than "several issues were found."
- Keep it skimmable. Short paragraphs, a clear verdict up top. Assume it will be read in two minutes, because it will be.
The technical detail
Beneath the summary sits the layer written for the people who will actually fix things. Here the values flip: precision over brevity, completeness over readability. The technical detail must be reproducible — an engineer who was not on the engagement should be able to follow a finding to its affected asset, see the evidence, and understand the remediation well enough to act. That means exact hostnames and IPs, exact software versions, the requests or commands used, and references the team can look up.
This is also where you speak the defender's language by mapping findings to MITRE ATT&CK technique IDs. Tagging a finding with T1110 (Brute Force) or T1078 (Valid Accounts) lets the client line your results up directly against their detection coverage — turning "we got in" into "here is the technique, and here is whether you would have seen it." The threat-actors lesson introduces ATT&CK in depth, and the live matrix lives at attack.mitre.org.
The attack narrative: the bridge
Between the two altitudes sits the section that both audiences actually enjoy reading: the attack narrative. It reads like a short story, told linearly, summarizing exactly what you did as an attacker — with specific details — from your first foothold to your final objective. Done well, it carries an executive through the arc of the engagement ("they started with nothing but an IP range and ended with control of the network") while giving an engineer the exact sequence of moves to trace.
The narrative is where the report proves it understands the engagement as a story and not just a list of disconnected issues. Whether you illustrate it with screenshots or keep it as clean text is personal preference; what matters is that it is honest, ordered, and concrete. A strong narrative is often what an executive remembers long after the severity table has faded.
Consistency without contradiction
Writing for two audiences introduces a specific danger: the layers can drift apart. The fastest way to destroy a report's credibility is for the executive summary to say one thing and the findings to say another — a summary that calls the engagement "largely successful from a defensive standpoint" sitting above three High-severity full-compromise findings is a report no one will trust.
Guard against it deliberately. The same facts and the same severities must hold across the whole document — one metric, applied identically everywhere (see 08.04). The high-level results in the summary must be a faithful compression of the detailed findings, never an exaggeration and never a softening. When you revise, read the summary and the findings side by side and ask one question: do these tell the same story?
Next: how to turn raw technical severity into prioritized business risk — and how to write remediation a client can actually execute.