Building a Threat Hunting Program: From First Hypothesis to Repeatable Practice

A repeatable threat hunting program depends on a falsifiable hypothesis, the telemetry to test it, and protected time to run it. Most programs stall for a structural reason: one of the three is missing, and no amount of hunter talent closes that gap on its own.

Security teams search for this because ad hoc hunting rarely survives contact with the alert queue. A program that depends on whoever has spare time after triage produces inconsistent results and little documentation, and leadership eventually asks why the hunting budget isn't showing up in detection coverage.

This guide walks through writing a testable hypothesis, fixing the telemetry gaps that undermine hunt results, converting findings into permanent detections, and choosing the right delivery model, whether that's in-house, bundled with Managed Detection and Response (MDR), dedicated managed hunting, or agentic execution.

TL;DR:

• A hunt starts with a falsifiable hypothesis and a named data source. "Data exfiltration" is a topic; Domain Name System (DNS) tunneling out of the finance department is a hunt.
• Telemetry and retention gate everything else. Data overtook staffing as the top barrier in 2026, and a clean hunt against missing logs cannot establish that the behavior is absent, only that it was not seen in the data available.
• Hunt counts measure activity; incident counts measure discoveries. Neither alone establishes coverage, which is why the PEAK framework (Prepare, Execute, Act, Knowledge) also tracks gaps closed and detections shipped.
• Separating hypothesis authorship from execution can add capacity: experts retain judgment while agents search and correlate months of logs, so one expert-defined hypothesis can run across data sources in parallel.

Write the Hypothesis Before You Pick the Data

A hypothesis has to be falsifiable, which rules out most first drafts. Splunk's PEAK guidance illustrates the fix: it treats "data exfiltration" as a topic, then makes it testable by specifying DNS tunneling as the mechanism, arriving at "A threat actor may be exfiltrating sensitive financial data using DNS tunneling." The refined form works because it names both the exfiltration type and the data type.

Scoping comes before equipping. Dan Gunter's SANS model for threat hunting makes this ordering explicit: purpose and scope come first, so the hypothesis and the data sources it needs get defined together, before whatever data is already on hand gets a chance to steer the hunt.

Use a Template That Forces the Evidence Question

PEAK's ABLE structure (Actor, Behavior, Location, Evidence) forces the evidence question by making the last field name a data source before you commit to the hunt. Actor is optional, but Behavior should name one or two specific techniques, phrased narrowly enough to query directly.

HEARTH entry H060 shows what a finished ABLE record looks like in practice. It documents netsh.exe or PowerShell abuse of Windows Firewall rules, catalogued under MITRE's Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) framework as T1686.003, the Windows Host Firewall sub-technique that replaced the retired T1562.004. The entry also records the event sources and limitations a hunter would need to know before running it.

A pre-check layer, applied before committing to any hypothesis, catches gaps early: do we collect this telemetry, is it retained long enough, and can a query actually validate the assumption. Any "no" answer sends the hypothesis back for refinement before it reaches the backlog.

Bound It in Time and Scope

Set a maximum effort and a lookback window before the first query runs, so the hunt ends on a fixed schedule. Splunk's cryptominer example caps this at three days of hunting against a normal data window of at least 30 days, a ratio that keeps the investigation proportional to the data behind it.

Scope has to account for business risk as well as technical feasibility. A hunt chasing a technique or actor profile with no plausible path to your environment wastes the window regardless of how well it is built, so the relevance check belongs at the start of scoping, before any queries get written.

Fix Telemetry Before You Add Analysis Techniques

Telemetry maturity caps analysis maturity. The U.S. Cybersecurity and Infrastructure Security Agency's logging reference architecture frames the underlying infrastructure question: which sources to collect, where to centralize them, and how long to retain them. SANS's 2026 survey reports that data outranked staffing as the top hunting barrier for the first time, 50% to 45%.

David Bianco's Hunting Maturity Model explains why that ordering matters, since it ties what a team can analyze directly to what it has already collected. HMM1 organizations collect a few data types; HMM2 organizations collect large amounts and, in the Sqrrl whitepaper's description, run procedures developed by others; HMM3 organizations create their own procedures; and HMM4 organizations automate them into detection.

Telemetry and analytic capability tend to improve together, but telemetry is still the gate. Expand collection toward HMM2 first, since no amount of analytic skill produces a trustworthy result against data that was never collected.

Teams can trust a negative result only when they collected the required data to produce it. SC World's guide calls the coverage-gap findings that come out of telemetry mapping "the most underused outcome in hunt programs," and the fix is procedural: route those gaps to the team that owns logging or endpoint visibility, with an owner and a ticket attached.

This problem shows up clearest with Local Security Authority Subsystem Service (LSASS) access. Without Sysmon event ID 10, or an equivalent endpoint detection and response (EDR) source, a clean result there says nothing about whether the behavior was actually absent.

Retention sets the other limit on what a negative result can prove. A hunt that reaches back weeks or months needs telemetry that is both retained and actually queryable for that whole period, which varies by product, table, and tier. Cloud environments make this harder still: according to the SANS 2026 Threat Hunting Survey, 32% of respondents identified cloud infrastructure as the hardest environment for threat hunting, more than any other environment.

Close the Loop From Hunt to Detection

The test of a program is what happens the week after the hunt. Splunk's PEAK conversion guidance says finding detection ideas "isn't that useful unless you take the next logical step: turn your hunts into production detections so you don't have to spend the time and energy hunting them over and over again." A declining share of teams follow a formal methodology at all, per the SANS 2026 figures above, and a program without one has little structure pushing hunt insights toward that next step.

Decide What Each Finding Becomes

Not every finding should become an alert. PEAK's Hierarchy of Detection Outputs orders outputs by how much automation they offer, with reports at the bottom, and one hunt can produce outputs at several levels. In the cryptominer case, DNS analysis might make a good automated alert while central processing unit (CPU) usage analysis is only suggestive and belongs on an expert-reviewed dashboard.

A consistently threat-indicating, low-noise pattern is the clearest candidate for automation. A complex hunt that cannot reduce to a simple detection is better served by a documented, repeatable workflow than by a rule that will misfire.

Elastic's hunt-query guidance covers the mirror case: a high-value signal too noisy to alert on can still run as a scheduled hunt query, with the known noise documented in the query itself.

Whatever you promote, store it as code. Detection logic that lives in version control, with test cases and continuous integration and continuous deployment (CI/CD) validation, holds up better over time than a one-off dashboard nobody maintains.

Write It So the Next Hunter Can Rerun It

Document every hunt well enough that someone else could rerun it. Skipping this step has a real cost. As Sydney Marrone noted at the SANS AI Cybersecurity Summit 2026, teams struggle to reuse prior investigations and end up repeating setup work each time they rerun a hunt. A structured hunt file with hypothesis, queries, and results helps, even though query history and telemetry can leave some trail on their own.

HEARTH's PEAK template goes further by requiring a ticket number and link on every row of its findings table, whether the row records a detection idea or a data gap. Without that record, the next hunter may not be able to reconstruct what was tested and concluded.

Protect the Time and Count the Right Outputs

Triage usually consumes hunting time unless teams schedule it, since hunting squeezed into whatever downtime remains after incident response and alert triage tends not to happen at all. The practical answer is dedicated days or blocks of hours, reserved from the alert queue on a fixed schedule so they can't be absorbed by whatever is left over.

A small team can give the part-time hunter role to an incident responder or detection engineer with the right skills and protected capacity. The UK Home Office guide offers one workable option: rotating Security Operations Center (SOC) staff onto hunting for a month at a time on a fixed schedule.

Alongside declining use of formal methodologies, fewer teams measure hunt outcomes: 40% of

SANS 2026 respondents do so, down from 51% in 2025 and 64% in 2024. PEAK’s impact metrics capture value even when a hunt finds no threat, including detections created or updated, gaps identified and closed, and vulnerabilities and misconfigurations identified and remediated.

Incidents opened is a poor standalone metric. Splunk's PEAK metrics guidance calls it "probably the most obvious measure" but "not a strong indicator of success" on its own, and recommends pairing it with how many of those incidents a hunt-derived detection later caught.

Hunts per hunter is worse. Intel 471 warns that tracking it as a vanity metric "can lead the hunt program astray or drive talent away."

For board reporting, eSecurityPlanet's illustrative example shows the mechanism that matters more than either vanity metric: in the example, validated hunts produce maintained detection logic and expand ATT&CK technique coverage, rising from 22% to 34% across 18 validated hunts.

Where the Hunting Gets Done: Four Threat Hunting Approaches

The four approaches differ less in effort than in what they hand back. The SANS 2026 survey reports internal execution holding at 58%, the level it reached in 2025, while full outsourcing kept dropping, to 18% from 30% in 2025.

The scope and cadence of hunting bundled with MDR vary by provider and contract. Most MDR offerings, traditional or AI-native, treat hunting as retro-hunts after major attacks or indicator of compromise (IOC) sweeps, short of a dedicated, continuous, hypothesis-driven practice, though a few providers now advertise more.

A genuine provider can explain which hypotheses it pursues, which data sources it uses, how it documents hunts, and what output it provides when a hunt finds nothing.

Dedicated managed hunting sells hunter time without the hiring, and quality still depends on the engagement; ask how much of the program is IOC sweeps versus hypothesis-driven hunts.

Agentic execution is an emerging delivery approach, and independent evaluations remain scarce. Vendor marketing in this space increasingly claims agents can both generate and test hypotheses, a claim worth testing directly before taking it at face value. An MDPI study found large language models "do not yet offer a clear advantage over human-generated queries in many threat hunting scenarios."

Decision Criteria: Match the Approach to Your Constraint

None of the four approaches removes the hypothesis and data work covered earlier; they change who runs the queries and how often. The right starting point is identifying what is actually blocking repeatable hunting today. If data is the bottleneck, as the SANS 2026 survey reports for half of respondents, fix telemetry and retention before buying any hunting service; missing historic logs limit what any hunter, managed or in-house, can reconstruct.

If a detection engineer or incident responder can hunt but keeps losing the time, block and protect the hours first. Consider external execution only for the hunts that remain in the backlog.

If you already pay for MDR and lean on its bundled hunting, apply the buyer questions above and ask for the last empty-hunt report. If none exists, treat the missing cadence as an unanswered diligence question until the provider can show one.

When the backlog has more hypotheses than hands, separate hypothesis authorship from execution so one expert's hypothesis can run across endpoint, identity, cloud, and software-as-a-service (SaaS) logs in parallel. If the team already sits at HMM3, close the gap to HMM4 by converting its proven procedures into automated detections.

If your mid-market security team has more hypotheses than available hunter time, one workable mix is in-house hypothesis ownership, protected time for one or two people, and outside execution for the hunts that never make it off the list.

That mix still depends on telemetry adequate for each hunt's scope, documented outputs, and expert judgment. External execution cannot recreate historic logs that were never collected, or rescue a hypothesis that isn't falsifiable to begin with.

Hunting Is Starting to Split Into Expert Hypotheses and Agentic Execution

Some vendors are now building toward an architecture where experts retain hypothesis generation and judgment while agents handle search and correlation, though others market agents that generate hypotheses too. The UK Home Office's 2019 guide staked out the older, more settled position: hunters develop hypotheses from threat intelligence, situational awareness, and domain expertise, treating that judgment as a distinctly human skill. Which framing holds up is still being contested in the market.

Where agentic execution changes the math is scale. A single hunt can return a large volume of events to correlate, and running that correlation in parallel addresses the HMM3 scaling problem Bianco identified, where running every procedure on schedule otherwise requires more security experts. Whether that translates into lower total cost once review effort is counted is a question worth testing in a pilot.

The skepticism is visible and earned. The share of hunters ranking artificial intelligence and machine learning (AI/ML) as a top planned improvement fell from 48% to 39% between 2025 and 2026. SecurityWeek expects agentic hunting to stay "limited to discrete AI agents tackling individual tasks." The durable version uses bounded agents to run expert-defined analyses while experts retain the lead judgment.

Daylight's Threat Hunting service runs as its own engagement, separate from MDR, on the same platform and with the same security experts from incident response, threat hunting, and detection engineering, all with over 10 years of experience and no juniors.

A security expert writes the hypothesis, and a coordinated agent swarm executes a controlled five-step process, iteratively reducing the dataset across up to 90 days of historic telemetry.

Hunts run on a defined frequency, which turns selected backlog items into scheduled work instead of leaving them for whenever capacity frees up. The team escalates unexplained behavior into investigation and converts validated findings into detections, while IOC sweeps run alongside for known threats.

Frequently Asked Questions About Threat Hunting Programs

How Long Does It Take to Build a Threat Hunting Program?

There's no fixed timeline, and a vendor promising one in weeks is oversimplifying. The clock starts once telemetry collection catches up with the hypotheses worth testing: a team with broad existing collection can validate its first hunt within weeks, while a team still closing logging gaps should expect that data work to absorb most of the first quarter. A useful progress check is whether the backlog is actually shrinking, or just shifting from "no hypothesis" to "no data"; the second failure mode stalls a program as surely as the first.

Who Should Run the First Hunts?

Whoever already reads logs and writes queries for a living, and that matters more than having "hunter" in a title. Detection engineers and incident responders usually fit best for exactly that reason. The harder requirement is protected time on a calendar: a candidate with strong hunting instincts but no blocked hours will still lose every hunt to the alert queue. If nobody on the team has both the skill and the spare capacity, that's a signal to buy execution for now and build the internal role later.

What Happens to a Hunt That Finds Nothing?

A null result is only meaningful if the telemetry needed to detect the behavior was actually collected and retained for the full lookback window. When that condition holds, log the hunt anyway: record the technique ruled out, the data sources confirmed to have coverage, and the query used, so the next hunter does not have to verify the same ground from scratch. PEAK counts exactly this kind of documented, telemetry-backed null result as a program output in its own right, alongside detections and closed gaps.

What's the Fastest Way to Tell If a Managed Hunting Provider Is Doing Real Hunts?

Ask for a sample hunt report with client details redacted. A provider running real, hypothesis-driven hunts can usually produce one; a provider repackaging periodic IOC sweeps as "hunting" often cannot, or produces something closer to a scan summary than an investigation record. Vague answers about which data sources were queried, or no example of a hunt that found nothing, are the clearest signs the engagement runs on an occasional, undocumented cadence.

‍