SecOps leaders keep asking how they should scope the role, and the honest answer is that many of them have already scoped it without realizing. They've defined a cyber threat intelligence analyst as the person who manages the indicator of compromise (IOC) feed and writes the weekly report.
That definition mostly records the path of least resistance and turns it into a job description.
I've spent the last while working with teams trying to connect their cyber threat intelligence (CTI) output to actual decisions inside the security operations center (SOC), and the same structural failure shows up everywhere.
The role defaults to tactical intelligence because tactical intelligence is the part a pipeline can produce on its own. Indicators arrive, get routed, and become a report.
Meanwhile detection engineering builds against vendor rules that don't reflect real adversary behavior, the incident response (IR) team meets tactics, techniques, and procedures (TTPs) it has never modeled, and leadership gets a threat summary that describes activity without changing a single decision.
The recognition exists, but the influence often does not. Most chief information security officers (CISOs) say they value CTI; far fewer say it actually drives their decisions.
In Brief:
- Too many CTI programs become IOC subscription managers with a report attached. That leaves a feed pipeline with a recurring deliverable, not an intelligence function.
- A better operating model spans tactical, operational, and strategic horizons. Many programs never escape the first because tactical work is the part automation can do alone.
- CTI should feed detection engineering as a TTP package: adversary, technique, data source, and detection hypothesis.
- 2025 threat data structurally invalidates indicator-centric programs. When 82% of detections are malware-free, an IOC feed misses the threat your organization faces.
What a cyber threat intelligence analyst actually is
Cyber threat intelligence analysts collect, process, analyze, and disseminate threat information to defenders. That is accurate, and almost useless as a scoping decision. It tells you nothing about which threats, at what level of abstraction, for which consumer, on what cadence.
I scope the role around three distinct intelligence functions with different inputs, outputs, consumers, and shelf lives: tactical work for indicators and TTPs, operational work for campaign and incident context, and strategic work for attribution, motivation, and broader risk.
When a program collapses the role to a feed manager plus report writer, it runs only one of the three and calls that the whole function.
The role spans three intelligence horizons, most programs only cover one
Treat the three horizons as separate products. A functioning analyst maintains all three at once because they serve separate consumers, and structural pressure explains why many programs only produce the first.
Tactical: indicators, signatures, short-cycle alerting
At the tactical layer, the analyst deals with malicious IPs, file hashes, domains, and signatures. It is the highest-volume, shortest-shelf-life, most automation-friendly horizon. In the operating model I use, SOC analysts and detection engineers consume it on short cycles, usually hours to days.
Many programs live here, and it's the horizon the analyst should touch least with their own hands.
At this horizon, the analyst keeps the tactical feed current, routes indicators to the right consumers, and avoids turning the feed into an indicator dump.
David Bianco's Pyramid of Pain still holds: teams that spend human time chasing hashes and IPs are aiming their effort at the adversaries their automation should already stop.
Indicators belong in automated detection, and analyst attention belongs on durable adversary behavior. If your cyber threat intelligence analyst spends most of their week here, you've bought an expensive feed subscription.
Operational: campaign tracking and adversary profiling
Operational work tracks campaigns and adversary profiles: who is targeting your sector, with what campaigns, against what infrastructure, and with what timing and intent. In this model, IR teams and security operations leadership consume it on a weeks-to-months horizon.
Operational CTI also shapes detection engineering. The output becomes a coverage question: whether the actor cluster reliably uses a set of techniques, and whether the SOC has coverage for them. That question is answerable, testable, and durable in a way an indicator never is.
TTP-based hunting matters for the same reason: techniques don't change frequently and are common across adversaries because of the constraints of the target technology. Profile the behavior and you get coverage that survives the adversary swapping infrastructure.
Strategic: threat modeling and detection prioritization
Many CTI programs produce zero strategic output. This horizon answers which threat actors matter to your risk profile over the next 6 to 12 months, and what that should drive in program investment, detection coverage decisions, and the board-level narrative.
In this model, the consumers are the C-suite and budget holders, and the shelf life is measured in months and years.
Teams often dismiss this work as fluff for executives, and that dismissal gets the value backwards. Strategic CTI, mapping adversary motivation, sector targeting, and supply-chain exposure, is what determines whether security gets translated into a business narrative that boards can act on.
ISACA frames strategic CTI as an input into long-term business strategy, risk-management priorities, and investment decisions. A program that produces nothing at this horizon has surrendered the one output that defends its own funding.
Why the role keeps collapsing to tactical
Structural pressure pulls the role toward tactical work. Pipelines produce tactical output more easily than operational or strategic analysis, so automation keeps attention on feeds.
Staffing gaps reinforce that pull when CTI programs draw from SOC and IR teams, because people who came up triaging alerts produce alert-shaped intelligence. Underfunded teams then gravitate toward the cheapest output: reports and feed handling.
I've watched teams treat this as a personnel problem, hiring harder for strategic thinkers while leaving the structural pull untouched. It doesn't work. If the role's interfaces and requirements still point at the tactical layer, the smartest analyst you can hire will still produce indicator feeds.
The requirements have to change: define them at all three horizons and build the interfaces that force operational and strategic output into the rest of the SOC.
Intelligence has to change behavior inside the SOC
Intelligence has to change a decision or a detection somewhere inside the SOC, and two interfaces carry that load in opposite directions.
Upstream into detection engineering, the analyst hands off TTPs with the metadata an engineer actually needs: adversary context, the MITRE ATT&CK-mapped technique, a detection-logic hypothesis framed as an abstract analytic, and the data sources required to support it.
A valid hypothesis is evidence-driven, testable, and falsifiable, which is a unit a detection engineer can build against, validate, and trace back to its source. An IOC dropped in a Slack channel gives them none of that.
Downstream from IR, confirmed incidents feed back to CTI as adversary-behavior validation, and the gaps surfaced in forensic analysis become refactoring tasks for new detection rules. Brief the leadership horizon on its own track, because a CISO needs a threat picture tied to business risk.
Separate artifacts serve that audience and the technical indicator audience better than one report trying to do both.
What the CTI role should not absorb
Exclusions matter as much as inclusions, and raw feed aggregation swallows the function fastest. A threat intelligence platform (TIP) that ingests indicators and pushes them to a security information and event management (SIEM) tool is still a tool, and operating it is pipeline work, not intelligence.
Threat hunting can swallow the role too. The two are tightly coupled but distinct: hunting performs proactive, hypothesis-driven operations inside your own environment while CTI monitors the external threat field. CTI produces the hypotheses, and hunters test them against internal telemetry.
Weekly threat reports create the same failure mode when nobody reads them, because report volume proves little about intelligence.
Judge a CTI program on traceability, not activity counts
Forget activity counts and look for traceability instead. Detection backlog items should point back to CTI-sourced TTPs: open the backlog and you should be able to say which adversary profile or operational report produced a rule.
The same trace should appear in IR post-mortems, where the incident review cites the operational profile that anticipated the behavior or names the gap the program should have caught.
At least one strategic briefing per quarter should drive a coverage or investment decision, because the whole point of strategic output is influence, and that influence gap is exactly what these outputs close.
Threat data makes that traceability necessary. When most intrusions are malware-free and credential abuse is a leading initial access vector, an indicator feed cannot surface the majority of intrusions. A role scoped to the tactical horizon is fighting a threat that mostly doesn't show up as a file hash.
So I'd scope the role at all three horizons, build the two interfaces, and judge it on what it changes. If your cyber threat intelligence analyst cannot trace this quarter's SOC outcomes back to their work, fix the scope you handed them before you question the hire.
Frequently asked questions about cyber threat intelligence analysts
What does a cyber threat intelligence analyst do?
A cyber threat intelligence analyst owns work across tactical, operational, and strategic horizons. Across those horizons, the analyst serves SOC, detection, IR, hunting, and leadership consumers at the right level of abstraction.
Beyond IOC feed management, the role feeds intelligence into decisions and detections inside the SOC.
How is CTI different from threat hunting?
CTI monitors the external threat field: adversary groups, campaigns, and emerging attack patterns. Threat hunting runs proactive, hypothesis-driven operations inside your own networks, endpoints, and cloud to find activity that automated detection missed.
CTI produces the hypotheses, and hunters test them against internal telemetry. They differ in cadence and scope, which is why they should be scoped as separate functions even when one person covers both.
How should CTI feed into detection engineering?
CTI should hand off a TTP package: the adversary context, the ATT&CK-mapped technique, a detection-logic hypothesis framed as an abstract analytic, and the data sources required to support it.
Per MITRE's TTP-based hunting framework, that package gives detection engineers what they need to build durable, traceable detections and avoid short-lived indicator chasing. ATT&CK is the shared vocabulary between the two teams and the coverage-tracking interface.
Does every SOC need a dedicated CTI analyst?
A SOC can cover CTI without dedicated headcount, but every SOC needs the function covered at all three horizons. In smaller teams, CTI and hunting are often additional duties for incident investigators.
If the scope narrows to tactical output, operational and strategic intelligence stays unproduced, and detection engineering defaults to vendor rules.
What skills does a CTI analyst need?
Beyond IOC analysis and TIP fluency, the role needs intelligence-requirements gathering, threat modeling, and analytic models like the Kill Chain, Diamond Model, and MITRE ATT&CK.
The Mandiant CTI Analyst core competencies framework emphasizes communication adaptation across audiences, from executive-level strategic briefings to highly technical handoffs to detection engineers. Source-credibility judgment is increasingly important given the volume of AI-generated and unverified content.