Stop reporting vuln counts to the board and start reporting risk

The number that gets a security leader in trouble at a board meeting is the one they cannot explain when a director asks the second question.

You walk in with a clean slide. Open P1s down 15 percent this quarter. It looks like progress. Then a board member who runs a business line asks what that 15 percent means for the company, and the whole story turns out to rest on a spreadsheet you built by hand the night before. You can defend the count. You cannot defend what the count means. That gap is where the credibility drains out of the room.

I have sat on both sides of that table, first as an investigator building a case that had to hold up under questioning, later inside a Big 4 practice translating technical findings for people who sign the checks. The problem is the same in both settings. A raw count is an input. A board makes decisions on exposure, ownership, and what you are asking them to fund. If you hand them the input and make them do the translation, they will do it wrong, and you will own the result.

Why the count does not land

A vulnerability count answers a question the board did not ask. They do not manage patch queues. They manage risk to revenue, to regulatory standing, to the deals in the pipeline. When you say P1s dropped 15 percent, three things go unsaid, and each one is where the follow-up question lives.

First, which assets. Fifteen percent of a number is meaningless until someone knows whether the fixed items sat on a public payment system or a lab printer. Second, who owns the remaining exposure. A board wants a name and a function, not a queue. Third, what you are asking for. Every risk statement to a board is implicitly a budget or a decision request. If it is not, it is trivia.

The manual translation layer most teams build each quarter fails on defensibility, not on effort. It is a narrative assembled by hand, which means it changes shape every quarter, cannot be traced back to evidence in real time, and falls apart the moment a director probes one line of it. You are not defending the risk. You are defending the spreadsheet.

The one-page worksheet

The fix is not another dashboard. It is a fixed structure that forces every finding through the same five columns before it ever reaches a slide. One row per material risk. Five fields, in this order.

• Asset. The specific system, dataset, or business capability at risk. Not a CVE, not a control ID. The thing the board would recognize if it broke.
• Owner. A named function accountable for the risk, not the security team. If security owns every row, the board learns that security is the only place risk lives, which is both wrong and a trap.
• Exposure. What happens to the business if this is exploited, stated in terms the board already tracks. Lost revenue, a stalled deal, a reportable breach, a regulatory finding. This is the translation from count to consequence.
• Evidence. The source that backs the exposure claim. A scan result, a finding ID, a control test, an incident. This is the column that survives the follow-up question, because you can point to where the claim comes from instead of to a spreadsheet you assembled.
• Ask. The decision or funding you want. Accept the risk, fund the fix, accept a delay, approve an exception. A row with no ask is a row that wastes board time.

Five columns is the whole discipline. Asset grounds it in something real. Owner puts accountability outside the security team. Exposure does the translation. Evidence makes it defensible. Ask makes it a decision instead of a status update. When a director asks the second question, you answer from the evidence column and the narrative holds, because the narrative was never the point. The row was.

Filling one row for a real finding

I ran a finding from Harbinger, my threat-brief tool, through the worksheet to prove it works on live input rather than a made-up example.

The finding was an agentic print-management exploit chain, the kind where an automated agent with tool access can be walked into actions no one scoped for it. As a P1 count it is one line. As a board row it reads like this.

• Asset: the document-handling pipeline that touches customer records.
• Owner: the VP who owns document operations, not the security team.
• Exposure: an attacker chaining agent tool calls could reach records inside the pipeline, which for a regulated buyer is a reportable event and a stalled security review on two open deals.
• Evidence: the Harbinger brief and the upstream advisory, both linked, both dated.
• Ask: fund the scoping fix this quarter or formally accept the exposure with the deal owner in the room.

That row takes a board thirty seconds to absorb and gives the director a real place to push. When the follow-up comes, the answer is in the evidence column. You are not defending a count. You are defending a claim you can trace.

Where this fits

Board reporting is not a tooling problem. It is a translation problem, and it is exactly the work I do for HealthTech and public safety technology vendors as a fractional seat. The worksheet is deliberately boring. It has no scoring model to argue about and no dashboard to license. It forces the five decisions a board actually needs and leaves a trail back to evidence for every one of them.

If your quarterly board prep is a hand-built spreadsheet that you dread the second question about, the fix is not more automation on top of the count. It is a structure that carries the risk, names the owner, and points at the evidence before the meeting starts. Build the row once for your worst finding and the pattern will hold for the rest.