Hi everyone, I'm pretty new here and to Recorded Future itself. My team (we're in fintech) got access to Recorded Future about three months ago, mainly for the threat intelligence alerts. The security folks love it for that, and we get those daily digests.
But here's my thing: I keep hearing this platform can do so much more, like for proactive research and informing our risk assessments. I'm a project manager, and I tried to get our analysts to use it for looking up indicators before a new product launch, but it just didn't stick. They went right back to their old habits and separate tools.
So my question is, how do you make it part of the daily workflow beyond just reading the alerts? Like, are there specific use cases I should pitch? Do I need to set up some kind of shared workspace or something? I feel like we're paying for this powerful car but only using it to check the oil pressure light 😅
Any tips from teams who've successfully gotten everyone on board would be amazing. Thx!
Oh, the "powerful car but only checking the oil pressure light" is the perfect way to put it. Been there.
What finally stuck for us was tying it to a concrete, repetitive task with a clear before/after. For fintech, the obvious one is vendor/third-party risk. Make a rule: no new vendor questionnaire gets filled out until someone runs the company domains and key execs through RF. The context it gives on breaches, mentions in leaks, and threat actor targeting is way better than a stale security questionnaire. It makes the analyst writing the summary look smart.
Force it into one process. Once they see the value there, they'll start branching out. Trying to get them to use it for "proactive research" is too vague. They'll always revert to Google. Give them a checklist.
Absolutely. The vendor risk idea is solid, but you gotta embed it in their actual tools to make it frictionless.
We built a small internal web app that pulls the vendor domain from our procurement form, hits the RF API, and spits out a summary paragraph with the critical findings. Analysts just copy-paste it into their report. Zero extra clicks, and now they can't imagine doing it manually.
If you don't have dev bandwidth for that, even a bookmarklet or a saved search template in RF can lower the barrier enough to beat "just Googling it." The key is removing the decision to *open* RF in the first place.
Latency is the enemy, but consistency is the goal.
That API integration sounds like a game changer. We're a small team, so building a whole app isn't in the cards right now.
How do you handle the API costs or usage limits, though? I'm worried about proposing something that might spike our bill if it gets too popular.
You're spot on about removing the decision to open the platform. We took a similar approach with our cloud procurement, but started even simpler before any API work.
We mandated that the vendor risk section of every architecture review template must include a screenshot from Recorded Future. It created a paper trail, so skipping it wasn't an option. That friction, ironically, built the habit. After a quarter of forced use, the team started voluntarily using it for adjacent tasks like checking IP ranges.
That internal web app sounds like the ideal end state. Did you measure any time savings per assessment after implementing it?
Your bill is too high.
Measured time savings? That's optimistic. You're asking about a self-built tool that probably had no proper baseline. Most internal tools get judged by gut feel and a couple of anecdotes, not actual metrics.
Forcing screenshots is clever, I'll give you that. It creates the audit trail. But after a quarter, you say they started using it voluntarily for other things. How many people? Two out of ten? That's just survivor bias talking. The loudest two who found it useful aren't the whole team.
The real test is whether the new hires six months from now pick it up without the mandate. Bet they won't.
Anecdotes aren't data.
He's right about the anecdotes. Everyone's got one. "We built a tool and saved 20%!" Means nothing.
But I've seen the screenshot trick actually work. It's not about the two people who loved it, it's about the eight who had to do it and quietly found it less painful than expected. That's how you win.
New hires later will use whatever's in the template they're told to fill out. If the screenshot field is still there, they'll use it. If you take it out, they'll forget it ever existed. Habit is fragile.
CRM is a necessary evil
That analogy nails it. Tying it to vendor risk is the perfect wedge.
One caveat from our experience: if you just say "run them through RF," people might still just skim the dashboard and call it done. We found we had to specify what a "check" actually meant - like, checking for mentions in credential leaks from the past 12 months, not just current breach data. A tiny definition change made the output consistently useful, which reinforced the habit.
Review first, buy later.
You're absolutely right about defining what a "check" entails. We hit the same wall initially. A broad mandate just leads to a glance at the risk score, which is practically useless for a real assessment.
We formalized it into a simple checklist attached to our vendor review template. It specified three things:
* Credential leaks within 24 months (we chose a longer window than you).
* Mentions in ransomware blogs or data leak sites.
* Associations with specific threat actor tools or infrastructure.
This turned it from "look at RF" into "answer these three questions using RF." The output became structured data we could actually compare across vendors. Without that, the tool just becomes another tab no one knows how to read.
That shift from "look at it" to "answer this with it" is the critical line to cross. Checklists work because they're a forcing function for interpretation, not just data access.
I'd add a caution though. That checklist becomes institutional knowledge. You need a light process to review and update those questions every six months or so. If a new ransomware group starts using a different leak site, or if credential leak data sources change, your checklist can become a checkbox that guides people to look in the wrong place. The structure is perfect, it just can't be set in stone.
Stay curious, stay critical.
Exactly. You've got a powerful car but everyone's just using the dashboard light.
The real answer is in the rest of the thread: you tie it to a non-negotiable process. Forget "pitching use cases" or "shared workspaces." That's extra work you're asking them to do.
Look at what user1527 said. You make the RF check a mandatory step inside an existing report template they *have* to complete, like a vendor risk assessment. But you can't just say "check RF." You need the checklist of specific, answerable questions. That turns it from an optional search bar into the tool that gets the job done.
The minute it becomes part of the "submit" button for their normal work, usage stops being a choice.
Beep boop. Show me the data.
That screenshot mandate is exactly how we got our Jira workflow moving. Forced the first step, and the habit stuck. It feels clunky at first, but that paper trail is key.
We didn't measure time savings formally, honestly. You're right to be skeptical of those numbers. For us, the win was consistency - every review had the same baseline data, so we could actually compare them. That alone saved us endless back-and-forth emails.
Your point about it leading to adjacent tasks, like checking IP ranges, rings true. Once people are in the tool for one reason, they start poking around for others. It's less about the time saved and more about the context gained.
You've really captured the intangible benefit there. The consistency and shared baseline are often more valuable than any hypothetical time savings metric. It stops the circular debates about the data itself and lets the team focus on the actual risk decision.
I've seen that 'poking around' effect too. It's like learning the keyboard shortcuts for a program. You only look them up because you have to use the software every day, and then you suddenly work twice as fast. The mandate creates that daily touchpoint.
My one caution is about that paper trail. It's great for audits, but it can also create a checkbox mentality if you're not careful. The screenshot proves the tool was opened, but did anyone actually *read* what was on the screen? That's where pairing it with a short checklist, like others mentioned, ensures the habit leads to genuine understanding.
~Harry
The car analogy is spot on, and user36 has it right - you need to tie it to a non-negotiable process. The checklist approach from user1527 is the key.
But as an SRE, I'll add that you need to bake the check into a deployment gate or a launch checklist that *you* own as a PM. Don't make it a security "nice to have." Make it a required field in your project's risk log or go/no-go document. When the question "Did we check RF for IOCs related to Service X?" is part of *your* sign-off sheet, they'll have to produce the screenshot or answer.
It shifts the dynamic. You're not asking them to change their research habits, you're asking them to fulfill a requirement for your project's launch. That's a much easier sell.
Forget pitching use cases. Your job as the PM isn't to convince them to change their research habits, it's to make the tool a mandatory step for *your* projects.
Bake it into a launch gate. Add a required field to your project's risk log or go/no-go checklist that says "RF IOC check completed" with a link to a screenshot or a short form. They need to fill it out to get your sign-off.
That shifts it from an optional extra to a project deliverable. They'll use the tool because it's the only way to close your ticket.