Executive summaries

The executive summary is often the only part of the report management reads in full. It is written for CISOs, executives, and other non-technical decision-makers who need to judge overall risk, not individual vulnerability details.

It answers how bad it really is, what attackers can reach at a high level, and what to do next at an organizational or architectural level. Stay honest and factual. Prefer language already used in the per-finding summaries: they are less technical and closer to what leadership can act on. Jargon and detailed verification paths do not belong here unless absolutely necessary.

See also Report writing, Finding summaries, and Finding recommendations.

Goal

A good executive summary:

• Answers how bad it really is in plain terms, without inflating or softening what we proved.
• Explains what attackers can reach at a high level: data, accounts, systems, and operations.
• Highlights risk by combining findings into an attack path when that path is real and supported by the evidence.
• Stays concise and non-technical so management can read it once and understand the situation.
• Is mostly based on finding summaries, not on finding descriptions or raw technical notes.
• Highlights strengths we observed during testing when they matter (e.g. the SOC detected our attacks within minutes).
• Focuses on the main risks (typically Critical to High themes). Low and Informational findings can be left out or folded into a short continuous-hardening note.
• Ends with strategic recommendations: higher level than per-finding fixes, aimed at organizational or architectural issues.
• Includes operational judgment only when necessary, especially when issues create existential or very high threats.

Length is a soft target, but aim for half a page: long enough to paint a clear picture of the risk, short enough not to be bloated. Engagements with many findings often need a longer executive summary; engagements with a few clear themes can stay short.

Quick rules of thumb

• Lead with the headline. State the worst realistic outcome in the first paragraph.
• Build from finding summaries. Reuse their plain-language outcomes. Do not pull jargon, tool names, or step-by-step verification from descriptions unless the exec summary cannot make the point without it.
• Chain findings when the path is real. If finding A enables finding B, say so. Do not invent missing links or inflate the end state beyond what we demonstrated or can credibly support.
• Outcome over mechanism. State what an attacker could access, control, or disrupt. Do not walk through how we exploited each issue.
• Stay honest. Answer "how bad is it?" with verified facts and clear limits of testing. No hypothetical worst cases.
• Recommend strategically. Prefer organizational and architectural direction over per-endpoint configuration detail.
• Highlight strengths when noticed. If a control worked in practice (detection, segmentation, hardened admin access), say so with a concrete observation.
• Skip Low and Informational detail. Cover Critical to High themes. A line such as "Remaining lower findings belong in continuous hardening" is enough.
• Add operational judgment only when needed. Usually skip it when the posture is already solid and only a few Critical or High findings remain. Include it when issues can lead to existential or very high threats (e.g. domain takeover reaching OT, full internet-facing takeover).
• Write in past tense (see Report writing).

What leadership needs to decide

Question	What to cover
How bad is it?	Overall risk in plain terms.
What can attackers reach?	High-level outcomes we demonstrated or credibly chained: data, systems, accounts, operations.
What did we find?	Grouped Critical to High themes or a short attack-path narrative, not a flat list of every finding.
What is already good?	Strengths we noticed (e.g. fast SOC detection) and client initiatives already underway.
Do systems need special handling now?	Only when threats are existential or very high. Otherwise omit.
What should happen next?	Strategic, medium- to long-term priorities. Not every bullet from every finding.

Structure

A typical executive summary flows like this:

1. Headline and overall posture (1 short paragraph): worst credible outcome, plus strengths if we noticed them.
2. Combined impact (1 to 2 paragraphs): what an attacker could ultimately reach when weaknesses work together. Name the business consequence, not each technical step.
3. Operational judgment (optional): whether to keep systems running, add monitoring, segment networks, or restrict access while remediating. Include only when necessary.
4. Grouped themes and strategic recommendations (remainder): main Critical to High themes and medium- to long-term next steps. Lower findings can be one short continuous-hardening sentence.

Not every engagement needs all sections. The flow matters more than the headings. Prefer clarity over a fixed length: paint the risk picture fully, but do not pad. Many findings often mean a longer executive summary; few themes can stay short.

Start from finding summaries

Write the executive summary after the finding summaries exist, or at least draft from their wording. Summaries already strip most technical detail and state impact for a management audience.

Source	Use in the executive summary?
Finding summaries	Yes. Primary input for outcomes, who can exploit, and limits.
Finding titles	Yes, for grouping themes.
Finding descriptions	Rarely. Use only when a summary is missing a fact you must state at engagement level.
Finding recommendations	Indirectly. Lift themes (identity, segmentation, authorization), not per-control bullets.

If a sentence needs a protocol name, CVSS score, CWE ID, tool name, or reproduction step to make sense, it probably belongs in a finding description, not here.

Combine findings into attack paths

Executives do not benefit from a flat list of fifteen medium findings. When several findings form a useful attack path, highlight that path so the combined risk is visible. Separate issues often look moderate on their own; together they can show a clear route to a much worse outcome.

Stay factual:

• Chain findings when roles, access levels, or systems clearly link them (e.g. unauthenticated access leads to a standard user session, which leads to admin password reset).
• Do not invent links we did not prove, assume production abuse we did not test, or claim an end state beyond what the evidence supports.
• Do not inflate by chaining weakly related issues just to sound dramatic.

Separate listing (weak)	Chained outcome (strong)
"3x high: LDAP signing missing, SMB signing partial, LLMNR enabled"	"A standard employee account could be escalated to full control of Active Directory, including systems that rely on it for authentication."
"2x critical on portal, 1x high on API"	"An external attacker could access other customers' orders and administrative functions through the customer portal."
"Unauthenticated users can bypass authentication and log in as a standard user" and "A standard user can reset passwords of other users, including admins" listed as two unrelated highs	"Unauthenticated attackers could take over the website: they could bypass login to reach a standard account, then reset administrator passwords and gain full control."

Lead with what is at risk. Mention who can reach it when that changes the decision. Keep the path at business level: starting access, what that unlocked, and the end state. Leave technical details (e.g. protocols, commands, jargon, detailed enpoints, etc.) for descriptions.

Example (findings left separate)

We found that unauthenticated users can bypass authentication and log in as a standard user. Separately, a standard user can reset passwords of other users, including administrators.

Each sentence is true, but leadership may treat both as local flaws and miss that together they allow full site takeover from the internet.

Example (chained path)

Unauthenticated attackers could take over the website. We were able to bypass the login page and obtain a standard user session. With this session we were able to reset passwords of any user, including administrators. Combined, that path gives an external attacker administrative control of the application without a valid account.

Both steps were demonstrated. Connecting them makes the combined risk obvious without inventing anything.

Example (too technical)

Starting from a standard workstation, we chained missing LDAP signing with weak SMB protections and name-resolution abuse to obtain domain administrator access and reach the OT environment.

This reads like a finding description. Leadership needs the path in outcome terms, not the protocol-level chain.

Example (outcome-focused chain)

Weaknesses in workstation and domain authentication controls allowed any standard employee to gain administrative control of Active Directory and reach OT systems that share the same identity platform.

Same severity, but the reader sees the business consequence and the combined path without the relay mechanics.

Be honest about how bad it is

• State only what we verified or could credibly chain from verified steps.
• Say when time or scope limited testing: "We did not assess the mobile application" or "We could not test the production OT segment."
• Do not predict regulatory fines, reputational damage, or compliance outcomes.
• If compensating controls reduced risk during the test (SOC monitoring, network segmentation), say so, but do not imply they remove the need to fix root causes.
• If the client is already remediating (PAM, LDAP signing rollout), mention it without suggesting the problem is solved.
• Do not soft-pedal critical outcomes to sound polite, and do not overstate them to force urgency.

Highlight strengths when noticed

If we observed a control working during the test, say so. Concrete strengths help leadership judge residual risk and where investment already pays off.

Examples:

• "The SOC identified several of our attack attempts within minutes and opened incidents."
• "Administrative access to the customer portal was already limited to the internal network, which reduced the exposure of the session-management flaw."
• "Endpoint protection blocked multiple payload attempts on employee workstations."

Mention strengths that we actually saw. Do not invent a positive tone by listing generic best practices the client might have. Strengths do not cancel Critical findings; they put them in context.

Operational judgment (only when needed)

Include operational judgment only when it changes what leadership should do now. Typical cases:

Situation	Operational judgment?
Solid posture overall, only a few Critical or High findings, no existential exposure	Usually omit
Issues that can lead to existential or very high threats (e.g. domain compromise reaching OT, full internet-facing takeover)	Include
Leadership needs a clear go / restrict / isolate message while remediating	Include

When you include it, answer directly:

• "The customer portal can remain in production if administrative access is restricted to the internal network until the session management flaw is fixed."
• "OT systems should be treated as exposed to domain compromise until domain authentication hardening is enforced or OT networks are completely segmented from user workstations and domain controllers."
• "We did not identify issues that require an emergency shutdown, but two findings should be remediated within the next sprint before further external exposure."

Avoid vague lines like "risk should be addressed in a timely manner" without saying what that means for operations.

Strategic recommendations

Executive summary recommendations are higher level than individual finding recommendations. They tackle organizational or architectural issues and point direction over the medium to long term.

Level	Belongs in
"Complete the planned PAM rollout and restrict standing domain admin access."	Executive summary
"Segment OT from office networks before expanding partner VPN access."	Executive summary
"Prioritize fixing authorization flaws that allow customer or admin takeover on internet-facing apps."	Executive summary
Set a specific GPO, registry key, or cookie attribute	Finding recommendations

Order by business effect, not by CVSS score alone. You do not need to restate every finding recommendation. Cover the themes that change how the organization runs identity, network boundaries, privileged access, or application security programs.

Low and Informational findings usually do not need individual mention. A short closing line is enough, for example: "Remaining lower findings belong in continuous hardening."

Full example

Below is an example based on a typical internal / AD engagement.

We identified a solid security baseline at XYZ, but critical vulnerabilities could allow low-privileged attackers to compromise administrative accounts and OT infrastructure. Network access is well protected through centralized authentication, multiple endpoint security solutions, and continuous monitoring by a security operations center. During testing, the SOC identified several of our attack attempts within minutes. Further measures are currently being implemented, including Privileged Access Management (PAM), which will strengthen the overall security level once fully rolled out.

Despite this foundation, we identified several weaknesses that together allow a broader compromise of the environment. Authentication and network controls on employee workstations could be bypassed to gain administrative control of Active Directory, and OT-related systems that rely on the same identity platform. Separately, an internal web application exposed sensitive HR data to users who should not have access. In both cases, a normal employee account with standard remote access was enough. Physical access or insider knowledge was not required.

Because domain compromise could reach OT systems that share the same identity platform, OT should be treated as exposed until domain authentication hardening is enforced or OT networks are segmented from office networks and domain controllers.

Over the medium and long term, we recommend completing PAM deployment, reducing standing domain administrator accounts, hardening domain authentication controls on domain controllers, and segmenting OT from office networks. Application teams should address authorization flaws in the HR platform in parallel. Re-test after these controls are in place to confirm the authentication and application issues are closed. Remaining lower findings belong in continuous hardening.

This example leads with impact, highlights a concrete strength (SOC detection), chains related outcomes, adds operational judgment because OT exposure is a very high threat, and closes with strategic priorities plus a short note on lower findings.

Executive summary vs. finding summary

	Executive summary	Finding summary
Scope	Whole engagement	Single finding
Length	Soft target: clear picture, not bloated. Longer when many findings	A few sentences
Reader	CISO, executive leadership	Department lead, management
Detail	Critical to High themes, combined attack paths, judgment only if needed	One issue's impact and preconditions
Source	Mostly finding summaries, grouped and chained	Drawn from that finding's description
Recommendations	Strategic, organizational or architectural	Per-finding fixes

Common mistakes

• Burying the headline by opening with scope, methodology, or a findings count table.
• Writing from descriptions and dragging jargon, tools, or verification paths into the exec summary.
• Flat finding lists with no grouping or combined-outcome narrative.
• Missed attack chains where related findings (for example auth bypass plus privilege escalation) are left as separate issues instead of one path to a worse outcome.
• Hypothetical or inflated chains that invent steps, stretch weakly related issues, or claim an end state we did not support.
• Exploitation walkthroughs that describe how we abused each issue instead of what an attacker could ultimately reach.
• All negative with no mention of strengths we actually observed.
• All positive that understates critical issues leadership must act on.
• Listing every Low or Informational instead of focusing on main risks and a short continuous-hardening note.
• Operational judgment by default when the posture is already solid and no existential or very high threat exists.
• Technical jargon without a plain-language outcome.
• Scanner tone ("47 vulnerabilities identified") instead of business consequences.
• Finding-level recommendations restated as the whole next-step section, instead of organizational or architectural direction.
• False precision on compliance, fines, or reputation without evidence or client request.
• Bloated length. Paint a clear picture. Cut padding, not the headline. Longer text is fine when many findings need grouping.

Further reading

• OWASP Web Security Testing Guide — Reporting
• Google Tech Writing Course — Audience and scope