A cyber threat intelligence capability is a standing function that answers an organisation's stated questions about external threats, continuously and to a predictable rhythm. Building one is mostly a matter of people, clarity and routine rather than tooling, and it works as a programme that runs indefinitely, not a project that finishes.
Read first: The intelligence cycle (the process the capability runs)
Most of what determines whether an intelligence function succeeds is decided before any tool is bought. It is decided by who is hired, by whether anyone can say what the team delivers and to whom, and by whether the work has a rhythm that survives a bad week.
The foundation of the capability is the people in it. Technical ability is necessary and nowhere near sufficient: what distinguishes a good analyst is analytical instinct, curiosity, and the ability to think the way an adversary thinks. The useful shorthand is that they should be journalistic, possessed of an enquiring mind that keeps asking what is actually going on here.
Those qualities are difficult to teach, which is an argument for weighting them heavily at hire. Diversity of background helps for the same reason: people who have come through military intelligence, law enforcement and conventional cybersecurity see different things in the same material.
A broad understanding of cybersecurity is table stakes. The value comes from analysts with genuine depth in a particular threat vector: malware, phishing, denial of service, insider, geopolitical activity. That depth is what produces reporting with context and nuance instead of competent summary.
The failure mode is specific and worth naming. An analyst who reports tactically or strategically without grounded understanding of the vector itself will produce incomplete assessments. What goes missing is the credible "so what": the line connecting technical detail to a business consequence. A single tactical event, an unusual PowerShell execution, one phishing email, can carry strategic weight in risk appetite, regulatory exposure or customer trust. Being able to trace that impact across the cycle and state it plainly is what separates an expert from a generalist.
Every piece of intelligence should arrive with an explanation of why it matters to this organisation and what ought to be done about it. Without that, it is information, and it makes the reader do the analytical work the function exists to do for them.
This is the single most useful discipline to impose early, because it is self-correcting. A team that has to write the "so what" on every product quickly discovers which of its collection actually supports one.
Consistency is rare in this discipline and essential to it. A defined daily cadence covering monitoring, triage, reporting, collaboration and feedback does two things at once: it builds dependability, and it frees analysts from spending their best cognitive hours deciding what to do next.
Routine also makes anomalies visible. When the shape of a normal day is known, a day that does not fit stands out, and that contrast is itself an intelligence signal.
Standard operating procedures are the scaffolding for the routine. Paired well, they improve repeatability, ensure coverage across vectors, enable handoffs between people who were not in the room, and give new joiners something to learn from.
Over-engineered procedure is its own risk. Make the SOPs too rigid or too elaborate and you will push away exactly the analysts you worked hardest to hire, because the people who thrive on clarity and instinct do not thrive on bureaucracy. Worse, analysts become reluctant to deviate from the script at precisely the moments when judgement is required.
Good procedure is clear and actionable rather than academic, defines what good looks like rather than only listing steps, and leaves explicit room for analyst interpretation. The test: does it enable the work, or inhibit it.
A project is a temporary effort to produce change. A programme is a sustained structure that delivers output over time. Intelligence is the second kind of thing, and the distinction has teeth.
Organisations sabotage their own intelligence routine by loading it with internal projects that pull analysts off the work. Projects feel like progress and frequently are not: they consume time, fracture focus and erode the operational consistency the function depends on.
There is an uncomfortable observation here too. Endless projects often mask a leadership gap. Where there is no clarity about what needs doing, large working groups and exploratory initiatives form instead of decisions, and that usually happens when leaders lack the operational depth to make the change themselves.
Risk is not threat. Threat is what adversaries are capable of and willing to do, and it exists entirely outside your control. Risk is the potential for loss when a threat meets a vulnerability of yours. An intelligence function owns the first and informs the second; confusing them turns the team into a control-assurance function with a more exciting job title.
The function disseminates; it does not operate. Once intelligence is handed to the SOC or to incident response, direct involvement in what happens next should generally end. Operational teams act on it. The intelligence team is accountable for accuracy, relevance and timeliness, not for managing the application of its own product. Teams that cannot let go of that boundary end up doing neither job well.
Intelligence-led is a moment, not a permanent state. Being intelligence-led means intelligence informs and shapes the early stages of planning and response. As a situation develops and new information arrives, the lead can and should shift to the operational teams whose work the situation now demands. Insisting on holding the lead throughout is a misreading of what leading means.
Several pressures recur across organisations, and it helps to name them rather than treat each as a local problem.
Three things, and they are unglamorous: a leader with real operational experience rather than only management experience, a defined plan setting out what the team delivers, to whom and when, and a minimal-fuss implementation of tools and process that supports output rather than bureaucracy.
The leadership job after that is mostly protective. A good routine is a disciplined flow rather than a rigid checklist, and the most common way it dies is excessive experimentation from above. The best intelligence teams operate like a well-run programme: consistent, purposeful and quietly effective.
Conundrum is built to carry the routine rather than to replace the capability. Collection runs continuously against the requirements you set, so the daily cadence does not depend on somebody remembering to check. Reporting arrives in a fixed structure, which is the "so what" discipline expressed as format. Dissemination is rule-based and logged, which draws the boundary between producing intelligence and operating on it.
What the platform cannot supply is the expertise. It reduces the resource-intensive parts of the cycle so that a small team spends its time on judgement rather than assembly, which matters most to exactly the understaffed functions described above. It does not make a generalist into a vector expert, and any tool claiming otherwise is selling something.
