"Intel-driven" is the most-claimed and least-practiced phrase in security. Almost every SOC deck I have reviewed says it. Almost none of them operate that way. What they actually operate is alert-driven — the tool vendors decided what is interesting, the SIEM rule pack ships with 4,000 default detections, and analysts triage whatever comes up. Intel, if it exists, lives in a Confluence page nobody reads.

Here is what changes when intel actually drives the program.

Priority Intelligence Requirements (PIRs)

Borrowed from military intelligence doctrine, PIRs are the short list of questions your program is trying to answer. Good PIRs are specific enough to be answerable and general enough to last a quarter. Bad PIRs look like "what are the latest threats?" Good PIRs look like:

  • Which ransomware affiliates target mid-market US law firms and what are their initial-access TTPs this quarter?
  • Are our edge appliances (Citrix NetScaler, Fortinet FortiGate, Ivanti Connect Secure) subject to active exploitation chains?
  • Which of our third-party SaaS vendors have had credential exposure or OAuth-token compromise incidents in the last 90 days?
  • What commodity infostealers are most prevalent on consumer machines that authenticate to our SSO?

Every intel artifact your team produces or consumes should tie back to a PIR. If it doesn't, it is either a new PIR or noise.

Detection Engineering From Intel

The concrete test of intel-driven is: does new operational intel produce new detections within a defined SLA? When Mandiant or Unit 42 publishes a report on, say, Scattered Spider's latest social-engineering-to-MFA-fatigue-to-Okta-session-hijack chain, the clock starts. Within 72 hours, your detection engineer should have (a) mapped the TTPs to ATT&CK, (b) checked existing detection coverage for each technique, (c) written or tuned detections for the gaps, and (d) filed a test case in your purple team backlog.

This is the Red Canary / SpecterOps model. Intel in, detections out, measured and tracked. If your "intel team" produces PDFs and your detection team writes rules from scratch off SIEM alerts, those are two disconnected functions regardless of what the org chart says.

Briefing Cadence

A workable cadence for a mid-sized program:

Daily (async, 5 min read): Intel analyst posts a short Slack summary — new CISA KEV, any open PIR hits overnight, anything the on-call SOC needs to know.

Weekly (30 min): SOC + detection engineering + intel review. What detections shipped, what PIRs moved, what is backlogged.

Monthly (60 min): CISO-level intel brief. Threat-landscape shifts, PIR coverage, recommended posture changes.

Quarterly (strategic): PIR refresh. Retire stale PIRs, add new ones based on business changes, threat shifts, and incident learnings.

Measuring ROI

Intel programs die when they cannot defend their budget. Measurable outputs:

  • Time from public threat disclosure to detection deployment (target: 72 hours for priority groups).
  • Detection coverage against a named threat portfolio mapped in ATT&CK Navigator — track quarter over quarter.
  • Intel-sourced incidents — how many incidents were caught because of an intel-driven detection vs. a default rule? Tag them in your case management.
  • PIR answer rate — of your stated PIRs, how many have a current, defensible answer?
  • Purple team pass rate against threat-informed scenarios, not generic ones.

These are defensible to a CFO in a way that "indicator ingestion volume" never will be.

The Risks of Over-Intel-ing

You can over-rotate in the other direction. Three failure modes I have seen:

Actor obsession. The team spends weeks building APT28-specific detections because the CISO read an article, while the actual incident vector is a commodity phish with a Microsoft 365 OAuth-consent trick. Intel should inform priorities, not define them to the exclusion of base rates. Commodity threats cause most breaches.

Report-writing as a substitute for defending. Beautiful intel reports that nobody on the SOC side reads or acts on. If the detection engineer cannot name last week's top intel finding, your pipeline is broken.

Perishable overload. Ingesting every available IOC feed produces false positives, retention bloat, and alert fatigue. Quality and enrichment beat volume. The CrowdStrike and Mandiant practitioner consensus on this has been consistent for years.

A Minimum Viable Intel Function

If you are a one-person intel program (which is most mid-market security teams): write four PIRs, subscribe to CISA KEV and three operational blogs, set a weekly 30-minute ritual to translate findings into a single detection or control change, and track the backlog in a simple spreadsheet. That is an intel-driven program. Everything else is scaling, not substance.