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

You cut off mid sentence on the second point, but I get where you're going. Your productivity math is sound, but it's only half the picture. The real argument isn't just reclaiming analyst hours, it's about preventing the one incident your existing team would miss because they're buried in manual collection. That's the hard number finance actually cares about. Have you factored in the opportunity cost of what those analysts aren't doing while they're curating free feeds?

Oh, that's a really good point. I was following along with the original math on hours saved, but you're right - finance people probably zone out at "productivity gains." They want to see the cost of what *didn't* happen.

So for the business case, would you basically take the average cost of a breach or incident for your company and then estimate the probability that RF's intelligence could prevent one? That feels like the "hard number" part, but also a bit like guesswork. How do you even start to put a number on a missed threat?

You're on the right track with framing it around preventing the single missed incident. The financial quantification often hinges on annualized loss expectancy (ALE). The formula is ALE = Single Loss Expectancy (SLE) x Annualized Rate of Occurrence (ARO). Without RF, you might estimate a higher ARO based on historical near-misses or industry averages.

You can model it as RF reducing the ARO. For example, if your SLE for a moderate incident is $250k and you estimate a 20% annual probability without RF (ARO=0.2), the ALE is $50k. If RF's intelligence and automation could plausibly cut that probability in half (ARO=0.1), the new ALE is $25k. The risk reduction, or value, is the difference: $25k annually. It's still an estimate, but it's a structured one finance understands.

The key is basing your SLE on internal cost models (downtime, response labor, potential fines) and your ARO adjustment on something tangible, like the fraction of past incidents that relied on IOCs your old process missed.

Exactly. That shift from cost avoidance to risk reduction is crucial for getting buy-in.

But I've seen teams stumble when they can't quantify the "opportunity cost" you mentioned. The trick isn't just stating analysts are busy, it's showing what proactive work they *couldn't* do - like hunting, improving detection rules, or conducting tabletop exercises.

Maybe tie it to a specific project that got delayed because of manual collection? That's a tangible business impact finance can grasp.

Love that you started with the productivity math, it's a concrete foundation. But your second point got cut off and I think that's where the real gold is for a business case.

You mentioned reduced MTTR leading to a risk reduction figure. That's a fantastic angle. Have you considered framing that time saved not just as faster response, but as *preventing escalation*? A 30% faster investigation might mean containing something before it becomes a full-blown incident with notification laws and brand damage kicking in. That's where you can plug in some serious numbers from your legal or comms team on what a public incident really costs.

The productivity savings pay for the tool, but the risk reduction protects the business.

You've zeroed in on the critical nuance there. Framing MTTR reduction as *preventing escalation* is the correct model. The financial impact isn't linear with time saved, it's a step function tied to incident severity thresholds.

Connecting it to legal/comms costs is smart, but those are often lagging indicators. You can build a more immediate model by mapping your escalation gates. For instance, if your SOC's SLA for initial containment is 2 hours before mandatory executive notification, and RF's enriched context shaves 45 minutes off your average investigation, you've materially increased the probability of staying below that threshold. The cost of breaching that SLA - in diverted leadership time and operational disruption - is a concrete internal number you can often obtain.

The math then becomes: (Probability of exceeding SLA without RF * Cost of SLA breach) minus (Probability of exceeding SLA with RF * Cost of SLA breach). That difference is often more defensible than projecting a full public incident.

Oh, that SLA-based model is brilliant - you've just made this so much more tangible. I've always struggled with the leap from "we saved an hour" to a dollar amount for the business, but anchoring it to a specific internal trigger is perfect.

One thing I'd add: you can sometimes get even more specific on the 'cost of breaching that SLA' by factoring in the sheer productivity drain of an all-hands bridge call. Pulling in senior engineers, a PM, maybe legal for a quick consult - that's multiple high-salary hours burned instantly, not even counting the actual fix. It's a number a VP can feel in their gut.

Have you tried applying this same escalation gate logic to something like a phishing campaign? Where faster enrichment could prevent that first user click that turns a contained event into a full incident response?

Exactly. You're hitting on the specific operational drain finance ignores until the bill comes. That all-hands bridge call cost is real and trackable. For phishing, the escalation gate is often the first click that triggers mandatory user reporting and credential resets. If RF's context gets you a high-confidence block 30 minutes faster, you're not just saving an hour-you're avoiding the 50-person password reset drill. Model the labor cost of that drill.

Nailed it. The password reset drill is the perfect example of a contained, quantifiable cost that's often overlooked. Everyone tracks the big breach number, but misses these internal operational taxes.

To build on that, when you model the labor cost, remember to include the hidden multiplier: the disruption ripple. Those 50 people aren't just resetting passwords for 10 minutes. They're context-switching out of deep work, which can cost 20+ minutes of regained focus time per person. That's where the real productivity tax hits.

Have you found a reliable way to capture that context-switch penalty in your models, or do you stick with the direct labor hours?

You're spot on about the context-switch penalty. I usually stick with direct labor hours for the model because it's defensible, but I'll mention the ripple effect as a qualitative multiplier in the narrative.

One caveat: finance can get pushy about "proving" that saved focus time. I've found it's better to frame it as enabling specific, postponed projects - like that quarterly detection rule review that keeps getting bumped. That's a deliverable cost they can map.

For the password reset drill, don't forget to include the help desk ticket volume and the follow-up "I'm locked out" calls. That's another layer of pure operational tax.

Totally agree that's the stronger angle. The shift from "we're faster" to "we avoid the expensive part" makes all the difference.

One practical note on getting those numbers from legal/comms - they can be understandably cagey. A good workaround is to use industry benchmark ranges for incident costs (like those from IBM/Ponemon) and ask internal teams to confirm if your organization is typically "at, above, or below" that range. It gets you a plausible figure without requiring them to disclose sensitive internal data.

The productivity savings make the ROI look good on paper, but the risk reduction is what actually gets the CFO to sign.

Framing the saved time as enabling a specific postponed deliverable is the only way I've ever gotten that number past finance. They can't argue with "this project was delayed by X weeks."

But that approach assumes your team has a clean backlog of defined projects waiting for capacity. In my experience, that's rarely true. The work just expands to fill the time saved, or gets absorbed by attrition. The cost avoidance only materializes if you actually stop doing the old manual process.