You do not need a platform to start

Most threat intelligence programs die one of two deaths. Either the company buys an expensive TIP and a bundle of feeds before anyone knows what questions to answer, and the tool becomes an unread inbox. Or someone subscribes to twelve RSS feeds, forwards articles to a Slack channel, and calls it intelligence.

A working program is neither. It is a loop: requirements drive collection, collection feeds analysis, analysis gets disseminated to people who act on it, and their feedback refines the requirements. Every piece of that loop can be built with free tooling and a few hours a week. Here is the roadmap.


Step 1: Write down your intelligence requirements

Before touching a single feed, answer one question: what decisions should intelligence improve? The formal name is Priority Intelligence Requirements (PIRs), and for a small SOC five is plenty. Good PIRs are specific to your organization:

  1. Which vulnerabilities in our internet-facing stack are being actively exploited?
  2. Which threat actors and malware families target our sector and region?
  3. Are our domains, credentials, or brand being abused (phishing kits, lookalike domains, leaks)?
  4. What TTPs from relevant actors do our detections not cover?
  5. What changed this week that should alter our patching or hunting priorities?

Notice what these do: every one of them names a consumer (vuln management, detection engineering, IR, leadership) and implies an action. "Stay informed about cyber threats" is not a PIR; it is a horoscope subscription.

Write the PIRs down, get your SOC lead to sign off, and revisit them quarterly. They are the filter that saves you from drowning in step 2.


Step 2: Collection, the free tier

There is more free, high-quality intelligence available today than any small team can consume. The problem is selection, not access. A solid starter kit:

Source What it gives you Maps to PIR
CISA KEV catalog Vulnerabilities confirmed exploited in the wild 1
vuln.mlab.sh CVE search with CVSS, EPSS and KEV in one view 1
abuse.ch (URLhaus, MalwareBazaar, ThreatFox, Feodo Tracker) Malware URLs, samples, IOCs, botnet C2s 2, 3
actors.mlab.sh 500+ actor profiles: aliases, TTPs, linked CVEs 2, 4
Vendor research blogs (Microsoft, Cisco Talos, Mandiant, ESET, Unit 42...) Campaign reporting with IOCs and TTPs 2, 4
news.mlab.sh Curated security news, one stop instead of forty tabs 5
Certificate transparency monitoring Lookalike domains targeting your brand 3
Your sector ISAC or national CERT list Sector-specific warnings, often early 2, 5
Your own incident and alert data The most relevant intel you will ever own all

That last row is the one teams skip. Your closed incidents, blocked phishing domains, and recurring alert patterns are ground-truth intelligence about who actually targets you. Treat them as a first-class source from day one.

Resist feed maximalism. Ten sources you triage beat fifty you ingest. Every source must justify itself against a PIR; if it cannot, unsubscribe.


Step 3: A triage workflow that fits in 30 minutes a day

Collection without processing is hoarding. The daily routine for a one-person intel function:

  1. Sweep (10 min). Scan your curated news and feed digest. For each item, ask the only question that matters: does this touch a PIR? No: skip without guilt. Yes: continue.
  2. Extract (10 min). Pull the actionable content: IOCs, exploited CVEs, TTPs. Paste report text into the free IOC extractor on mlab.sh to get defanged indicators out in seconds, then enrich the ones that matter to decide whether they are alert-worthy or hunt-worthy.
  3. Route (10 min). Send each item to its consumer with a recommended action. Exploited CVE in your stack goes to patching with a deadline suggestion. New TTP goes to detection engineering as a hunt hypothesis. Lookalike domain goes to IR for takedown.

Keep a lightweight log of what you processed and where it went; a shared spreadsheet or ticket queue is fine. You will need it for step 5 and 6, and it is your evidence that the program exists.


Step 4: Dissemination that people actually read

Intelligence that is not consumed does not exist. Match the format to the audience:

  • SOC analysts: enriched IOCs pushed into the SIEM watchlist or blocklist, with source and expiry. Never raw feed dumps.
  • Detection engineers: a short hunt hypothesis. "Actor X abuses scheduled tasks named like GoogleUpdate; do we detect that?" is a deliverable.
  • Vulnerability management: a same-day ping when a CVE in your stack hits KEV or spikes in EPSS.
  • Leadership: a weekly five-bullet summary. What happened, whether it affects us, what we did. No IOCs, no jargon, one screen.

The discipline: every dissemination names a recipient and a suggested action. A forwarded link with "FYI" is noise wearing a badge.


Step 5: Close the loop

The feedback loop separates a program from a newsletter. Once a month, ask your consumers three questions:

  1. Did anything we sent change what you did?
  2. What did you need that we did not provide?
  3. What did we send that you ignored, and why?

The answers rewrite your PIRs and prune your sources. When detection engineering says actor TTP notes are gold but daily IOC pushes are noise, you have learned where to spend your thirty minutes. Programs that skip this step calcify into ritual within six months.


Step 6: Metrics that prove value (and ones that do not)

You will eventually be asked to justify the time spent. Measure outcomes, not volume:

Worth tracking:

  • Intel-driven actions: patches prioritized, hunts launched, detections created or tuned from intel
  • Detection outcomes: true-positive alerts from intel-sourced indicators vs false positives they caused
  • Time-to-awareness: lag between public disclosure of a relevant threat and your team knowing about it
  • Coverage: how many PIRs received at least one actionable deliverable this month

Vanity, ignore:

  • Number of IOCs ingested
  • Number of feeds subscribed
  • Number of reports read

One good story ("we patched the VPN gateway two days before mass exploitation because KEV flagged it") buys more budget than a million ingested indicators.


Failure modes to dodge

Four traps account for most dead CTI programs; know them before you meet them.

The collector. Someone builds an impressive ingestion pipeline and never gets to analysis. Feeds pile into a database nobody queries. If step 2 consumes more of your week than step 3 and 4 combined, the ratio is inverted.

The pundit. The intel function becomes a commentary desk: articulate summaries of global events, zero connection to local decisions. The PIR filter exists precisely to kill this; apply it without mercy, including to interesting stories.

The blocklist cannon. Every ingested IOC gets pushed straight to blocking with no confidence check, no expiry, no enrichment. Three weeks later a stale CDN IP takes down access to a legitimate service, and the program's credibility goes with it. Indicators earn blocking status; they do not arrive with it.

The silent partner. Intel flows out, nothing flows back, and after a quarter the deliverables no longer match what consumers need. If you skip the monthly feedback questions, this failure is not a risk; it is a schedule.


The 90-day plan

  • Weeks 1-2: write and validate five PIRs with your SOC lead.
  • Weeks 3-4: wire up the free source kit, kill anything that does not map to a PIR.
  • Weeks 5-8: run the daily 30-minute triage, log every routed item.
  • Weeks 9-12: first feedback round, first metrics summary, adjust PIRs and sources.

By day 90 you have a functioning intelligence cycle, a paper trail of value delivered, and, if you later decide you need a TIP or paid feeds, you will finally know exactly what to buy and why. Most teams discover they need less than they thought.


Threat intelligence is a process wearing a fancy name. Start the loop small, keep it honest, and let the results argue for the budget.