Knowledge Base · Intelligence Fundamentals

The intelligence cycle

7 min read · Updated September 2026

The intelligence cycle is the repeating process by which an organisation turns a question it cannot answer into intelligence somebody can act on. It runs in four phases, direction, collection, processing and dissemination, with feedback and review running throughout, and its purpose is to move what you know you do not know into the known, to a standard good enough to support a decision.

Every intelligence function, in every sector, is doing the same thing underneath: taking a question somebody needs answered, finding material that bears on it, working out what that material means, and getting the answer to whoever has to act. The intelligence cycle is the structure that makes that repeatable rather than accidental. It came out of military doctrine, where it is set out in the US Army's intelligence field manual, and it transferred into commercial cyber threat intelligence largely intact because the underlying problem is the same one.

What it is not is a reporting workflow. A team can produce a great deal of output without running an intelligence cycle at all, and that is the most common failure mode in this discipline: collection that nobody directed, analysis that answers no stated question, and distribution to a list rather than to a decision.

Known unknowns, and the point of the exercise

The clearest way into the cycle is the distinction between what you know, what you know you do not know, and what you do not know you do not know. The middle category is the cycle's subject. A known unknown is a question you can actually pose: whether a ransomware group active against your sector has your kind of infrastructure in scope, whether a vulnerability in a product you run is being exploited, whether a supplier has been breached. Those are answerable, and the cycle exists to answer them systematically instead of when somebody happens to notice.

The third category, the unknowns you have not thought to ask about, never disappears. A mature function accepts that and structures itself so that new questions enter the cycle continuously, rather than pretending that a fixed requirement set will hold for a year.

Direction

Direction decides what the organisation needs to know, and frames it as specific questions rather than as topics. "Monitor ransomware" is not a requirement; it is a subject heading. "Has this group been observed targeting financial services in the last week, and with what initial access method" is a requirement, because you can tell whether it has been answered.

That framing work is where priority intelligence requirements come from, and it is also where requests for information get filtered. Both describe questions, they overlap constantly, and a function that does not manage the overlap ends up answering the same thing repeatedly for different people.

Three tests are worth applying to any question before it enters collection:

  • Is it relevant to the business? Not interesting, not alarming, but connected to something the organisation does, owns or depends on.
  • Can it actually be answered? With assets you have, in a timeframe that still matters.
  • Has it already been answered? And if so, is the answer somewhere the asker can find it?

It also matters to separate standing tasks from specific taskings. Watching a threat landscape continuously is a different commitment from answering one question this week, and conflating the two produces requirements that are never finished and never closed.

Document the questions, including the ones you could not answer. An unanswered question is institutional knowledge: it tells you where the gaps are, and it stops three analysts independently discovering the same dead end.

Direction is not a planning stage that happens once a year. It is in constant motion, and it is usually triggered by something concrete: a phishing incident the SOC is working, an alert from an endpoint tool, a report from a peer in your sector. Every one of those arrives as a new question, and the cycle has to be able to absorb it.

Collection

Collection is the act of pointing the right asset at the question. Those assets typically include vendor intelligence feeds, open-source collection, internal telemetry such as SOC logs and endpoint detections, and material shared through law enforcement or industry groups.

The discipline here is that collection is targeted, not opportunistic. The asset has to match the type of question: a feed of indicators will not tell you how a group operates, and a strategic report will not tell you whether a specific hash has been seen on your estate. A team that knows its own tooling knows which questions it can serve and which it cannot.

That leads to the most useful habit in this phase. When no asset exists that can answer a stated requirement, that is a finding, not a failure. It is a capability gap, it should be recorded as one, and it should go to whoever decides on investment. A requirement quietly abandoned because nothing could answer it is the worst outcome available: the organisation still has the question, and now nobody knows it is unanswered.

Volume is not the measure of this phase. Precision, corroboration and timeliness are.

Processing

Processing turns collected material into a product somebody can read. It covers corroborating sources against each other, deconflicting accounts that overlap or disagree, extracting the pattern that matters, and writing the result for the person who asked.

Some models split this into separate processing and analysis phases. The four-phase version keeps them together, which is a defensible simplification as long as the analytical work is genuinely happening and not collapsing into summarisation.

Whatever it is called, the product has a consistent internal shape:

  • Situation. What happened.
  • Analysis. Why it happened, and what it means for us.
  • Recommendations. What should be done about it.

Consistency of format is not house style for its own sake. A reader who knows where the assessment sits in every report will read the assessment; a reader who has to hunt for it will eventually stop opening the report at all.

Dissemination, and the feedback that closes the loop

Dissemination is getting the finished product to the audience that needs it, which involves more than sending it. It includes grading and classification so the recipient knows how to handle it, choosing a channel that suits the audience rather than the sender, and arriving while the intelligence still changes what somebody would do.

Feedback is the half of this phase that most functions under-build. Three questions close the loop: did the intelligence reach the person, was it useful, and did it prompt any action. Note the boundary in the third one. An intelligence team does not own the outcome and should not be measured on it, but it should make reporting an outcome as easy as possible, because without that signal the next cycle's direction is guesswork.

There is a hard-earned principle underneath all of this: it is better for intelligence to reach slightly the wrong person than to reach nobody. A report delivered imperfectly can be redirected by whoever receives it. A report nobody saw cannot be recovered by anything. Visibility beats perfect routing, and teams that optimise the routing until distribution becomes a bottleneck have chosen the worse failure.

Why it behaves like a cyclone rather than a circle

Drawn as a diagram, the cycle is a neat loop with four boxes. Running it feels nothing like that, and the better image is a cyclone: continuously turning, drawing in new material as it goes, generating its own momentum, and useful only when it makes landfall.

That last part is the test. A cyclone that stays out at sea has no effect whatever its size. Intelligence that never reaches a decision is the same: energy expended, nothing moved. It is entirely possible for a team to run every phase competently and still produce nothing of value, if the output does not land somewhere that can act on it.

Where functions get this wrong

Four patterns come up repeatedly.

  • Collection without direction. Feeds are bought, material accumulates, and nobody can say which question any of it answers. This is the easiest failure to fund and the hardest to notice.
  • Direction that is never revisited. Requirements set once and left, while the business changes what it does and the threat landscape changes what it faces.
  • Dissemination as a distribution list. The same report to the same recipients regardless of content, which trains everyone to ignore it.
  • No feedback mechanism at all. The cycle becomes a line: it starts at direction and stops at send, and next quarter's requirements are set from the same assumptions as last quarter's.

Each of these is survivable. Together they describe a function that produces reports and no intelligence.

How this maps to the platform

Conundrum is built around this cycle rather than around a feed, which is why its capabilities are named after the phases rather than after features. Requirements come first and everything downstream is answerable to them: collection runs against the questions you set, generated reporting carries the situation, assessment and recommendations structure, dissemination routes on rules your team controls, and what your analysts do with the output feeds back into what surfaces next.

Two of the four phases are split in the product where doctrine keeps them together. Processing appears as separate analysis and production capabilities, because in practice the work of interrogating intelligence and the work of writing a finished report are done by different people at different moments, and a tool that conflates them serves neither well.