Finding summaries
The summary is the non-technical introduction to a finding. It is written for management, department leaders, and similar roles, sometimes including CISOs who need the business picture of a specific finding.
The description carries the full technical analysis. The summary answers why leadership should care.
See also Finding titles, Report writing, and Executive summaries.
Goal
A good summary:
- Leads with the biggest validated impact in the first sentence (e.g. platform takeover, account takeover).
- States what an attacker could achieve in the client's environment.
- Explains how we reached that outcome in plain language, in one to three sentences.
- Names requirements and limitations (who can exploit it, what we did not test).
- Is tailored to the client's systems, data, and roles.
- Is short, but should not miss critical information.
Quick rules of thumb
- Impact first. Open with what is at risk, not with the vulnerability category.
- Plain language. Avoid jargon (CVSS vectors, CWE IDs, protocol names) unless absolutely required.
- Verified outcomes only. Describe what we demonstrated, not theoretical worst cases we did not test.
- Name the client's context. Refer to the specific portal, customer database, VPN, or admin role, not "the application" or "the server" (except when only one application was assessed). Name the feature or page in plain language. Full URLs, API paths, and parameter names belong in the description unless a short name is needed for clarity.
- Keep it short. Two to four sentences for the whole summary is usually enough. The attack path (how we got there) should be one to three sentences on its own at maximum.
- Outcome over mechanism. Describe what we could do and what that unlocked, not how we did it technically. Tool names, file paths, API endpoints, command-line steps, and similar belong in the description.
- Write in past tense (see Report writing).
What every summary should answer
| Question | What to cover |
|---|---|
| What is the impact? | First sentence. What data, accounts, or operations are at risk? |
| What goal did we reach? | What we actually achieved during the test (e.g. administrator access, read customer records). |
| How did we get there? | One to three sentences in business terms. State what each step unlocked, not how we performed it technically. No payloads, commands, or step-by-step reproduction. |
| What are the requirements and limitations? | Who can exploit it (any internet user, logged-in customer, internal employee). What we did not verify. |
Not every summary needs four separate sentences. Often one paragraph covers all four. A busy reader should be able to skim it and understand the risk.
Structure
A typical summary flows like this:
- Impact: what matters to the business.
- Goal reached: what we proved during the engagement.
- Path: how we got from entry point to that goal, in one to three plain-language sentences.
- Requirements and limitations: preconditions and any gaps in our testing.
Example (good summary)
Logged-in users could fully take over the online shop, by changing other user's passwords, including the administrator's. During the test, we logged in as a regular shop customer and changed the administrator's password via the password change function. With the newly set password, we gained access to the administrator account and had full access to all customer orders, user accounts, and configuration settings. Any user with a valid login could exploit this flaw to compromise the system and access sensitive customer data.
This summary names the client's portal, the data involved, who can exploit it, and what we demonstrated, without HTTP details or cookie field names.
Example (too technical)
The application stores the
userIdin a client-side session cookie without integrity protection. We modified the cookie and accessed/portal/admin, which returned HTTP 200. CVSS 8.8, CWE-565.
Management readers cannot act on this. It describes mechanism, not business consequence.
Example (too vague)
Insecure session management could allow attackers to compromise the application.
This does not say what is at risk, what we achieved, or who can exploit it. It could apply to any client.
Explain the path briefly
The attack path should be easy for a non-technical reader to follow. Focus on what each step made possible, not the technical method we used to perform it.
Example (path too technical)
By reading environment variables on the server, we discovered AWS keys and could subsequently access customer data through the AWS CLI.
This is accurate but names implementation details (environment variables, AWS CLI) that do not help a manager prioritize remediation.
Example (path in plain language)
We were able to read local files on the server. This granted us access to AWS credentials which we could use to access customer data through the application's S3 bucket.
The second version omits env variables and the CLI, but still conveys the chain: local file read, credential exposure, customer data access. That is enough for the summary.
Name the component without over-specifying
Summaries should say which part of the client's system is affected, but not with the same precision as the description. Prefer the page, feature, or role a manager would recognize. Exact URLs, query parameters, and API paths belong in the description.
| Too detailed for a summary | Enough for a summary |
|---|---|
"We discovered an open redirect vulnerability in https://example.com/login/ in the redirect parameter." | "We discovered a vulnerability in the redirect parameter on the login page which allowed us to redirect users to an arbitrary site." |
"The POST /api/users/change-password endpoint accepted a client-supplied userId." | "The password change function on the customer portal let us change other users' passwords." |
The tailored version still names where the issue sits. It drops locator detail that does not help a management reader prioritize the finding.
Focus on impact
Summaries exist so decision-makers can prioritize remediation without reading the full description. Translate technical outcomes into what they mean for the organization:
- Access: "full control of the hiring platform", "read access to all customer invoices"
- Data: "exposure of employee records in the HR system", "ability to change payment details"
- Operations: "ability to disable user accounts", "ability to deploy code to production servers"
Tie impact to assets we tested, not abstract risk categories. "High confidentiality impact" is weaker than "access to 12,000 customer records in the CRM".
Stay within what we verified. Do not claim regulatory fines, reputational damage, or compliance failures unless that is explicitly in scope and supported by evidence (see Finding titles).
Tailor to the client's environment
Generic summaries read like scanner output. Replace template phrases with specifics from the engagement:
| Generic | Tailored |
|---|---|
| "the web application" | "the customer self-service portal" |
| "sensitive data" | "customer order history and delivery addresses" |
| "administrator access" | "access to the backend used by the support team" |
| "authenticated users" | "any logged-in B2B partner account" |
If the finding affects a named system, business unit, or data type the client cares about, say so in the summary. Hostnames and full URLs are optional in the summary when the page or feature name already identifies the component.
Requirements and limitations
Clarify who can exploit the finding and what we did not test when it matters for prioritization.
Examples:
- "Exploitation requires a valid employee account on the corporate VPN."
- "We confirmed read access to the database but did not modify or delete records."
Transparency helps leadership judge urgency and follow-up work. It also avoids overstating risk.
Summaries vs. titles vs. descriptions
| Section | Audience | Purpose |
|---|---|---|
| Title | Everyone | One-line headline: impact, who, cause |
| Summary | Management, leaders, CISOs | Business impact and attack path in plain language |
| Description | Technical staff | Full analysis, steps, evidence |
The summary expands on the title. It should not repeat the title word for word, and it should not duplicate the description. If the description is long, the summary is the bridge for readers who will not read past the first page.
Common mistakes
- Burying the impact by opening with vulnerability class or methodology instead of business risk.
- Technical language such as CVSS scores, CVE IDs, or CWE references in the summary instead of metadata.
- Unverified worst case such as claiming "full network compromise" when we only showed access to one application.
- Missing preconditions such as not stating that exploitation requires VPN access or an insider account.
- Copy-paste templates with the same text for every SQL injection finding regardless of which database or data was exposed.
- Too much technical detail in the attack path, such as environment variables, CLI commands, cookie formats, full URLs, or request parameters that belong in the description.
- Over-specified components such as naming
https://example.com/login/and the exact parameter when "the redirect parameter on the login page" already identifies the issue. - Long attack paths that walk through every step when one to three sentences would cover the same outcome for a management reader.