A small team should spend its first 90 days on questions, not feeds. Month one defines what decisions intelligence will inform. Month two connects two or three sources to those decisions. Month three routes findings to owners and measures whether anything changed. Skip the platform until the routine works.
Month one: what decisions will intelligence change?
NIST SP 800-150 defines cyber threat information as anything that helps an organization identify, assess, monitor and respond to threats, including indicators of compromise and the tactics, techniques and procedures of attackers. That is broad. Narrow it.
Write three to five intelligence requirements as plain questions your team must answer:
- Which vulnerabilities in our software are being exploited right now?
- Which attacker techniques are used against companies like ours?
- Is anything of ours, such as credentials or domains, being discussed or sold?
Pair each with a decision it supports. "Exploited now" decides patch order. "Techniques" decides which detections to test. If a question changes no decision, drop it.
Also list your own assets: software, vendors, cloud accounts, domains. Intelligence is only useful against something you own.
Month two: which sources are worth connecting?
Choose two or three, free ones first.
- Exploited vulnerability list. CISA's Known Exploited Vulnerabilities catalog is described by CISA as the authoritative source of vulnerabilities exploited in the wild, and it says organizations should use it as an input to prioritization. It is published in CSV and JSON.
- Exploit likelihood scores. EPSS, maintained by a special interest group at FIRST, publishes scores freely. Use it to order what the exploited list does not cover.
- Technique knowledge. MITRE ATT&CK is a free knowledge base of adversary tactics and techniques from real observations. Use it as a shared vocabulary when you discuss detections.
- Vendor and sector feeds. Add a sharing community in your industry if one exists. SP 800-150 covers how to set goals, scope sharing and agree rules for distribution.
Resist more than three. Each source costs triage time.
Month three: how do findings reach the people who act?
Intelligence that stays in a spreadsheet changes nothing. Build a weekly rhythm:
- Pull new entries from the sources.
- Match them against your asset list.
- Send matches to the owning team with a due date and a plain explanation.
- Record what they did.
Use a short note format: what happened, why it matters to us, what to do, by when. Label how widely it can be shared, for example internal only. The Traffic Light Protocol is a common convention for that, though check FIRST's current definitions before you adopt it.
How do you know it works?
Pick three measures:
| Measure | What it tells you |
|---|---|
| Time from a listed exploited flaw to an owner assigned | Speed of the loop |
| Share of intelligence items that led to an action | Relevance of sources |
| Items closed without action, with reason | Where to prune |
Avoid counting feeds or indicators ingested. Volume is not value.
What should you leave out of the first 90 days?
Skip dark web monitoring, custom attacker profiles and a full platform. They answer questions you have not yet asked, and each adds triage work a small team cannot absorb. Also skip chasing every new report from vendors. If something truly matters to you, it will show up in the exploited vulnerability list or in your sector sharing channel. Write the leftover ideas in a parking list and revisit them at day 90, when you know what your routine can carry.
Where Safeguard fits
For the software side of your questions, Safeguard's reachability analysis helps show whether a listed vulnerable component is actually called by your code, so exploited vulnerability entries become a short, prioritized list. Its zero day discovery and policies at build and release add automated checks. Safeguard is not a threat intelligence platform and does not replace sources or analysts.
What to do
- Write three to five intelligence requirements and the decision each supports.
- Build an asset list covering software, vendors, domains and cloud accounts.
- Connect the exploited vulnerability catalog and one scoring source.
- Set a weekly review with a named owner for each team.
- Use a fixed note format with sharing labels.
- At day 90, prune sources that produced no action.
Quick check
Do we need a threat intelligence platform on day one?
No. A small team can run a useful weekly routine from public sources and a shared asset list. Consider a platform once the routine works and volume outgrows manual handling.
What is the most useful free source for patch priority?
CISA's Known Exploited Vulnerabilities catalog is a strong starting input, since CISA recommends using it in vulnerability prioritization. Combine it with your own asset list.
Sources
- NIST SP 800-150, Guide to Cyber Threat Information Sharing
- CISA Known Exploited Vulnerabilities Catalog
- FIRST, Exploit Prediction Scoring System
- MITRE ATT&CK
Last reviewed: 18 October 2026.
