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.