A pentest delivers two artefacts: a technical report and an executive summary. Engineers read the technical report; executives read the summary. What gets remediated depends almost entirely on whether the summary does its job — because the budget, the prioritization, and the “stop shipping features until this is fixed” decision live with people who will not open the 60-page appendix.
Key takeaway
The executive summary is not a translation of the technical report. It is a different document, with a different purpose, written for a different reader. Most pentest reports fail here and the remediation stalls as a result.
What a weak executive summary looks like
The pattern is familiar. The summary lists finding counts by severity — four critical, eleven high, nineteen medium, twenty-two low. It includes a CVSS distribution chart. It has a methodology paragraph. It concludes with the sentence: “the tested environment has significant vulnerabilities that should be remediated in accordance with organizational priorities.”
A non-technical board member reads this and learns three things: there are some red numbers, a chart was provided, and nothing specific must happen by any particular date. The document drives no decisions because it asks for none.
What a board-usable summary contains
Five things, in this order:
1. The business-language statement of what the attacker could do
Not “SSRF in image-fetch endpoint leading to IMDS credential exposure.” Instead: “within four hours of starting, the tester was able to read every customer’s billing records without authentication.”
The second sentence moves budget. The first sentence does not, because the reader cannot evaluate whether it is important.
2. The single most damaging chain
A mature pentest finds dozens of issues. The executive summary names one: the worst chain the tester executed, described as a narrative, ending in a stated business impact. “The tester combined [finding A] and [finding B] to achieve [outcome]. Either finding alone would not have been exploitable. The combination is what produced the impact.”
This is the only part of the report that most executives will truly read. Getting it right is most of the value of the engagement.
3. A small set of numbered recommendations, tied to business outcomes
Not “implement compensating controls for finding CVE-xxxx-yyyy.” Instead:
Recommendation 1. Restrict outbound egress from the application VPC to a curated allow-list of destinations. Expected outcome: the chain that led to customer-data exposure becomes non-exploitable regardless of application-level bugs. Estimated effort: 2 engineering weeks.
Three or four of these, each naming the outcome and the cost, gives a non-technical reader everything they need to fund and schedule the work.
4. What changed since last year
If this is the second engagement, the summary must call out what was fixed since last year — and what was flagged last year and remains exploitable. The second category is where accountability lives, and executives will ask about it regardless of whether the report surfaces it. Better to surface it.
5. A retest commitment and a date
“Findings will be retested within 30 days of remediation; an updated report will be issued with status changes reflected.” Without this line, the report is a snapshot with no path to closure. With it, there is a deadline and an artefact that makes remediation a measured deliverable.
Common miss
Retests are often treated as a separate engagement and priced accordingly. For reports you actually want acted on, retest should be included in the original scope. It is the mechanism that turns findings into fixes.
What to ask of your pentest vendor
Before the engagement begins:
- Can you share a sample executive summary from a previous engagement? The technical report is usually a commodity; the summary is not.
- Is retest included in the base price?
- Will the summary include a named chain-of-exploitation scenario with business impact, or only a severity distribution?
- Will you present the findings live to a mixed technical/executive audience? The live readout is where most of the remediation decisions actually get made.
If the vendor cannot answer these concretely, the engagement will produce a PDF that gets forwarded three times and actioned zero.
What to do with the report you already have
If you are reading an old report that did not meet this bar:
- Pull out the single highest-impact finding. Rewrite its summary in business language. Share that with the leadership that commissioned the report.
- For every finding marked “accept risk,” write down the business decision and who owns it. A finding with no owner is a finding that will resurface on the next report.
- Schedule the retest, even if the contract doesn’t include one. Pay for it out-of-band if necessary. The retest is what closes the loop.
A pentest report that does not drive action is a cost, not a control. The difference is almost entirely in how the summary is written.