Threat Feeds vs Finished Intelligence: When to Buy Data and When Analysis

Many security teams pay for threat intelligence and get a firehose of indicators that decay within days, while the questions their leaders actually ask, "are we a target, and what should we change?", go unanswered. A threat feed is data: machine-readable indicators such as IP addresses, domains, URLs and file hashes, delivered continuously for automated blocking and matching. Finished intelligence is analysis: a written assessment that has been collected, evaluated, put in context and given a judgement with stated confidence, written for a decision maker. This guide compares the two on shelf life, false positives, the real cost of consuming them and the decisions each supports, and helps you decide what to fund and how to wire both into operations. It is for threat intelligence leads, SOC managers and security leaders setting a CTI budget. It does not repeat feed scoring methods or report writing craft: for those, see the Threat Intelligence Feed Evaluation Guide and Writing Threat Intelligence Reports.

Key takeaways

• Feeds answer "is this thing bad?"; finished intelligence answers "what does this mean for us?" They support different decisions and are consumed by different people and systems.
• Shelf life is the core difference. Hashes and IP addresses lose value quickly because adversaries change them cheaply; assessments of adversary behaviour, intent and targeting stay useful for months.
• Feed cost is mostly consumption cost. The licence is often the smaller part; the larger part is triage of false positives, tuning, expiry and engineering to keep the data clean.
• Finished intelligence is only as good as its requirements. Generic reports that are not tied to your intelligence requirements are expensive reading material, not decision support.
• Mature programmes connect the two. Indicators in a feed should trace back to an assessment, and every assessment should end in actions: detections, hunts, control changes or risk decisions.

Short answer

Buy or subscribe to feeds when you have systems that can act on indicators automatically (SIEM, EDR, firewall, secure email gateway, DNS filtering) and staff to manage expiry and false positives. Buy or produce finished intelligence when people need to make decisions: which threats to prioritise, which controls to fund, how to respond to a campaign against your sector, what to tell the board. Small teams without a platform for managing indicators usually get more value from good finished intelligence plus a few curated, free feeds than from a large commercial feed. Large SOCs need both, joined by a threat intelligence platform that keeps indicators linked to the context that explains them.

Side-by-side comparison

Threat feeds in depth

Threat model they address: commodity and campaign infrastructure that is reused across many victims: phishing domains, malware download URLs, command and control addresses, known malicious file hashes. Feeds help when an adversary reuses infrastructure against you that someone else has already seen.

Architecture in words: the provider collects observations from sensors, honeypots, sandboxes, incident response work or member submissions, normalises them and publishes them. You pull them, usually over a TAXII 2.1 collection or an API, into a threat intelligence platform or directly into a SIEM. From there indicators are matched against logs (retrospective and live), pushed to blocking controls, or used to enrich alerts. Government schemes follow the same pattern: CISA's Automated Indicator Sharing exchanges machine-readable indicators and defensive measures at no cost to participants and expects a STIX and TAXII capability.

How feeds fail:

• Decay: David Bianco's Pyramid of Pain places hash values and IP addresses at the bottom because adversaries can change them trivially. An address that hosted command and control last week may now belong to a legitimate tenant of the same cloud provider. See the Pyramid of Pain Guide.
• Shared infrastructure: content delivery networks, cloud hosting ranges, URL shorteners and popular file-sharing services appear in feeds and produce false positives when blocked wholesale.
• No context: an indicator without a threat name, kill chain stage or confidence cannot be prioritised; a SOC treats a phishing domain and a ransomware staging server the same.
• Volume over relevance: millions of indicators, most of which never appear in your telemetry, inflate storage and matching cost.

Controls that make feeds work: ageing and expiry on every indicator (STIX 2.1 Indicator objects carry a valid_from and optional valid_until; MISP's decaying model lowers a score over a configured lifetime and resets it when a new sighting arrives); allow-lists for shared infrastructure; confidence thresholds per action (block only above a high threshold, alert or enrich below it); and recording sightings so you know which indicators actually fire.

Finished intelligence in depth

Threat model it addresses: adversaries who adapt. A finished assessment describes who is targeting your sector, how they operate (techniques, tools, targeting choices, timing), what has changed, and what that means for your controls. It aims higher on the Pyramid of Pain, at tools and tactics, techniques and procedures, where change is costly for the adversary.

Architecture in words: analysts start from intelligence requirements set by stakeholders, collect from many sources (including feeds, incident data, vendor research, government advisories and community sharing), evaluate source reliability, analyse, and write a product with key judgements first. The US intelligence community's analytic standards in ICD 203 are a useful bar: describe source quality, express uncertainty with likelihood and confidence, separate information from assumptions and judgements, consider alternatives, show customer relevance and explain changes from earlier judgements.

How finished intelligence fails:

• Not tied to requirements: a monthly global threat roundup that never mentions your sector, estate or crown jewels.
• Hedged into uselessness: judgements with no likelihood term or confidence, so no one can act on them.
• No action path: a well-written report that produces no detection, hunt, control change or risk decision.
• Stale by delivery: long production cycles mean the campaign has moved on by the time the report reaches its reader.

Controls that make it work: written intelligence requirements reviewed at least yearly; a consistent likelihood scale (ICD 203 maps terms such as "likely" to 55 to 80 percent and "very likely" to 80 to 95 percent); a release workflow with peer review; TLP 2.0 markings so recipients know what they may share; and a standing link from every product to the actions taken.

Shelf life and indicator decay

The single biggest practical difference is how long each product stays useful. Use the indicator type to set default lifetimes, then let sightings extend them.

The shelf life column is a planning default, not a measured constant: tune it from your own sighting data. Keep expired indicators for retrospective hunting, because a hash that is too old to block can still show that you were compromised months ago.

False positives and the real consumption cost

The price on a feed contract understates its cost. Count these before buying:

1. Ingestion and normalisation: parsing formats, deduplicating across feeds and mapping to your platform's schema.
2. Matching cost: SIEM licensing and compute for matching millions of indicators against logs, often priced by data volume or search load.
3. Triage time: each false positive alert costs analyst minutes. A feed that adds many alerts a day with a low true positive rate can cost more in staff time than its licence.
4. Tuning and allow-listing: engineering time to suppress known-good infrastructure and maintain expiry rules.
5. Business impact of bad blocks: blocking a shared cloud address or a popular service interrupts users and erodes trust in the SOC.

Finished intelligence has a different cost profile: subscription or analyst salaries, plus the time of the people who read it. Its waste is invisible: reports nobody reads. Measure both with the same question: what decision or action did this produce, and at what cost?

Decision support: what each lets you decide

Choosing: decision criteria

• Automation maturity: if you cannot expire, score and suppress indicators automatically, a large feed will hurt more than it helps. Start with a few curated sources.
• Analyst capacity: with no dedicated CTI analyst, buy finished intelligence that is already tailored, or use free government and sector products, and keep feeds small.
• Sector and threat profile: sectors with frequent targeted campaigns gain most from sector-specific finished intelligence and the indicators attached to it; organisations mostly facing commodity threats gain more from curated feeds into mail and DNS controls.
• Sharing community: an ISAC or ISAO membership often supplies both: member-submitted indicators and analyst products relevant to the sector.
• Platform: a threat intelligence platform is what lets you keep the link between an indicator and the assessment behind it. See the MISP Threat Sharing Guide and the OpenCTI Guide.
• Small vs large: a small organisation can rely on its managed security provider's matching and on government advisories; a large SOC should own requirements, a platform and at least one analyst producing tailored finished intelligence.

Worked scenario: one budget line, two options

A regional bank with a 10-person SOC and one CTI analyst has budget for one paid product. Option A is a commercial indicator feed of several million indicators a day. Option B is a sector-focused finished intelligence subscription with weekly assessments, campaign reports and attached STIX indicators.

• Pilot: both are trialled for 30 days. Option A's indicators are matched against 90 days of DNS, proxy and EDR logs. Most never appear; of those that fire, a large share are shared cloud and content delivery addresses. Option B's two campaign reports describe an actor using help desk social engineering and abuse of remote management tools against regional banks.
• Actions: Option B leads to three new detections, a help desk verification change and a hunt that finds one unapproved remote management agent. Option A produces alerts but no confirmed true positive.
• Decision: the bank buys Option B, keeps free government and ISAC feeds for automated blocking with short expiry, and revisits a commercial feed when it has a platform with automated decay.

The figures will differ for every organisation, which is why the pilot matters more than the brochure.

Where identity fits

Identity is where finished intelligence often adds most value over feeds. Indicators rarely capture identity abuse: a valid login from a residential proxy, a consent grant to a malicious OAuth application or a stolen session token does not match a hash or IP list reliably. Finished intelligence that describes how actors abuse help desks, OAuth consent, service account keys or MFA fatigue gives you detections and control changes that no feed can. See Threat Intelligence for Identity and NHI Guide. Treat feed API keys and TAXII credentials as non-human identities too: scope them read-only, store them in a secrets manager and rotate them.

Implementation roadmap

1. Write intelligence requirements: five to ten questions from stakeholders, each with an owner and the decision it supports.
2. Map sources to requirements: mark which requirements need data (feeds) and which need analysis (finished intelligence).
3. Pilot feeds in observe mode: match against historical logs and alert only, no blocking, for 30 days; record hits and false positives.
4. Set handling rules: default lifetime per indicator type, confidence thresholds per action, allow-lists for shared infrastructure.
5. Promote to blocking gradually: start with high-confidence domains at DNS, then mail; keep a one-click rollback and an owner for each blocking rule.
6. Connect finished products to actions: each assessment ends with recommended detections, hunts or control changes, tracked to completion.
7. Review quarterly: drop sources that produced no actions; revise requirements.

Detection and measurement

• Feed hit rate: share of a feed's indicators that matched your telemetry in the period.
• True positive rate of feed alerts: confirmed malicious matches divided by all matches, per feed.
• Unique contribution: matches from a feed not present in any other source.
• Stale indicator share: active indicators older than their default lifetime with no new sighting.
• Actions per finished product: detections, hunts, control changes or risk decisions traced to each assessment.
• Requirement coverage: intelligence requirements answered in the last quarter.

Common failure patterns

• Blocking every feed indicator: shared infrastructure blocked, users interrupted, SOC credibility lost.
• No expiry: indicator stores grow forever and alert on addresses that changed hands long ago.
• Buying reports without requirements: analysts read generic reports that never change a control.
• Counting indicators as value: volume metrics reward the noisiest feed.
• Stripping context on ingestion: indicators loaded without the report that explains them cannot be prioritised.
• Ignoring sharing terms: re-sharing TLP:AMBER or licensed content outside its permitted audience breaks trust and contracts.

Framework mapping

Practitioner checklist

• Write intelligence requirements before buying any feed or report.
• Pilot every feed against historical logs in alert-only mode before blocking.
• Set default lifetimes per indicator type and let sightings extend them.
• Allow-list shared hosting, content delivery and popular service ranges before blocking.
• Keep indicators linked to the report or campaign that explains them.
• Require likelihood and confidence language in every finished product.
• Track actions taken from each finished product and drop sources that produce none.
• Respect TLP 2.0 markings and licence terms when sharing onward.
• Store feed and TAXII credentials in a secrets manager and rotate them.

Standards and references

• NIST: SP 800-150 Guide to Cyber Threat Information Sharing
• ODNI: Intelligence Community Directive 203, Analytic Standards
• OASIS: STIX Version 2.1
• FIRST: Traffic Light Protocol (TLP) 2.0
• CISA: Automated Indicator Sharing
• MITRE ATT&CK: Threat Intelligence Program
• MISP Project: Decaying of Indicators
• David Bianco: The Pyramid of Pain

Related NHI Mgmt Group resources: Threat Intelligence Guide, Threat Intelligence Feed Evaluation Guide, Writing Threat Intelligence Reports, STIX and TAXII Guide, Indicators of Compromise vs Indicators of Attack Guide.