Guide: Building a business case for Recorded Future with hard numbers.

You've hit on the critical point: the reclaimed hours need a specific destination to be credible. A lot of teams say they'll reinvest it, but as others have noted, work expands.

One approach that's worked for me is to pre-define the "swap." Before building the case, we identified a low-value, manual recurring task (like our weekly false-positive triage for old alerts) and got leadership agreement that it would be officially sunset if the tool came in. That turned the productivity math into a guaranteed process elimination, not just hopeful capacity.

You're absolutely right about the need to link saved time to a specific delayed project. The challenge I've encountered is that the most impactful proactive work, like threat hunting, often doesn't exist as a formal, backlogged project with a budget. It's aspirational capacity.

My workaround has been to create a lightweight 'project charter' for one high-value proactive activity during the business case phase. For example, document a plan for a quarterly detection logic review that would reduce false positives by a target percentage. Then, the cost of the delayed project isn't hypothetical - it's the ongoing operational cost of those false positives that continue unchecked. This gives finance a concrete, if forward-looking, number to latch onto instead of a vague "we could hunt more."

That's a solid workaround, but you're just translating the hypothetical project into a hypothetical cost of inaction. Finance sees through that.

Better: use a past incident. Find a recent case where stale detection logic *directly* caused a pain point, quantify the manual hours spent, and project that cost forward for the next X years if nothing changes. The "delayed project" is the cost of those recurring hours. It's a real number from your own logs, not a forecast.

You've put your finger on the core implementation risk. Agreeing on the 'swap' with leadership upfront is the only way I've seen it work consistently. We documented a specific, low-value manual report that consumed 20 analyst-hours monthly and attached its formal retirement as a condition of the tool's approval. This turns the reclaimed hours into a guaranteed process elimination, not just hopeful capacity.

The attrition absorption point is also critical. If you're not backfilling roles, the saved time isn't new capacity, it's just preventing burnout. The business case then shifts to risk mitigation - the cost of a potential security error due to overworked staff versus the tool's cost. It's a harder but still valid angle.

That step function model is precisely what makes the difference between an accepted and rejected business case. The SLA breach cost you mention is the perfect, tangible variable.

A practical data point: internal communication costs can often be sourced from previous incidents where the PR/legal retainer was activated, even for contained events. The hourly rate for your CISO and general counsel during a declared incident is a known quantity. If executive notification triggers a mandatory two-hour war room with six VPs, you can attach a fully loaded hourly cost to that. The math becomes about reducing the annual probability of those war rooms.

One caveat on obtaining the "probability of exceeding SLA" figure. It requires decent historical data on investigation time distributions. If you lack that, a sensitivity analysis using a range of probabilities based on your team's qualitative assessment can still show the model's logic and force a conversation about what the real baseline is.

The delayed project angle is valid but relies on a defined backlog, which is rare. I use a different metric: tool time versus manual time.

I ran a benchmark on our last 10 intel requests. Manual OSINT collection averaged 47 minutes per request. The same request with a commercial feed took under 5 minutes for basic due diligence. That's a 90% reduction on a repeatable task.

You can't argue with the time logs. The opportunity cost is the 42 minutes per request you're spending on google-fu instead of analysis. That's the tangible impact.

Your MTTR reduction math is sound, but you're missing a step. "Applying that percentage to the estimated cost of a breach" is too broad. That industry average is a shaky multiplier.

You need to isolate the specific cost segment that faster investigation actually impacts. It's not the total breach cost, it's the hourly cost of the incident response effort during those saved hours. Use your own IR retainer fees or internal labor costs for the team actively engaged in the investigation.

That turns your 30% into a real, defensible number from your own data.

Exactly, and that past incident can be operational, not just a breach. A tool that automates IOC enrichment can shave an hour off every high-severity alert triage. If you've got 50 of those a year, that's a solid number from your ticketing system for hours saved. Finance can't dispute logged alert volumes.

The projection part is where it gets tricky. You have to justify that the volume stays constant or grows. I tie it to something measurable, like annual growth in cloud assets or user count, so the forward projection isn't just a flat line.

You're right that ticketing system data gives you solid hours to work with. But that projection is the killer.

Tying it to asset or user growth assumes the tool's efficiency scales perfectly and that your team's capacity for triage is the only bottleneck. It ignores the hidden step-up in licensing costs that usually kicks in at those growth thresholds. Your projected savings get eaten by the vendor's price increase before you even realize them.

Good point, the per-user or per-asset licensing tiers are a trap. You can show a beautiful ROI curve that falls off a cliff at the next pricing bracket.

I've started asking vendors directly for their pricing model's growth function during the eval. If they hedge, that's a red flag. Then I model the savings with their own tier thresholds baked in. Sometimes the numbers only work if you commit to a higher tier upfront, which changes the entire pitch.