The Executive Summary
One page, no payloads, no CVE numbers. Written for the person who signs the check and will never read past it.
What you will learn
- -Write an executive summary in business language a non-technical leader can act on
- -Lead with the worst true finding and the overall security posture
- -Translate a technical finding into consequence-focused prose without jargon
The CISO reads one page of your report. Maybe the board reads one paragraph of that page. They will never open the finding with the UNION in it, and they should not have to. The executive summary is the whole report for the people who decide whether it gets funded, and if it fails them, the technical work behind it never turns into a fix.
That page has a different job from everything else in the report. The findings section persuades an engineer to change code. The summary persuades a leader to spend money and attention. Different reader, different language, and the mistake almost everyone makes is writing the summary in the same voice as the findings.
Strip every piece of jargon
No CVE numbers. No payloads. No "UNION-based in the search ." A business reader does not know what that is and will not learn it in the ten minutes they have. Say what it means to the organization instead.
$Technical: 'Unauthenticated SQLi in /search enables UNION extraction of the users table' -> Executive: 'An attacker on the internet, with no login, could download every customer record including passwords'Lead with the worst true thing
Put the single most serious real in the first two sentences. Leaders read top down and stop early, so burying the crown-jewels finding under a paragraph of and methodology means they may never reach it. Open with the punch, then give the shape of everything else.
A good summary has a predictable arc. What you did, in one sentence. What you found, as a count and a plain-language headline. The top risks, named by business consequence. The overall posture, your honest one-line verdict on how they are doing. And what to prioritize, so they leave the page knowing the next move.
Notice there is not a single technical term in that paragraph, and yet a reader knows exactly how worried to be and what to do first.
Tell the attack story, not the finding list
The findings section is a list. The summary is a narrative. If an attacker could chain three medium findings into a full compromise, the summary is where you say so, because that chained path is the real risk and no individual finding shows it. "Individually these are moderate, but together they form a path from an anonymous visitor to full administrative " is the kind of sentence that gets a room to act, and it lives only in the summary.
Keep the summary honest in both directions. State plainly what you were scoped to test and what you were not, so a leader does not read "we assessed the portal" as "everything we own is safe." Do not overstate the posture to flatter the , and do not inflate it to alarm them into more work. This page drives budget and board-level decisions, so an exaggeration here does more damage than anywhere else in the document. Report the real posture of the systems you were authorized to test, and name the limits of that scope.
A finding reads: 'Stored XSS in the ticket comment field executes JavaScript in an administrator's session, enabling session-cookie theft and full admin takeover.' Rewrite it as one sentence for the executive summary, with no jargon.
Drop the terms (, , session ) and keep the consequence: an attacker takes over an admin account, and does it through something as ordinary as filing a support ticket. That gives a leader the who, the how-easy, and the loss without a single technical word.