You have feeds. You have dashboards. You have a weekly report that goes to leadership with impressive numbers on it. And you have absolutely no idea who is coming for you.
That’s not an intelligence program. That’s data collection theater, and it’s more common than anyone in this industry wants to admit.
I’ve been doing this for thirty years. I’ve walked into organizations running three commercial threat intel platforms, a dark web monitoring service, and an ISAC membership — and when I ask the team “who is your most likely adversary right now?” I get blank stares. Maybe someone mentions a nation-state because they heard it on a podcast. Maybe someone pulls up a threat actor profile they downloaded six months ago.
Nobody has an answer grounded in actual analysis. They have data. Gigabytes of it. What they don’t have is intelligence.
THE DIFFERENCE MATTERS MORE THAN YOU THINK
Data is a list of 50,000 malicious IPs your feed vendor compiled from across the internet. Intelligence is knowing that a financially motivated threat actor group has been systematically targeting mid-size regional banks in the Southeast for the last 90 days, using phishing lures themed around ACH payment disputes, because they’re after wire transfer credentials — and that your current email controls have a gap that matches their known delivery method.
One fills a SIEM. The other drives a decision.
The problem isn’t the feeds themselves. Feeds have a place in a mature program. The problem is that most teams treat ingestion as the finish line. Data comes in, gets parsed, flows into a dashboard, and someone calls it “threat intelligence.” No requirements definition. No analysis cycle. No finished intelligence product that answers a specific question for a specific decision-maker.
Just ingestion. On repeat. Forever.
THE THREE QUESTIONS YOUR PROGRAM SHOULD BE ABLE TO ANSWER
I use this test constantly, with my students and with practitioners I consult with. If your program can’t answer these three questions on demand, you’re flying blind:
- Who is most likely to target your organization right now? Not “nation-states are a threat.” Not “ransomware is on the rise.” Specifically — given your sector, your size, your technology stack, your geography, your public profile — who has motive, capability, and opportunity to come after you?
- What do they want? Data exfiltration? Credential access? Operational disruption? Ransom? The answer shapes everything — your detection priorities, your response posture, your communication to leadership.
- What TTPs are they using that your current controls don’t catch? This is where intelligence connects to defense. If you can’t map adversary behavior to your own control gaps, you’re not doing intelligence. You’re reading the news.
Most programs I see can’t answer any of these. They can tell you how many IOCs they blocked last week. They cannot tell you whether any of those IOCs were relevant to an actual threat actor targeting organizations like theirs.
VOLUME IS NOT VALUE
Here’s where teams get it backwards. They measure their intel program by how much data flows through it. Millions of IOCs ingested. Thousands of alerts generated. Hundreds of IPs blocked. And they report those numbers upward like they mean something.
They don’t. A feed with 50,000 indicators that aren’t relevant to your sector, your size, or your environment isn’t intelligence. It’s noise. Expensive, time-consuming noise that your analysts are drowning in while actual threats go undetected.
I’ve watched teams spend entire shifts chasing IOC queues — blocking, alerting, documenting — without once stopping to ask: does any of this reflect a real threat to us specifically? Not to “the industry.” Not to “organizations like ours in general.” To us. Right now.
That question is the beginning of actual intelligence work. Most programs never get there.
WHERE TO START IF YOUR PROGRAM IS BROKEN
You don’t fix this by buying another feed or hiring another analyst to process more data. You fix it by going back to basics.
- Define your intelligence requirements. What questions does your security program actually need answered? Get specific. “Tell me about threats” is not a requirement. “Which threat actor groups have targeted companies in our sector and revenue range in the last 12 months, and what initial access techniques did they use?” is a requirement.
- Know your own environment first. You cannot map adversary behavior to your defenses if you don’t know what your defenses actually look like. Asset inventory. Crown jewels. Control gaps. This comes before any external data collection.
- Evaluate your feeds against your requirements. Not against vendor marketing. Against your specific requirements. Does this feed give you information relevant to your threat profile? If not, stop paying for it.
- Produce finished intelligence. A log entry is not a finished product. An alert is not a finished product. A two-page written assessment answering a specific question for a specific decision-maker — that’s a finished product. Build the habit of producing them.
- Measure what matters. Track decisions informed by your intelligence output. Not IOC volume. Not alert counts. Decisions. If your program can’t point to decisions it drove, it isn’t working.
THE BOTTOM LINE
Real intelligence production is hard, iterative work. It requires discipline, analytical rigor, and a willingness to say “I don’t know yet” instead of pointing at a dashboard full of numbers.
Most teams skip the hard work and call the data collection intelligence. Then they wonder why leadership doesn’t take the program seriously. Leadership isn’t wrong — they’re just not seeing intelligence. They’re seeing a very expensive content aggregator.
If you’re building a threat intel function from scratch or trying to fix one that’s gone off the rails, I put together a practical guide that walks through requirements definition, the intelligence cycle, and how to build finished products that actually drive decisions. You can find it at jrobertsonsecurity.gumroad.com. No fluff — just the framework practitioners actually use.