The Risk Rancher Field Manual, Ch. 10: The Only Numbers That Matter

October 8, 2026 · 5 min read · #security, #vulnerability-management, #risk-rancher, #metrics

Part of The Risk Rancher Field Manual, a hands-on guide to starting, scaling, and running a vulnerability management program.

You have built the engine and, if you want, automated it. Sooner or later someone, your boss, the board, a big customer, asks the question every program eventually faces: is it working? Answer it badly and good programs lose their funding to flashier ones. Answer it well and it is a short, honest handful of numbers, which we are going to actually compute.

Stop reporting vanity

The trap is to report activity and dress it up as progress. “We found forty thousand vulnerabilities this quarter.” “We blocked ten thousand attacks.” These numbers feel impressive and mean nothing. A bigger number reads as either more danger or more busywork, never as things getting better, and nobody on a board can do anything with it. Worse, chasing these metrics rewards the wrong behavior: finding more instead of fixing more. Retire them.

The three numbers that matter

Report outcomes, not activity. Download sample-remediation-log.csv: twelve findings from the queue you have been working, each with the date it was found, the date its SLA was due, and the date you verified it fixed. That tiny log is enough to compute everything that matters. All twelve rows:

Three honest gauges from the sample log. The P1 bar is just over its line, and that is the one to talk about.

Mean Time to Remediate (MTTR). For each finding, resolved date minus found date. Average them, and always break it out by priority, because one blended number hides the story. On this log:

Look at what the blended 18.2 days hides: your P1s close in 3.5 days and your P4s drag to 43. Report only the blended number and you will spend a meeting explaining an eighteen that is actually fine. Report it by priority and the story is clear: the fires get put out fast, the smoke smolders, which is exactly how you want it. A falling P1 MTTR is a program getting healthier, and almost everything in this book exists to drive that number down.

SLA adherence. What share of findings got fixed inside their deadline. Count the rows where resolved date is on or before due date, divide by the total. On this log it is 9 of 12, or 75 percent, and three findings breached: F029, F016, and F018. MTTR gives you the average; adherence gives you the discipline, and the breaches give you the list to go read. Note that the breaches are not equal: F029 was a P1 that ran four days over its three-day clock, and that one line deserves more of your attention than the two lower-priority slips combined.

Exception volume, and age. How much risk you are formally, knowingly accepting, and for how long. Count the open rows in your exception-log.csv from chapter eight. A little is healthy realism. A lot, or a growing pile of exceptions that keep expiring and reopening, is a flashing light that something upstream is drowning, usually remediation capacity. This number keeps the first two honest, because a team can hit its SLA beautifully by excepting everything hard.

If you want the arithmetic checked, metrics.py is twenty lines and prints exactly this:

python3 metrics.py sample-remediation-log.csv

MTTR P1: 3.5 days  (n=4)
MTTR P2: 13.8 days  (n=4)
MTTR P3: 31.0 days  (n=2)
MTTR P4: 43.5 days  (n=2)
MTTR blended: 18.2 days
SLA adherence: 9/12 = 75%
breaches: F029 (P1), F016 (P2), F018 (P3)

Try it. Compute all three yourself off the log first, by hand, then run the script to check: the per-priority MTTR, the adherence percentage, and the breach list. Your numbers should match the output above. Then ask the real question the numbers set up: which single breach would you walk into your boss’s office about? If you picked the P1, you are reading metrics the way a program owner does, not the way a dashboard does.

If you want a fourth, track the trend of the active backlog: is the herd growing or shrinking over time? Direction matters more than the absolute count.

How to show them

Keep it to those few, and show them as trends, not snapshots. A board does not want your scanner dashboard; they want a line that goes the right way. MTTR down, adherence up, exceptions owned and aging out. Three numbers and an arrow, in a language the business actually speaks. That is a program winning, told in a sentence.

Straight talk. Because Risk Rancher runs the workflow, it already has most of these numbers: it watched every finding travel from found to patched, so a live MTTR, the overdue count, and the split of patched versus risk-accepted versus false-positive are right there in the free tool. Two honest gaps: its MTTR is blended, and it does not break adherence out by priority, so the per-priority table you just built is still yours to compute. The manual version is that computation, once a month, which you will grow to resent. The lesson is the same whichever you pick: report the outcome, not the activity, and never let a blended average hide a P1 that is on fire.

That is the engine, built, run, scaled, and measured. One thing left, the only thing that ever really mattered: doing it tomorrow, and the day after that.

← Back to the blog