---
{
  "title": "Threat intelligence",
  "summary": "Turn information about threats into a decision-relevant assessment.",
  "topic": "soc",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    4
  ],
  "aliases": [],
  "sources": [
    {
      "title": "MITRE ATT&CK: Get started",
      "url": "https://attack.mitre.org/resources/"
    },
    {
      "title": "NIST SP 800-150: Guide to Cyber Threat Information Sharing",
      "url": "https://csrc.nist.gov/pubs/sp/800/150/final"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## Information becomes useful through a decision

Threat intelligence is an assessed understanding of threats that helps a particular audience make a decision. It can address adversary behaviors, exposed technologies, likely attack paths, or relevant indicators. The defining feature is not the volume of data collected but the relationship between evidence, analysis, and an actionable question.

A feed of addresses and hashes is information. An assessment explaining which behaviors threaten an organization's important services, what confidence supports that view, and which defenses need attention is intelligence. Different audiences may need different products from the same underlying research.

## Focus on the environment

Imagine a fictional academy deciding how to protect staff access to cloud services. A widely reported campaign uses phishing pages and stolen sessions. The analyst examines the reported behavior, the services involved, and the academy's actual authentication, recovery, and session controls.

The resulting assessment should avoid claiming that the academy is targeted simply because it operates in education. Instead, it can explain why the behavior is relevant to its technology and workflows, what controls may reduce the opportunity, and which evidence would help detect attempted abuse.

[[indicators-of-compromise]] may support searches, but campaign infrastructure can change. Describing the behavior and required evidence can remain useful when a specific domain or file hash is no longer relevant.

## Preserve provenance and confidence

Trace important claims to their original sources where possible. Distinguish direct observations, credible reporting, analytical inference, and speculation. Several secondary reports copying one original claim do not provide independent confirmation.

State limitations clearly. An actor's observed use of a technique does not establish that the technique is exclusive to that actor. An absence of reporting about one platform may reflect limited visibility rather than safety. [[source-evaluation]] helps make those distinctions explicit.

Handling requirements also matter. Information shared under an agreement may have restrictions on redistribution or operational use. Preserve the applicable context when moving material into tickets or detection systems.

## Deliver a product someone can use

A technical assessment might recommend reviewing a particular application-grant path and identify the relevant audit events. A leadership brief might explain the business risk, responsible owner, dependencies, and priority. Both should connect the recommendation to the evidence rather than presenting generic security advice.

Ask for feedback after dissemination. Did the audience make a decision, identify a missing requirement, or need a different level of detail? [[intelligence-cycle]] uses that feedback to refine the next round of work.

For practice, write a short assessment about a fictional account-abuse trend using three attributable sources. Include one environment-specific implication, one recommended action, one uncertainty, and the evidence that would change your recommendation.

## Related concepts

- [[mitre-attack]]
- [[osint]]