Why Purchased Threat Intelligence Sits Unread

Intelligence Programmes · June 12, 2026 · 9 min read

A pattern repeats itself in security programmes with enough budget to have the problem. A feed is procured. It is integrated, in the sense that indicators arrive somewhere. A dashboard appears. Eighteen months later, at renewal, somebody asks what the feed has actually done, and the room discovers that nobody can name a single decision it changed.

The reflex is to blame the vendor’s data quality. Occasionally that is fair. Far more often the feed is fine and the programme around it never existed. An intelligence product is an input to a decision; if the decision was never identified, no quality of input will rescue it.

Intelligence is bought as inventory and consumed as judgement

Feeds are sold in units that are easy to count: indicators per day, reports per quarter, actors tracked. Those units make procurement tractable and tell you almost nothing about utility, because utility depends on a property of the buyer, not the seller — whether there is a person or a system on the other end whose behaviour the data can alter.

Try the inverse test before any purchase. Name the decision. Not the capability, the decision: whether to block this, whether to hunt for this, whether to bring the patch window forward, whether this campaign changes what we build next quarter. Then ask who makes that decision, how often, and what they currently use instead. A feed that cannot be attached to an answer in that shape is being bought for reassurance, which is a legitimate purchase but should be priced as one.

Indicators answer a question most estates cannot ask

The dominant feed format is a list of atomic observables: addresses, domains, hashes, occasionally URLs and certificate fingerprints. The question such a list answers is narrow and specific — have I seen this, ever?

Answering it requires two things that are quietly expensive. It requires telemetry that records the relevant observable across the estate, and it requires retention long enough that a retrospective look is meaningful. An organisation with thirty days of proxy logs and no endpoint process telemetry can check a fraction of what arrives, over a window shorter than most intrusions persist. The feed is not wasted because the indicators are wrong. It is wasted because the question cannot be asked.

The corollary is a sequencing rule that almost nobody follows: build the ability to search history first, then buy things to search for. Retrospective hunting across whatever telemetry already exists is the highest-yield integration for any feed and is usually implemented last, after real-time blocking and after the dashboard.

Relevance is not a filter you can apply afterwards

Aggregate feeds describe activity against everyone. Most of it describes adversaries whose targeting has no intersection with the buyer — different sector, different geography, different asset class, different motive.

Vendors offer sector tagging to address this, and it helps at the margin, but sector is a crude proxy. What actually determines relevance is the shape of what you have: which technologies you run, which of your data would be worth something to somebody, who you are connected to as a supplier or a customer, and whether you are a plausible route into someone more interesting than you. That list is the beginning of a requirements document, and writing it forces a conversation about the organisation that is uncomfortable and useful in equal measure.

Without it, relevance filtering happens by exhaustion. Analysts skim, the volume defeats them, and the default becomes ignoring everything — including the occasional item that mattered.

The economics of blocking somebody else’s indicator

There is a persistent hope that a feed can be wired straight into an enforcement point and left there. Sometimes that works. Often it produces a slow accumulation of outages nobody attributes to the feed.

The reason is that the cost of a false positive is borne locally and the benefit of a true positive is speculative. An address that hosted a command and control panel in March may host a shared platform in June, and the shared platform may be running something your finance team depends on. The feed’s confidence assessment, if it has one, was formed at observation time and rarely carries an expiry that reflects how quickly infrastructure churns.

Three habits make automated blocking survivable. Treat every indicator as having a validity window rather than a permanent truth value, and expire aggressively. Separate indicator types by their natural lifetime — a hash is stable, an address is a lease. And keep a fast, well-known path for reversing a block, because the question is not whether you will block something important but how long it takes to notice and undo.

Corroboration that is only an echo

A subtler failure: several feeds agreeing looks like corroboration and often is not. Aggregators ingest each other. An observable published once can appear in four products with four confidence scores, all descended from a single original sighting whose context has been stripped along the way.

The defence is provenance. An intelligence item worth acting on should be able to answer where it was observed, by what means, and when. Items that cannot are not necessarily wrong, but they should not have their weight multiplied by appearing repeatedly. In practice this means recording the source of every indicator you ingest and refusing to let count-of-sources stand in for confidence unless the sources are genuinely independent.

The feed you already own

The most relevant intelligence available to any organisation is generated by that organisation. What was seen hitting the edge last week. Which credentials appeared in a phishing attempt. What an incident three months ago revealed about how somebody approached you. Which of your suppliers has been probed.

Internal observation has properties no purchased feed can match: perfect targeting relevance, verifiable provenance, and no licence restrictions on how you use it. It also has the properties of raw material — it needs someone to process it, and it is boring compared to a report about a named group. Programmes routinely spend heavily on the second while leaving the first in a log bucket nobody reads.

What a working programme looks like

Requirements are written down and reviewed, in the form of questions the organisation needs answered rather than topics it finds interesting. Each requirement names a consumer — an actual role who will act on the answer. Collection is chosen to serve those requirements, internal sources first. Production is measured by what changed as a result: a rule written, a hunt run, a patch accelerated, a control funded, a decision documented as deliberately unchanged.

That last case matters. An intelligence function that reports “we assessed this campaign and concluded it does not warrant action here, for these reasons” has delivered value, and a programme that cannot record that outcome will drift toward manufacturing urgency to justify itself. The measure of an intelligence capability is not how much it knows. It is how much of what it knows reaches somebody who does something different afterwards.