Write the Risk Brief for the Person Who Signs the Check

I once spent days proving a system was dangerously exposed, then realized the hard part wasn’t the analysis — it was getting anyone with budget to act on it. A findings list, however airtight, doesn’t move money or people. What moves them is a brief written for the person who signs the check: short, framed in their terms, ending in a decision they can actually make. Learning to write that brief did more for the outcome than any amount of additional technical proof.

Lead with the ask, not the evidence

Engineers instinctively build up to the conclusion: here’s the system, here’s the analysis, here’s finding one through fifteen, therefore we should act. A decision-maker reads top-down and stops when they have what they need. So the brief has to open with the bottom line and the ask — what’s at risk, and the specific decision you want — in the first few sentences. Everything after that is support for someone who wants to verify, not a journey they have to complete.

The reader decides in the first paragraph whether to keep reading. Spend it on the ask, not the backstory.

Frame impact in their language, not yours

“Unauthenticated deserialization on a root process” means nothing to someone who controls budget. “A single compromised device could take down the entire fleet, expose stored credentials, and give an attacker a foothold toward our core systems” means everything. Same finding, translated from mechanism to consequence.

The translation isn’t dumbing down — it’s doing the reader’s work for them. You understand both the technical cause and the business impact; the brief’s job is to carry the impact across so the decision-maker doesn’t have to make the leap themselves (and risk making it wrong). Lead with what could happen to the business; keep the mechanism available below for the people who’ll dig.

Separate what’s proven from what’s conditional

The fastest way to lose a skeptical reader is to overstate. If you claim a catastrophe is certain and they sense you’ve stretched, they discount the whole brief. So I split findings explicitly into proven (“this default account exists; this channel is unencrypted — directly verified”) and conditional (“full remote code execution is plausible for this flaw class but we have not built a working exploit, and shouldn’t”). Naming the line between them is what makes the proven part credible.

And here’s the move that makes it robust: show that the recommendation doesn’t depend on the conditional part. If the proven findings alone justify acting, say so. Then a reviewer who wants to argue about the speculative bit can’t use it to sink the whole case.

Give options with costs, not a single demand

A brief that says “do this one thing” invites a yes/no fight. A brief that lays out options with what each costs, buys, and leaves unresolved invites a decision. The shape that works:

• Do nothing — cost zero now, buys nothing, residual risk is the full exposure.
• Contain it — cheap, buys immediate risk reduction, but the underlying problem remains.
• Contain now and fund the real fix — costs more, but actually retires the risk.

Laying it out this way respects that the decision is theirs, shows you’ve thought about tradeoffs rather than just advocating, and quietly makes the recommended option look like the reasonable middle. You’re not hiding your recommendation — you state it — but you arrive at it through their decision, not around it.

Make “do nothing” a decision someone signs

The most useful section I learned to include is the cost of inaction, written as an explicit acceptance. Not “we should act” but: “Choosing not to act means accepting, in writing, by an accountable owner, the risk that X happens to the business on a system we cannot patch.” Inaction is usually the default that wins by nobody deciding. Naming it as a choice that requires a signature changes the dynamic — now not acting is also a decision someone has to own, which is exactly the accountability that gets things funded.

The brief is the deliverable

It took me a while to accept that the writeup is the work, not the paperwork after the work. The analysis only matters if it changes what someone does, and that hinges entirely on whether the person with budget understood it and felt the weight of the decision. Lead with the ask, translate impact, separate proven from conditional, offer options with costs, and make inaction an explicit signed choice. It’s the communication side of treating security as architecture, not decoration and of capturing the why behind a decision so it survives. If you’ve written a brief that finally got a stubborn risk funded, I’d love to hear what made it land.