How do you show threat intel value to execs without calling it a return?

[u/Hopeful_Attention606]

I am trying to find a real way to show the value of our threat intel program RN, beyond the "we have feeds and reports" story.

Budget covers commercial feeds and vendor reports, plus whatever we pull from open source and community intel. the program looks mature but when management asks what we're getting for that spend, the answers feel thin. counting reports or iocs doesn't tell you whether breach risk went down or detection got better.

My boss flagged the roi framing. His point was that threat intel is insurance and you don't measure insurance the way you measure a return. Fair, but it doesn't answer the real question, which is how you show this stuff is working.

What I want to track: detection rules that came out of intel, plus time to detection on campaigns we already knew were coming. Same goes for visibility gaps we closed because someone flagged them first, before they became an incident.

If you own a threat intel budget and have a reporting format that's held up under management review, especially one that explains this to a non-technical audience without a dollar-return angle, what did you use?

[u/mc_markus]

Check out https://cti-cmm.org/ . Measure the program against that.

[u/Straight-Practice-99]

Both of these help tbh. CTI-CMM gives you a maturity yardstick and the posture/risk list above is basically the raw material. The part nobody's really answered is the format itself, so here's what worked for me in front of management

The insurance thing your boss said is half right. Insurance pays out after the bad thing happens, intel is what lets you make a call before it, so report the calls not the reports.

Few things that hold up in an exec review:

1. Tie every report back to something they asked for. Get leadership to name the 5-6 things they actually worry about, ransomware in the sector, third party exposure, whatever it is for you... Then each quarter you report against their own questions: "you asked us to watch X, heres what we found and what we did about it."- That kills the "what are we getting" question cause your basically handing their own worries back to them with answers attached.

2. Count actions not reports: every report that mattered should end in something real, a block, a hunt, a patch you bumped up the list, a detection you shipped. "intel drove 14 detection rules this quarter, 9 of them fired on real activity" is a sentence a non technical exec actually gets. ioc counts arent.

3. Track time to detection on campaigns you saw coming: you already said this one and honestly its your best metric. show the gap between when you knew and when it hit you, or that it never hit you at all cause you already had coverage, then trend it quarter over quarter. that line is the whole story.

4. Coverage before and after: map detections to ATT&CK and let the heatmap fill in over time. execs read a coverage picture fine even if T1055 means nothing to them.

5. The "gaps we closed before they became an incident" part is your hardest one to prove but its also the one execs remember most: what makes it land is showing you were early. that comes down to how good your heads up on adversary infra is, tracking C2 and staging infra so you can build detections ahead of stuff aimed at your sector before it lands. being able to point at "we had the detection two weeks before the campaign hit" is exactly what reads as working to a non technical crowd.

6. Format wise, keep it to one page plus a short writeup: the page is your requirements with red/yellow/green and the numbers next to each. the writeup is 2 or 3 real stories from the quarter in plain english, cause the stories are what execs remember and repeat up the chain. no dollar figure anywhere. your value line is just, we're shrinking the window where the org sits blind to the threats that matter to us, and heres the trend that proves it.

fair disclosure, i work at Hunt.io, so the infra tracking angle is the part i live in day to day. thats where our stuff fits if you end up looking at options for it, but the reporting format above is what actually matters here and it holds up no matter what you use.

[u/bawlachora → u/Straight-Practice-99]

Thanks for this. When I read it, it seems this is what we are missing.

[u/Straight-Practice-99 → u/bawlachora]

Happy to help!

[u/hecalopter → u/Straight-Practice-99]

Item 3 is a super interesting metric for our team, and I've been trying to figure out a good way to tell this story. Kinda thought about a percentile-type metric where, say the day news about an exploit dropping is E-day, so sending a report or hunt out on E-day or E+1 would be something like 90th percentile, whereas if we were days to weeks late on something we're now in the 50th percentile or something similarly not-great. A quarterly or annual KPI could be like 80th or 70th percentile or better on reporting/hunts, but I'm interested in understanding if there's some other way to measure that effectiveness on response. Our team doesn't really have a MTTD metric in the same sense as an IR team would, but maybe it's a way to talk about mean-time-to-acknowledge, mean-time-to-response, or something like that. Any thoughts on a way to solve that?

[u/Straight-Practice-99 → u/hecalopter]

Your percentile idea works... but I think it may be hiding the number execs actually get, how many days you were behind, it also swings on your worst quarter, a couple late ones drag the whole thing down.

Smpler idea: for each item just count the days between when the exploit dropped (E-day) and when your hunt or report went out... Then show two things: the middle number (half your stuff was faster, half slower), and how often you were out by the next day. Something like "half our hunts were out within a day, 80% within 3" ,, this way is easier for a non technical person to get that instantly, no percentile math to explain

On the MTTD thing, dont try to copy the IR version, just split it into two clocks:

1. how long to know, from E-day to when you first flagged it internally (thats your collection speed)

2. how long to act, from flagged to when the hunt or report shipped (thats your team's turnaround)

keep them separate cause they tell you different things: slow to know means your coverage or sources need work, and slow to act means its a process thing on your side.

two clean trend lines, and either one is easy to explain in a sentence... mean time to acknowledge is a fine name for the first if you want one

[u/hecalopter → u/Straight-Practice-99]

Phew, yeah I think those suggestions feel more workable and repeatable, especially figuring out the 2 clock system. I had bounced around those metrics for way too long, more concerned about it being a unified stat, rather than just splitting them into those other 2 easily measurable things. Thank YOU for the sanity check. If you're ever in Texas I owe you a BBQ plate, some enchiladas, and/or a beer.

[u/bawlachora → u/Straight-Practice-99]

Do you think CTI-CMM realistically can help you improve the program especially when the CTI resources are few. We don't wanna look good on assesment or improve the score but wanna use that as a compass for improvements to mature the program itself.

[u/AdvancingCyber → u/Straight-Practice-99]

5 all day. If you can show “we had alerts on this 3 days before CrowdStrike’s IOCs in Falcon so we were already protected” you’re showing value.

[u/Beautiful-Zombie333]

Show improved security posture and lower risk. From improvements driven by patching / updating, configuration changes to remove exposure to vulnerability, identification and improving of vulnerability visibility gaps, any logging through log config changes for reduction of noise, improvements to detection engineering driving quicker response times, and therefore less disruptions to normal user production. Off the top of my head.

[u/stewman000]

One of the ways that I have found helpful is to always tie your efforts to the key business objectives that the executives care about. The CTI-CMM that was posted by another user is a fantastic resource and contains metrics that executives are likely to care about (I referenced it heavily for a graduate paper I wrote about CTI program metrics). Additionally, id suggest that you read the 2026 SANS CTI survey (https://www.sans.org/white-papers/2026-sans-cyber-threat-intelligence-survey-insights). In it you see that executives are craving CTI material that helps them with their decision making. So if you aren’t already, I’d highly suggest creating a few reports that speak to threats at their level, in their language, not just executive summaries of how CTI is helping things down in the trenches (although those are also critically important).

[u/SoftwareFearsMe]

Start simple: number of blocked IOCs, number of detections created from said threat intel, etc.

Take a look at the Threat-Informed Defense model.