Stop Reporting Vulnerabilities. Start Reporting Risk.

Somewhere in your company right now there’s a dashboard showing fourteen thousand open vulnerabilities, and it is actively making you less safe. Not because the number is wrong — because it’s the wrong number. It tells you nothing about what to do Monday morning, and it terrifies exactly the people who can’t act on it. A board member who sees “14,000” doesn’t hear a to-do list. They hear “we are hopelessly exposed,” which is both untrue and useless.

Early in my career I proudly handed leadership a report that said, in effect, “there are thousands of problems.” I thought the size of the number proved how hard my team was working. What I got back was a blank stare and a very fair question: so which ones matter? I didn’t have a good answer. That was on me, not them — and it’s the day I stopped reporting vulnerabilities and started reporting risk.

A vulnerability is not a risk

A vulnerability is a weakness. A risk is a weakness that’s actually reachable, actually valuable to an attacker, and actually likely to get hit. Those are completely different things, and treating them as the same is how security teams drown. Ten thousand vulnerabilities on internal systems nobody can touch matter less than one vulnerability on the internet-facing box holding your customer data. Counting them equally is how you end up exhausted, over budget, and no safer — grinding through a giant list while the one thing that would actually end your quarter sits there untouched at row 8,000.

The three questions I run every finding through

Before a vulnerability earns any of my team’s time, it has to survive three questions. Is it reachable? A flaw on a system an attacker can’t get to is a hypothetical, not a risk. Is what it protects valuable? A hole into the cafeteria menu is not a hole into the payments database. Is it likely to be hit? Is there working exploit code in the wild, is this the kind of thing attackers are actually using right now, is the box exposed where they’re already looking?

Run fourteen thousand findings through those three filters and the list collapses to something a human can actually act on — a dozen things, maybe two dozen, that are genuinely reachable, genuinely valuable, and genuinely likely. That short list is the real work. Everything else is inventory, and inventory is not an emergency.

Severity scores lie by omission

The reflex is to sort by CVSS and start at the top. It feels rigorous. It quietly misleads you, because a severity score describes the vulnerability in a vacuum — it knows nothing about your environment. A “critical” 9.8 on an isolated internal test box with no valuable data is a lower risk to me than a “medium” 6.5 on the public server that holds customer records. The score didn’t change; the context did — and context is the entire game.

Report the story, not the count

Leadership needs your vulnerability count about as much as a patient needs the doctor to read out every value on a blood panel. Nobody wants the raw numbers. They want the diagnosis: here’s our biggest exposure, here’s what it would cost us if it went wrong, here’s what I’m doing about it, and here’s what I need from you. That’s a risk conversation, and it’s the only kind that turns into resources instead of anxiety.

When I made that switch, the tenor of every executive conversation changed. I stopped being the person who showed up with a wall of red and an implicit “be scared,” and became the person who showed up with a short, honest read on where we were genuinely exposed and a clear ask. The big number made me look busy. The risk story made me effective — and, not coincidentally, made it far easier to get the budget to fix the handful of things that actually mattered.

The risks you accept still need an owner

Here’s the part that separates a real risk program from a triage queue: the thousands of findings you decided not to fix don’t vanish. They’re still there. You made a judgment call that they weren’t reachable, or valuable, or likely enough to spend on — and that judgment can go stale. The internal box that wasn’t reachable last quarter becomes reachable the day someone stands up a new integration. The low-value system inherits a pile of sensitive data because a project needed somewhere to put it.

So I keep a risk-acceptance register — a short, living record of what we consciously chose to accept, why, who signed off, and when we’ll look at it again. It does two things. It keeps accepted risk from quietly becoming forgotten risk, and it puts a name and a date on every “we’re fine with this,” so that if the context changes, someone owns the decision to revisit it. The thousands of vulnerabilities I’m not fixing this month aren’t ignored. They’re accounted for — which is a very different thing from buried in a dashboard nobody reads.

What the fix actually costs you

There’s a hidden tax in the fourteen-thousand-item dashboard: it burns your team’s trust in the program. When people are handed an impossible list, they don’t work harder — they triage by vibe, they patch what’s easy instead of what’s important, and they slowly stop believing the list means anything. A tight list of the dozen things that matter does the opposite. It’s finishable. People can see progress. And progress you can see is what keeps a security program alive between crises.

So kill the count as your headline metric. Keep it in the back room where it belongs, as raw material. Out front, report the three or four risks that could actually hurt the business, in dollars and plain language, with a recommendation attached. The number that impresses is not the number that protects. Report the one that actually gets things fixed.