Threat Hunting Program Models, From Solo to Enterprise

A one-person hunting “program” and a twelve-person global hunting operation aren’t the same discipline scaled up—they’re different jobs that happen to share a name. The mistake a lot of orgs make is trying to apply enterprise-program structure to a solo hunter, or worse, trying to run an enterprise-scale hunting mission with one person and a spreadsheet. Knowing which model actually fits your resourcing changes almost everything about how the work should be structured.

The Solo Hunter: Constrained, But Not Powerless

Plenty of hunting programs are exactly one person, usually part-time, squeezed between other SOC responsibilities. This model lives or dies on ruthless prioritization. A solo hunter can’t cover every ATT&CK technique, can’t run continuous hunts across every data source, and shouldn’t try. The move that actually works here is picking two or three hypotheses per month, tied to whatever’s highest risk for that specific org—a recent phishing campaign targeting the industry, a new CVE affecting internet-facing infrastructure—and running those deeply rather than spreading thin across everything.

Say a solo hunter has eight hours a week set aside for hunting. That’s not enough for a broad sweep, but it’s plenty for one well-scoped hypothesis: “did the recent credential-stuffing campaign targeting our sector result in any successful logins from unusual geographies.” Narrow, testable, finishable in the time available. The failure mode at this scale is almost always scope creep—starting broad, running out of time, and closing the quarter having “sort of” looked at five things instead of confirmed one.

Small Team Hunting: Where Specialization Starts

Once a program has two to four dedicated hunters, work usually starts splitting by data domain or threat category—one person leaning into identity and cloud, another focused on endpoint and network. This isn’t strict specialization yet; everyone still needs cross-domain fluency for hunts that span multiple data types. But it’s the first point where a rotation or ownership model makes sense, because a single person trying to stay expert across every log source in the environment starts hitting real limits around this team size.

This is also usually where hunt cadence formalizes—moving from ad hoc hunts whenever time allows to something closer to a scheduled rhythm, say two structured hunts per sprint with defined hypotheses documented in advance. The team’s small enough that coordination overhead stays low, but large enough that some process is worth the investment.

Mid-Size Programs: Tiering and the First Real Metrics Problem

Somewhere in the five-to-fifteen-hunter range, programs typically introduce tiering—junior hunters running well-scoped, playbook-adjacent hunts (closer to HMM2 maturity work), senior hunters generating novel hypotheses (HMM3 territory), and someone senior enough to own the feedback loop into detection engineering. This is also where measuring program value gets genuinely hard, and a lot of programs stumble here.

Counting “number of hunts run” as a success metric is tempting and mostly useless—it incentivizes running lots of shallow, quick hunts instead of fewer deep ones. A better mix of metrics tracks things like hunt-to-detection conversion rate (how many hunts produced a lasting detection rule), mean time to close a hunt, and—harder to quantify but worth trying—coverage against your ATT&CK matrix, showing which techniques have actually been hunted for versus assumed covered because a vendor rule exists somewhere.

Enterprise Programs: Global Coverage and the Coordination Tax

At true enterprise scale—global operations, follow-the-sun coverage, dozens of hunters across regions—the core challenge stops being “can we find things” and becomes “can we coordinate what we’ve already found without losing signal.” Duplicate hunts across regional teams, inconsistent hypothesis documentation between shifts, findings that get discovered twice because nobody checked whether the APAC team already ran this exact hunt last month.

This is where centralized hunt management tooling—a shared hypothesis backlog, standardized documentation templates, a single source of truth for what’s been tried and what came of it—stops being a nice-to-have and becomes the actual bottleneck if it’s missing. Enterprise programs that skip this coordination layer often end up with more raw hunting hours logged than mid-size programs, but less actual unique coverage to show for it, because so much effort gets duplicated across regions and shifts.

Picking the Right Model for Where You Actually Are

The temptation at every stage is to borrow structure from the next size up—a solo hunter trying to run a tiering model, a five-person team trying to build enterprise-grade tooling before they’ve proven out a basic hunt cadence. Resist it. Build the process that fits your actual headcount and data maturity right now, and let the structure grow with the team rather than imposing a structure the team isn’t big enough to fill yet.

Choose your model

Write down your available hunting hours per month, number of searchable data domains, number of analysts who can lead a hunt, and detection-engineering capacity. Choose the smallest model that can operate reliably within those limits. Define one measurable commitment for the next quarter, such as four completed hunts and one detection candidate—not an aspirational list of every technique you hope to cover.

Scale changes coordination, specialization, and measurement. It does not replace the core loop of hypothesis, evidence, validation, and defensive improvement.