CTI Program Maturity: Why Requirements Beat Feeds Every Time

Walk into any cyber threat intelligence program that is struggling, and you will usually find the same picture. A wall of dashboards. A dozen feed integrations. A platform humming with millions of indicators. And somewhere in the middle, an analyst trying to explain to leadership why none of it has stopped a single incident in the last quarter.

Walk into a mature CTI program and the picture is quieter. Fewer feeds. Smaller dashboards. A short, deliberate set of questions pinned above the analysts' desks. And a leadership team that can tell you, in one sentence each, what decisions intelligence has changed this month.

The difference is not budget. It is not headcount. It is not even the threat landscape. The difference is whether the program is organised around requirements or around feeds.

The Feed-Led Trap

Most programs start the same way. A security leader is told the organisation needs threat intelligence. They buy a platform. The platform comes pre-wired to ingest dozens of commercial and open-source feeds. Within a week, millions of indicators are flowing in. Within a month, the team is busy. Within a quarter, the team is exhausted.

This is the feed-led trap. The program's centre of gravity is the data, not the decisions. Activity becomes a proxy for value. Analysts measure success by the volume of indicators processed, alerts triaged, or reports forwarded. Nobody asks the more uncomfortable question: did any of it change what we did?

Feeds are not the enemy. They are a collection mechanism. But when a program is organised around feeds, three things go wrong:

• Collection drives analysis. Analysts work on what arrives, not on what matters. Coverage looks broad, but it is incidental rather than intentional.
• Volume becomes the metric. The team optimises for throughput, because that is the only thing easily measured. Quality and relevance go unmeasured and therefore undervalued.
• Consumers lose trust. Stakeholders receive products that do not answer their questions. Over time they stop reading, stop asking, and stop funding.

A program in this state cannot mature. It can only get louder.

What Requirements Actually Do

Intelligence requirements are not paperwork. They are the architectural decision that separates a noise factory from a decision-support function.

A requirement is a specific, decision-relevant question owned by an identified consumer. It declares what the program is trying to learn, on behalf of whom, and to support which decision. Once that question exists in writing, every other part of the program has a reference point.

• Collection can be justified or pruned. Each source is mapped to a requirement it helps satisfy. Sources that do not map to a requirement become candidates for removal.
• Analysis has a target. Analysts know what they are trying to answer, what counts as evidence, and what level of confidence is good enough for the decision the consumer is about to make.
• Production has a shape. The format, length, and cadence of intelligence products are determined by the consumer who owns the requirement, not by the habits of the analyst writing them.
• Measurement becomes possible. A program with requirements can report coverage, satisfaction, and decision impact. A program without them can only report volume.

This is why mature CTI programs almost universally look smaller from the outside. They have fewer feeds because each one is justified. They produce fewer reports because each one is asked for. They have shorter dashboards because each metric ties to a decision. The discipline of requirements compresses the program around what matters.

The Maturity Curve

CTI program maturity is often drawn as a staircase from reactive to proactive to predictive. That framing is useful but incomplete. A more honest model tracks the program against its relationship with requirements.

Level 1 — Ad hoc

There are no documented requirements. Intelligence work is driven by whatever is in the inbox or in the news. Products are produced when an analyst thinks of something interesting. Consumers are unclear; feedback is anecdotal. Value is asserted, not demonstrated.

Level 2 — Feed-led

Tooling and feeds have been procured. The team is busy processing data. Some informal questions guide work, but they are not written down or shared. The program can describe what it does, but not why. Leadership sees activity and assumes value.

Level 3 — Requirements emerging

A first set of Priority Intelligence Requirements has been drafted, usually after a painful incident or a leadership challenge. Some collection is mapped to PIRs. Some products explicitly reference them. The rest of the program still operates on momentum, but the language of requirements is starting to appear in reviews.

Level 4 — Requirements driven

Every active collection source, analytical product, and dissemination channel is mapped to a documented requirement owned by a named consumer. Requirements are reviewed on a defined cadence with the consumers who own them. Feedback is captured and influences both requirement wording and collection choices. The program can answer, for any artefact, the question "which requirement does this serve?"

Level 5 — Requirements optimised

Requirements are treated as a living portfolio. Coverage, satisfaction, and decision impact are measured per requirement. The program retires requirements that no longer drive decisions and adds new ones as the business evolves. Collection sources are continuously evaluated for cost, uniqueness, and contribution to satisfaction. The program is small, sharp, and demonstrably valuable.

Most teams sit at Level 2 and aspire to Level 3. The leap that actually matters is from Level 2 to Level 4, because that is where the program stops being a cost centre defending its budget and starts being a function that leaders defend on its behalf.

Why Feeds Cannot Substitute for Requirements

It is tempting to believe that enough feeds, correlated cleverly enough, will eventually approximate a requirements-driven program. They will not. The two are different categories of thing.

A feed is a stream of observations. A requirement is a structured question. No volume of observations answers a question that has not been asked. You can drown in indicators and still be unable to tell your CISO whether the ransomware group that hit your closest competitor poses a credible threat to you, because nobody framed that as a question, mapped it to evidence, or assigned an analyst to assess it.

Worse, feed-led programs systematically misallocate effort. Analysts spend their time on whatever the feeds happen to surface. The threats that matter most to your organisation may not appear in commercial feeds at all, or may appear only in low-signal mentions that get lost in the volume. A requirement directs attention; a feed merely supplies fuel.

There is also a subtler harm. When a program defines itself by its feeds, it surrenders its independence. The vendors decide what is interesting. The platform decides what is correlated. The program becomes a downstream consumer of someone else's editorial choices, rather than an upstream owner of the organisation's intelligence agenda.

What Maturing the Program Actually Looks Like

Moving up the maturity curve is not a technology project. It is an operating-model change. A few moves matter more than the rest.

• Name the consumers. Write down every group that could use intelligence. For each, write down the decisions they make that intelligence could improve. If you cannot find a decision, you have not found a consumer.
• Write the first PIRs with the consumers, not for them. Sit with the consumer, frame the question in their language, and confirm they would act differently based on the answer. A PIR that the consumer would not actually use is not a PIR; it is wishful thinking.
• Audit collection against requirements. Make a grid. Sources down the side, requirements across the top. Cells get filled where a source meaningfully contributes to a requirement. Empty rows are candidates for cancellation. Empty columns are collection gaps that need to be addressed or escalated.
• Change what production looks like. Stop producing reports that nobody asked for. Start producing the smallest artefact that satisfies a requirement for its consumer, in the format and cadence they will actually consume.
• Measure what matters. Track requirement coverage, consumer satisfaction, and at least anecdotal decision impact. Report these alongside, and eventually instead of, volume metrics.
• Review the portfolio. Quarterly, walk through every requirement with its consumer. Confirm it still matters. Retire what does not. Add what is missing. Treat the requirement set as a living artefact, not a one-time deliverable.

None of these moves require a new platform. All of them require discipline that feed-led programs rarely impose on themselves.

The Quiet Test of Maturity

There is a simple test for whether a CTI program has matured beyond the feed-led stage. Pick a recent intelligence product, any one. Ask three questions.

1. Which documented requirement does this product satisfy?
2. Which named consumer owns that requirement?
3. What decision did, or could, this product change?

A mature program answers all three without hesitation. A feed-led program struggles with at least one, and usually all three.

The good news is that the path between the two is well understood. It does not require more data, more tools, or more analysts. It requires writing down the questions, naming the people who care about the answers, and then building the rest of the program backwards from there.

Requirements beat feeds every time, because requirements are how intelligence becomes a discipline rather than a data stream. Programs that internalise this stop competing on volume and start competing on judgement. That is the only competition that matters.