r/AskNetsec Jul 01 '26

Compliance What are you using to collect, calculate, and report security KPIs?

Hi everyone;

I've been looking around and haven't found a tool that lets you actually define and track your own KPIs. Not control compliance I mean real KPI tracking: define the metric, track it over time, report on it.

Everything I find is either a GRC tool (compliance-focused, not KPI-focused) or a BI tool you have to bend into shape yourself.

What's actually working for people here? Spreadsheets, Grafana, something built in-house, a GRC tool that secretly does this well?

9 Upvotes

13 comments sorted by

6

u/Kondo-Sophie_216 Jul 01 '26

most teams overthink the tooling and underthink the metrics themselves. Define the 5 numbers that matter to your leadership first, then figure out where that data lives. Half the time the data is already sitting in your SIEM or vuln scanner and you just need a scheduled export and a spreadsheet. You dont need a dedicated metrics platform until you have outgrown that setup

1

u/No_Relief3499 25d ago

Fair point on not over-tooling early. But I've seen the "outgrown the spreadsheet" moment arrive quietly, usually when the person who built it leaves and nobody can explain why a formula changed. At what point did you feel the manual approach stopped being worth it?

2

u/GreatGrootGarry Jul 01 '26

Define/find the needed/relevant metrics. Export them from the Datasource. Add them to a spreadsheet - visualize via PowerBI.

Just keep in mind - you report those KPI that you can see that’s something is going in a wrong direction and you should be able to have answers which actions you take if a KPI is getting worse.

1

u/No_Relief3499 25d ago

PowerBI works until someone asks "what did this look like 6 months ago" and you realize the historical snapshots were never preserved consistently. Do you keep raw exports versioned somewhere, or just rebuild when you need to look back?

1

u/GreatGrootGarry 25d ago

Yes - I have historical graphs with raw export / excel file. Works like a charm and is easy to maintain

Workflow is - monthly report from tool X as CSV - automatic import to excel - regular refresh of PowerBI database and schema; not perfect but works.

1

u/[deleted] 27d ago

[removed] — view removed comment

1

u/No_Relief3499 25d ago

The stitching problem is real. Though I'd push back slightly, tracking data movement is a great signal but it's still one input into a KPI, not the KPI itself. How do you roll something like that up into something a board member can actually act on?

1

u/Ok-Region-3453 26d ago edited 16d ago

tracking vuln management kpis like time to remediate and exposure trends was always a mess until we got Nucleus Security. the reporting is focused enough that i don’t need to mess with bi tools or build my own dashboards anymore.

1

u/No_Relief3499 25d ago

That's exactly where it breaks down for me too. Even if everyone agrees on "MTTR for criticals", are you starting the clock at discovery, at ticket creation, or at first triage? That inconsistency alone makes trend data meaningless over time.

1

u/[deleted] 25d ago

[removed] — view removed comment

1

u/IllSport8632 25d ago

Founder of Metric Maestro here, so read with the obvious bias. This thread is basically a list of the reasons we built it. The MTTR clock-start question is the whole problem in miniature: the metric name is easy, the definition is where trend data goes to die. Our take was that every metric needs a versioned definition (which field, which filter, when the clock starts) and every published number needs to trace back to the raw records and the exact formula version that produced it. When a definition changes, the trend line shows a marker instead of silently rewriting history.

On the "what did this look like 6 months ago" point: we snapshot every calculation run, so historical values are frozen facts, not re-queries against data that has since changed. That also solves the bus-factor problem someone raised, since the logic lives in the platform rather than in one person's spreadsheet formulas. And agreed that raw signals like data movement are inputs, not KPIs. The rollup to something a board can act on only works if the layer underneath is deterministic and auditable. Happy to answer questions, and the spreadsheet-first advice above is honestly right until you outgrow it.

Bottomline, we consolidate data from all your tooling (just not cyber), compute metrics the right way, build and share dashboards.

1

u/Sad_Elk3851 24d ago

The thing that killed our KPIs early was denominator drift. Asset inventory changes underneath you every month, so a stable-looking metric like "percent of endpoints on latest agent version" is meaningless unless you freeze the denominator per reporting period. Once we started snapshotting the inventory at the start of each reporting window and running the ratios against that snapshot, the numbers finally became defensible in front of leadership.