Cyber Threat Intelligence: How to Build a Program Leaders Use

TL;DR: A cyber threat intelligence program that leaders use starts from their decisions, not from feeds. Write priority intelligence requirements (PIRs) that name the asset, the threat and the decision, then deliver each answer to a named reader in a format they use. Dissemination is where programs most often stall, in our reading. Measure requirements answered and decisions changed, not report volume, and let feedback from each consuming team reset priorities every cycle.

What is cyber threat intelligence?

Cyber threat intelligence is threat information that someone has analyzed for a named audience and a stated decision. A list of malicious IP addresses is not intelligence on its own. It becomes intelligence when an analyst has checked it against your environment, explained what it means, and handed it to the person who has to act.

Cyware's guide draws the same line. Unlike logs or alerts, it says, threat intelligence is "refined information that has been collected, processed, analyzed, and contextualized for specific audiences" (Cyware). Daniel Curtis, Manager of Finished Global Intelligence at ZeroFox, puts it more briefly: "Intelligence is information that has been processed to become useful for a given target audience" (ZeroFox).

Both definitions name the audience. We think the decision belongs in the definition too. In our reading, a report that names its reader but not the choice it informs tends to get filed and forgotten.

Why a feed is not a program

It is easy to buy a feed and call it a program. The raw material has known limits. Threat feeds "vary dramatically in quality, containing outdated indicators, false positives, or questionable information that requires expertise to validate" (Cyware).

Context is the second gap. Cyware notes that publicly available intelligence often lacks the context needed to judge whether it matters to your organization, so it takes substantial analysis to use (Cyware). Shelf life is the third. The same guide says intelligence "quickly becomes stale as adversaries adapt their tactics" (Cyware).

Adding another feed does not fix any of these problems. In our reading, analysts who know the business fix them, working from a clear request by the people who use the output.

Who it is for

Cyware describes four levels of intelligence, each with its own audience (Cyware). The decision column is ours, added to show what a stated decision looks like in practice.

The bottom row matters. Technical indicators are consumed by machines, so the reader is a tool and the decision is automated. Every row above it needs a person, a question and a deadline.

Use a quick test on anything your team labels intelligence: name the reader, name the decision, and name the date it stops being true. If any of the three is blank, you are looking at data. For related terms, see the CISO security glossary.

What are strategic, operational and tactical intelligence?

The three levels differ less by topic than by who acts on them and how soon. As the previous section set out, each level has its own reader, from the board down to the analyst. This section adds the time horizon, the typical output and the action that should follow.

One warning first: vendors do not label the levels the same way. Cyware treats tactical as the fast, machine-readable layer and operational as campaign analysis. Flashpoint reverses that. It describes operational intelligence as the layer that usually consists of indicators of compromise and machine-readable data, fed into firewalls and security tools. It places tactical intelligence in the middle, with a shorter lifespan than strategic but less reactionary than operational work. In our reading, the labels matter less than agreeing on them internally. Pick one scheme and write it into your program charter so a request for operational intelligence means one thing.

The table below uses the Cyware scheme.

What each level looks like in practice

Strategic intelligence looks out over long-term horizons (months to years). Its outputs support security budget planning and justification, third-party risk analysis, compliance readiness, scenario planning, and board-level risk reporting. Flashpoint notes it usually arrives as white papers, reports, and other briefings. For a security leader, this is the material that ends up in a board pack. Our guide to board committee oversight covers where it lands.

Operational intelligence covers weeks to months. It describes how adversaries behave, not just what they leave behind. Cyware says it helps teams develop tailored response playbooks and anticipate adversary behavior.

Tactical intelligence is often measured in hours or days. Typical uses include blocking malicious IPs, triaging during an incident, or writing detection rules. Its limit is context. Cyware observes that it rarely tells security teams where an attack is coming from or how it fits a wider campaign.

A quick test for any report that reaches your desk: name the reader and the action it should trigger. If neither is clear, the report is probably sitting at the wrong level.

How do you write intelligence requirements?

A requirement is a question the program owes someone an answer to. If no one can name the decision it serves, it is a topic, not a requirement.

Flashpoint's lifecycle puts this work first. The requirements stage is where a team must define what intelligence needs to answer and why, with priorities tied to business risk, assets and stakeholder needs. These questions are usually called priority intelligence requirements (PIRs). Whatever the label, the aim is clear, stakeholder-driven questions that the intelligence is expected to support.

Start from the decision, not the threat

The source says a good PIR reflects what the organization is trying to protect, the threats of greatest concern, and the decisions intelligence is meant to inform. In practice that gives a three-part test for every draft question:

• Asset: what is at stake, such as a payments platform, a product line or a group of executives.
• Threat: who or what worries you about that asset.
• Decision: what someone will do differently once they have the answer.

The chief information security officer (CISO) usually shapes this. Flashpoint describes senior leadership identifying critical assets, defining risk tolerance, and setting expectations for how intelligence supports decisions. A new CISO can fold this into the early stakeholder interviews in our first 90 days plan.

Worked examples

The lifecycle is framed as applying to fraud, physical security, and cybersecurity programs, so the same method works across audiences. The rows below are our own examples, not drawn from the source.

In our reading, the board question changes slowly and suits a quarterly briefing. The SOC and fraud questions need answers within days. For how boards receive this material, see our board committee oversight report.

Make requirements measurable and keep them current

Flashpoint notes the process often resembles building a business case. Clear requirements make it easier to establish meaningful key performance indicators (KPIs) and show value over time. A practical step: give each requirement an owner, a consumer and a review date.

Requirements are not fixed. The lifecycle closes with feedback, where teams refine requirements and adjust collection and analysis as threats and stakeholder input change. We think a short list that is reviewed often beats a long list that no one revisits.

How does the intelligence lifecycle work in practice?

The lifecycle is drawn as a circle, but in practice it works like a relay. Each stage hands something to the next, and one dropped handoff stops the whole loop. Flashpoint describes five stages that run from setting requirements through collection, analysis and delivery to decision-makers, and then back to refining priorities. The previous section covered requirements, so this one starts at collection.

Collection and processing

Collection is a problem of balance. Flashpoint puts it plainly: "Too little visibility creates blind spots; too much unfocused data overwhelms teams with noise and false positives" (Flashpoint). It also argues for collecting directly from original sources based on your own requirements, rather than relying on static, vendor-defined feeds.

Processing turns raw inputs into something an analyst can read. The source lists the work: inputs are normalized, structured, translated, deduplicated and enriched. A simple test: pick one requirement and ask which sources answer it. If the answer is the entire feed list, collection has not been scoped.

Analysis

Analysts assess relevance, likelihood and business significance to decide which threats, actors or exposures matter most. Artificial intelligence (AI) can speed up parts of this work, but the same source keeps judgment, context and prioritization with human analysts, especially for ambiguous threats. The output should be short: what needs attention first, and why.

Dissemination: where programs stall

Dissemination means delivering intelligence in formats that reach the right stakeholders at the right time, so that it informs operations, response and decisions, "not just reporting."

In our reading, this is the stage where programs most often stall. The analysis gets done and a report lands in a portal or a shared folder. The person who asked the question never sees an answer, or sees it after the decision was made. The team counts the report as delivered. The requester concludes intelligence is slow.

Flashpoint lists a planning question for the requirements stage: "Which downstream teams or systems will rely on these intelligence outputs?" (Flashpoint). We think it should be answered with named people before collection starts. Three habits help:

• Attach every finished product to the requirement it answers and the person who raised it.
• Match the format to the reader: a briefing for the board, a detection rule for the security operations center, a phone call to the incident lead.
• Close the request only when the requester confirms they received it and says whether it changed a decision.

Feedback

That confirmation is the raw material for the last stage, which loops back into requirements as described earlier. No delivery, no feedback. A program that never hears from its requesters ends up refining questions nobody is asking.

Who uses intelligence, and in what format?

Earlier sections set out the levels of intelligence and who sits at each. This one covers the object each reader actually receives, and the one place where intelligence feeds a regulatory filing.

Three deliverables

• Directors: a quarterly risk brief. Flashpoint describes reports for executives and board members that focus on long-term risks, geopolitical trends and potential threat impacts. It says this work is usually delivered as white papers, reports and briefings that cover a set time period. In our reading, a quarter fits most committee calendars. Two pages is enough: which threats moved, what changed in exposure, and the decision the board is being asked to support. Our board oversight report shows how committees take in this kind of material.
• Incident responders: adversary profiles. Flashpoint lists heads of incident response among the readers of intelligence on how an actor operates, including motives, capabilities and likely next steps based on past behavior. We think one page per group works: how it gets in, what it takes, how it applies pressure, and what it did when earlier victims refused to pay.
• Detection engineers: indicator lists. This is machine-readable data such as URLs, domain names and IP addresses, consumed through firewalls, SIEMs and security orchestration, automation and response (SOAR) tools. Ship it as a feed, not a PDF. Give each indicator a source, a first-seen date and an expiry date so stale entries age out.

Where intelligence meets materiality

Take an extortion incident. A ransom note arrives on day one of the response. That same day, the intelligence lead pulls the actor's profile and hands the disclosure team a dated, one-page assessment: which group is likely behind it, with a confidence level; what it has done with stolen data before; and which of its claims have been verified so far.

On the days that follow, the team watches leak sites. Flashpoint notes that intelligence can tell teams where certain threats have been observed online. If a posting appears, the assessment is reissued with a new date and a note on what changed.

The materiality call belongs to the company's disclosure process, not to the intelligence team. Intelligence is one input to it. The materiality glossary entry explains the term. Our Item 1.05 decision guide covers what the Securities and Exchange Commission (SEC) rule says about when the filing clock starts and how long it runs. Readers can check their own timeline against it.

In our reading, the timestamps matter as much as the content. A series of dated assessments gives the disclosure team a record of what was known and when. That record helps when facts shift after a determination has been made.

Three things a security leader can check this week:

1. The disclosure committee has a named intelligence contact.
2. Every incident assessment carries a date and a confidence level.
3. Indicator feeds expire entries on a set schedule.

Should you buy or build threat intelligence?

In our reading, most programs end up with a mix of sources. In our reading, the useful question is which source answers each requirement at the lowest total cost, rather than buy versus build.

The table below is our reading. Get your own quotes and salary benchmarks before you decide.

A worked example: three requirements, cheapest source first

1. Which ransomware groups are targeting payments firms this quarter? In our reading, a sector ISAC usually answers this for the cost of membership.
2. Are our employee credentials or customer data offered for sale? A managed service or a monitoring feed can answer this. In our reading, building that collection yourself costs more.
3. Which supplier compromise would halt settlement, and how exposed is each supplier? No outside source knows your supplier map, so this one needs an internal analyst.

The leftover work is the third requirement, plus the job of turning the first two into choices for leaders. That residue is the case for at least one in-house analyst, even in a program that buys most of its collection.

Checking the mix

Map each source you pay for to one of those decisions. If a feed or service feeds none of them, it is a candidate to cut at renewal.

For how other leaders report program spend upward, see our reports.

How do you show the program is working?

In our reading, volume is the easiest thing to count and the least useful. Report counts, feeds ingested and indicators pushed describe activity. In our reading, a board member or a head of operations can tell activity from value, and a program that reports only volume invites the question of what it changed.

Flashpoint describes the lifecycle as working "Rather than focusing on tools or outputs alone." Measurement should follow the same logic. Start from the written requirements and record what happened because of them.

Measures tied to requirements

In our reading, the decision log does the most work with leaders.

One of Flashpoint's planning prompts gives a second test: "How should intelligence improve efficiency, prioritization, or response across teams?" Whatever answer a team wrote down at the requirements stage becomes the thing to measure later.

Letting feedback reset priorities

The earlier section on the lifecycle covered the feedback stage. In practice, it runs as a short review with each consuming team at the end of every cycle. Three prompts are usually enough:

• Which outputs the team used, and for what.
• Which outputs it ignored, and why.
• Which question it needed answered and did not get.

The answers drive three changes. Retire PIRs that are answered or no longer relevant. Add the missing questions as new requirements. Shift collection and analyst time toward whatever produced decisions and detections. A requirement that has produced no decisions for two cycles is a candidate for removal. It may also be a sign that its owner needs a different format.

Keep the review honest by recording the ignored outputs as carefully as the successes. Over a year, that record shows which audiences the program serves well and which it does not. That is the evidence a chief information security officer (CISO) needs when reporting to a board committee. For how that reporting is typically structured, see /reports/board-committee-oversight and /guides/ciso-reporting-structure.

What this guide does not cover

This guide does not rank or recommend vendors, and it quotes no prices or salaries, so readers should get their own quotes and salary benchmarks before deciding. It points to a separate guide for what the Securities and Exchange Commission (SEC) Item 1.05 rule says, and materiality calls belong to the company's disclosure process. Nothing here is legal or financial advice. For the rules and the record behind it, see CISO Reporting Structure, the Five Models and What the Filings Show.