Threat Intelligence Essentials: Which Customer Are You Serving?
Most CTI programs fail because nobody asked who the intel was for.
Cyber threat intelligence aims to support decision making across different layers of security operations. But in practice, teams often overlook one simple fact: people at different levels have different needs. If our understanding of their day to day responsibilities is only surface level, the intelligence team cannot truly help them. This is also the core problem with many CTI products. They serve the same data, the same dashboards, and the same reports to everyone regardless of their role or seniority. Yet the question “Who is my customer?” is the most important one.
In this post, the goal is to define these customer profiles and take a quick look at the types of problems each one deals with. For simplicity, I’ll group all cybersecurity roles (offensive or defensive) into three categories: Analysts, Engineers, and Leaders.
1) Analysts
SOC analysts, incident responders, forensic analysts, threat hunters, vulnerability analysts, pentesters…
Analysts deal with real threats and real vulnerabilities. Their job is to identify active attacks on the organization’s systems and uncover weaknesses that could enable those attacks. In other words, they carry the majority of the operational load. Their workflow typically follows: Validation → Risk Assessment → Response.
Their core challenge is reducing the time between validation and response. It’s simply not possible for them to thoroughly investigate the hundreds of potentially risky events that may appear throughout the day.
Below are the common questions analysts ask and how CTI can help answer them.
Q:
Is this alert actually malicious, or is it a false positive?
How CTI helps:
— Hash/IP/domain reputation checks
— Sandbox analysis
— Automated malicious/benign classification via context enrichment
Q:
I found malicious activity on a system. How serious is this? How deep should I investigate?
How CTI helps:
— Campaigns related to the artifact
— Adversary “actions on objective”
— Example cases showing real-world impact
Q:
I’m investigating an incident. What is the attacker’s next step likely to be? Where should I look?
How CTI helps:
— Campaign or threat actor TTPs
— Step-by-step breakdown through MITRE ATT&CK
— Suggested pivot points for investigation
Q:
I’m flooded with new CVEs every day. Which of these actually matter to me?
How CTI helps:
— CVE relevance filtering via asset inventory or ASM integration
— Automatic prioritization of organization-specific vulnerabilities
Q:
I found CVE-XYZ in my environment. How urgently do I need to patch this?
How CTI helps:
— Active exploitation information
— Campaigns leveraging the vulnerability
— Real-world impact examples and threat actor usage frequency
2) Engineers
DevSecOps engineers, cloud security engineers, network/IT security engineers…
Engineers don’t deal with threat investigation directly; their job is to build scalable systems that perform those detections and harden environments automatically. The keyword here is “scalable.” Engineers don’t solve problems case-by-case. For example, determining the sensitivity of a single hardcoded API key is an analyst’s job. But designing a system that can find that key across hundreds of repositories is the engineer’s responsibility.
They work on large scale challenges such as patch management, detection engineering, software supply chain security, and identity lifecycle management. And with large scale comes a major trade-off: the bigger the scale, the lower the accuracy.
Understanding the importance of a few CVEs on one server is easy; scaling that to tens of thousands of servers leaves you drowning in hundreds of thousands of CVEs.
For analysts, the goal of CTI was “maximum context.”
For engineers, it’s the opposite: clean, structured, machine-readable data.
Most of the time, it’s not a human consuming the CTI. It’s the system they built.
This is why the CTI strategy for engineers is built around enrichment: improving the quality and structure of the data their systems rely on.
Q:
My detections produce too many false positives. How do I reduce them?
How CTI helps:
— Automatic correlation with external reputation sources
— Normalized risk scoring
— Noise-reducing global allow/deny lists
Q:
Patch management at scale is overwhelming. How do I prioritize?
How CTI helps:
— Exploitation-in-the-wild intelligence
— Threat actor usage patterns
— Sector/region-specific CVE trends
— Alignment with CISA KEV or similar authoritative lists
Q:
How do I secure our software supply chain at scale?
How CTI helps:
— Compromise history of popular libraries
— Malicious package trends
— Version-level risk scoring
— SBOM enrichment and dependency insight
3) Leaders
Head of Security, Director, InfoSec Manager, CISO
Security leaders act as the bridge between the company’s executive management and the security team. In practice this means:
Answering questions and requests from the executive layer,
Identifying security needs and convincing leadership to invest in them.
They often use tools like risk catalogs, maturity frameworks, SWOT analyses, and industry benchmarks. Their biggest challenge is building a compelling narrative that justifies investment. A block of forensic output or malware analysis is useless to them unless it’s translated into business-level meaning.
This is why the CTI strategy for leaders is interpretation.
The value comes not from raw intel, but from connecting the dots into a coherent story.
Q:
A new attack/vulnerability is all over the news. Does it affect us? Do I need to notify the executives?
How CTI helps:
— Targeting patterns of the campaign
— Active exploitation status
— Business impact ready summaries
— Executive friendly briefing materials
Q:
A threat actor claims they have our data. Is the claim legitimate? Do I need to involve the data protection office?
How CTI helps:
— Verification of leaked data (samples, patterns, previews)
— Dark web/voucher analysis
— Actor motivation and credibility
— Regulatory impact assessment
Q:
We might be impacted by campaign XYZ. What is the typical impact on its victims?
How CTI helps:
— Activities observed on other victims
— Potential business impacts (downtime, financial loss, exposure)
— Actor targeting criteria
— Executive-level narrative translation
Q:
We’re preparing a use case to procure a new security product. What are the sector/regional trends? What do the attackers targeting us look like?
How CTI helps:
— Sector-specific threat trend reports
— Benchmarking against similar organizations
— Threat landscape summaries
— Adversary motivation and sophistication profiles
Conclusion
A CTI program is only effective if it knows exactly who it serves. Analysts, engineers, and leaders consume intelligence in completely different ways, speak different languages, and expect different outputs. The goal is to deliver the right information to the right profile in the right format.
Analysts need speed.
Engineers need scale.
Leaders need narrative.
And the true value of threat intelligence lies in empowering the right decision maker at the right moment, with the right context.