How Do I Write a Risk Finding the Business Will Act On?

Most security findings die in a spreadsheet because they're written for other security people, not for the person who signs off on budget. If your report says "CVE-2023-XXXX, CVSS 9.8, patch immediately," you've described a vulnerability, not a risk. The business doesn't act on vulnerabilities. It acts on consequences it can picture.

Why severity scores alone don't move anyone

CVSS tells you how bad a flaw is in isolation. It says nothing about whether that flaw is reachable, whether the asset behind it matters to revenue, or whether compensating controls already blunt it. A 9.8 on an internal dev box with no internet path and no sensitive data is not the same conversation as a 7.5 on the payment gateway. If you rank findings purely by CVSS you'll spend your credibility patching things nobody was ever going to exploit, and the finding that actually mattered gets lost in the noise.

Risk that gets acted on has three ingredients: a plausible path to impact, a dollar or operational cost attached to that impact, and an owner who can actually fix it. Miss any one of those and the finding sits in the backlog.

Build the finding around a scenario, not a scanner output

Instead of "SQL injection found on /login endpoint," write the scenario: "An unauthenticated attacker can extract the full customer table, including hashed passwords and billing addresses, through the login form. This table backs 40,000 active accounts and the same database holds order history tied to PCI scope." Now the reader isn't parsing a vulnerability class, they're picturing a breach notification letter and a compliance call.

A useful structure for each finding:

• What can happen — the attack path in plain language, one or two sentences.
• What it touches — specific system, specific data, specific business process.
• What it costs — downtime hours, regulatory exposure, customer trust, contractual penalties. Use real numbers where you have them (SLA penalty clauses, past incident costs, cyber insurance deductible).
• What it takes to fix — effort, not just "patch it." Sometimes the fix is a WAF rule today and a code change next sprint.
• Who owns the fix — a name or a team, not "IT."

Tie the finding to something the business already tracks

Every company has metrics leadership already watches: uptime SLAs, churn, audit findings from the last SOC 2 cycle, cyber insurance premiums, a specific customer contract with a security clause. If you can connect your finding to one of those existing lines — "this is the same class of issue our insurer flagged last renewal" or "this data flow is in scope for the SOC 2 audit in Q3" — you're not asking them to care about something new. You're showing them a threat to something they're already accountable for.

This is also where talking to the business side pays off before you finalize the report. A ten-minute conversation with finance or ops about what a four-hour outage on a specific system actually costs beats any generic "reputational damage" line. Get the number, cite it, move on.

Rank by exploitability and blast radius, not just CVSS

A workable prioritization approach:

1. Is it internet-reachable or does it require internal access first?
2. Is there a public exploit or is it theoretical?
3. Does it touch regulated data (PCI, PHI, PII) or crown-jewel systems?
4. What's the actual time and cost to remediate versus the cost of leaving it?

Findings that score high on reachability and blast radius but only medium on CVSS often deserve to jump the queue over a critical-rated bug buried three network hops deep behind a jump box with MFA.

Write the ask, not just the problem

End every finding with a specific request: a budget line, a change window, a policy exception to close, or a named decision needed by a date. "We recommend remediation" gets ignored. "We need a four-hour maintenance window before the 15th to patch the payment gateway, or we accept the residual risk in writing" forces a decision one way or the other. Giving leadership an explicit accept-the-risk option, in writing, with their name on it, is often what finally gets the fix approved instead.

If you want to practice turning raw scan output into findings like this, work through Korra Studio's Blue Team and Offensive segments together — pairing exploitation context with reporting drills is where this skill actually sharpens.