FIRST CTI 2026: Intelligence That Actually Serves Someone
Summary
Notes from day one at FIRST CTI 2026 in Munich. A full-day workshop on the CTI cycle by Intel 471 and Freddy Murre reframed how I think about stakeholder engagement and evaluation metrics.
I am at FIRST CTI 2026 in Munich this week. First time attending, and day one already delivered.
The entire day was a workshop on the intelligence collection planning cycle, led by Kevin Williams and Garrett Carsten from Intel 471, together with Freddy Murre. The topic was the full CTI cycle, but approached from a practical standpoint rather than the academic framing you usually encounter.
I spent my doctoral research on automating parts of the CTI cycle. That work was grounded in the academic literature: formal models, structured frameworks, process definitions. It gave me a solid foundation for understanding the cycle’s phases and their interdependencies. But what this workshop added was the operational texture that papers rarely capture: how you actually run this process inside an organization, with real stakeholders, real constraints, and real feedback loops.
Three things stuck.
Talk to Your Stakeholders
Everyone in CTI says you need to understand your stakeholders’ needs. It sounds obvious. It should be obvious. But the rigour with which the workshop approached this was something else entirely.
They use the CTI Capability Maturity Model and Intel 471’s CU-GIR framework to systematically identify the things stakeholders care about most. Not in the we sent a survey sense. In the sense of structured engagement that maps stakeholder priorities to intelligence requirements, so the entire generation process is oriented toward producing output that someone will actually use.
The CTI-CMM gives you a maturity baseline: where does your program stand today, and what does the next level look like? The CU-GIR complements that by providing a structured way to decompose general intelligence requirements into specific, actionable collection tasks. Together, they turn understand your stakeholders from a platitude into a repeatable process.
What struck me was how much time the workshop spent on the conversation itself. Not the frameworks, not the tooling, but the actual interaction between intelligence teams and their consumers. Kevin and Garrett walked through how they conduct stakeholder interviews at Intel 471: what questions they ask, how they probe for unstated assumptions, how they distinguish between what a stakeholder says they want and what they actually need. That distinction matters. A CISO might ask for “more threat actor profiles”, but what they actually need is earlier warning on campaigns targeting their sector. The intelligence requirement looks completely different depending on which version you take at face value.
The difference between “we talked to our stakeholders and gave them our reports” and “we have a repeatable process for translating stakeholder needs into collection priorities” is enormous. Most teams are somewhere in the first category. This workshop showed what the second one looks like in practice.
Measure What Matters, and Be Honest About What Does Not
The second takeaway was about evaluation. You can generate what you believe is excellent intelligence, but confirming that without sound metrics is guesswork.
Freddy Murre’s CTI cycle mindmap maps out the full landscape of metrics you might use to evaluate the actual value of your intelligence output. It is a useful reference for identifying blind spots. The mindmap covers the entire cycle: 1. intelligence management, 2. direction, 3. collection, 4. processing, analysis, and production, 5. dissemination, and 6. feedback and metrics management. For each phase, it surfaces the kinds of things you should consider, like identifying your stakeholders, collecting the different resources, or giving a suitable dissemination strategy. But the most important phase, that stuck with me, is the last one: feedback and metrics management.
Most CTI programs default to quantitative metrics because they are easy to measure and easy to report. Number of indicators ingested, number of reports published, mean time from collection to dissemination. These numbers feel productive. They fill dashboards. They satisfy reporting requirements. But they measure activity, not impact.
Here is where I will go further than the workshop: skip the quantitative metrics entirely. Focus on qualitative ones.
Did the intelligence change a decision? Did it cause someone to reprioritize a patch, escalate an incident, or adjust a detection rule? Did a stakeholder come back and say “that report on the campaign targeting our supply chain, we used it to brief the board”? Those are the signals that matter.
There is no incentive in processing millions of alerts when they do not change a single decision at the stakeholder level. Volume is not value. And when volume becomes the metric, you are no longer doing security. You are doing securitization in the international relations sense: constructing something as a security issue and performing the rituals of response, without the substance (and maybe hunting the wrong KPIs).
The question is not “how many indicators did we process?” The question is “did any of this change what someone did?” If the answer is no, the pipeline is decoration.
Academic Meets Operational
This is the part that resonated most with my own background. My thesis work focused on automating the CTI cycle: using NLP and machine learning to extract, classify, and structure threat intelligence from unstructured sources. That work operated at the technical layer, optimizing how data moves through the cycle’s phases.
What this workshop made totally clear is that the technical layer is necessary but not sufficient. You can build the most elegant automation pipeline in the world, and it will produce noise if the intelligence requirements feeding it are wrong. Automation amplifies whatever you point it at. If the requirements are vague, automation produces vague output faster. If the requirements are precise and grounded in real stakeholder needs, automation becomes a force multiplier.
The CTI-CMM and CU-GIR frameworks essentially provide the governance layer that sits above the technical one. They ensure that what you automate is worth automating.
What Is Next
The main conference programme runs tomorrow and Thursday. Looking forward to it.