What is a threat hunting program?

A threat hunting program is the named discipline that proactively searches an environment for attacker activity that the deployed detection library did not surface. It runs against the same telemetry the security operations centre (SOC) monitors, but on a different cadence and against a different question. The SOC reacts to alerts; the hunting program forms hypotheses and tests them. The program produces three classes of outcome on every cycle: confirmed incidents handed to incident response, new and tuned detections handed to detection engineering, and recorded negative results that bound the coverage claim. A program without those three outcomes is exploratory analysis, not a programme.

How is threat hunting different from SOC monitoring, MDR, and incident response?

SOC monitoring reacts to alerts the detection library raised. Managed detection and response (MDR) is the outsourced packaging of monitoring, triage, and response. Incident response (IR) handles confirmed compromises. Threat hunting sits upstream of all three: it forms hypotheses about activity the detection library would miss, tests them against telemetry on a deliberate cadence, and feeds confirmed activity into IR while feeding the rest back into detection engineering as new or tuned content. The four disciplines share the asset map, the threat picture, and the platform, but they run on different cadences, against different inputs, and produce different evidence. A mature programme runs all four with documented handoffs rather than letting hunting drift into ad hoc IR or detection engineering.

What is the hunt loop?

The hunt loop is the four-phase repeatable cycle every chartered hunt runs through: hypothesis (a falsifiable statement about adversary activity in the environment, sourced from threat intelligence, TTP-based reasoning, baseline anomaly, or asset and identity risk), investigation (the analyst queries telemetry to test the hypothesis, pivots across data sources, names the affected assets and accounts, and records the queries on the artefact), uncovering (the analyst classifies the outcome as confirmed activity, suspicious requiring further work, false positive, or true negative with bounded coverage), and inform and enrich (the artefact is filed, confirmed incidents are handed to IR, new and tuned detections are handed to detection engineering, gaps are filed back to programme governance, and the hunt is closed on the record). Sqrrl named this loop in 2015; PEAK and TaHiTI added structure on top. The loop is the part that turns analyst curiosity into operating capacity.

What is the PEAK threat hunting framework?

PEAK (Prepare, Execute, Act with Knowledge) is the threat hunting framework SURGe (the Splunk threat research team) published in 2023 as a structured alternative to ad hoc hunting. It splits the work into three phases. Prepare covers hypothesis formation, scope definition, data source confirmation, and success criteria. Execute covers the data gathering and query work, the analysis, and the documentation of method. Act with Knowledge covers communicating results, handing confirmed activity to IR, handing tuned content to detection engineering, capturing knowledge for the next cycle, and updating the hunt backlog. PEAK names three hunt types: hypothesis-driven, baseline (anomaly-detection-style), and model-assisted. Programmes that adopt PEAK get a shared vocabulary for the hunt artefact and a shared structure for the handoff to detection engineering and IR.

What hypothesis types should a hunting program run?

Four hypothesis types cover the practical range. Intelligence-led hypotheses start from a CTI report, an emerging TTP advisory, a sector ISAC bulletin, or a vendor threat brief and ask whether the named technique is present in the environment. TTP-based hypotheses start from a MITRE ATT&CK technique mapped to the asset surface and ask whether the technique would currently produce a detection. Baseline-anomaly hypotheses start from a learned-normal model of a data source and ask what does not fit. Crown-jewel hypotheses start from the asset or identity register, name a high-impact target, and ask which TTPs would reach it given the current control set. A balanced programme runs all four types across a quarter rather than over-indexing on any one because each type catches a different class of gap.

How do hunt findings flow into the rest of the security operating model?

A hunt finding flows into exactly one of four downstream destinations and the destination is recorded on the artefact. Confirmed adversary activity flows to incident response with a named investigation reference and the hunt artefact attached. Confirmed misconfiguration or vulnerability flows to the vulnerability backlog with a severity, an asset binding, and the hunt artefact attached for evidence. New or tuned detection content flows to detection engineering with the rule logic, the test cases, and the hunt evidence. Gaps that cannot be resolved at the hunt layer flow to programme governance for capacity or telemetry decisions. The artefact carries the routing record so every hunt has a traceable downstream effect rather than a slide in a quarterly report.

What audit and framework reads does a hunting program support?

A well-operated hunting programme produces evidence read by ISO 27001 (Annex A 5.7 threat intelligence, 8.16 monitoring activities, 8.32 change management when hunt outcomes drive detection changes), SOC 2 (CC7.2 monitoring, CC7.3 evaluation of security events, CC7.4 incident response coordination), PCI DSS (Req 11.5 detect and respond to intrusions, Req 12.10 incident response), NIST SP 800-53 (SI-4 system monitoring, RA-3 risk assessment, IR-6 incident reporting), NIST CSF 2.0 (DE.AE adverse event analysis, DE.CM continuous monitoring, RS.AN incident analysis), CIS Controls (Control 8 audit log management, Control 13 network monitoring and defense), and MITRE ATT&CK as the coverage spine. The same hunt artefact answers each framework rather than each framework forcing a separate evidence assembly.

When does an organisation need a chartered threat hunting program rather than ad hoc analyst time?

Six signals indicate that ad hoc hunting has reached its limit and a chartered programme is the right next step. The same hypothesis has been hunted three times without a recorded outcome. Detection coverage of the named ATT&CK technique set cannot be answered from the existing record. CTI reading is happening but does not produce operational change. Hunt outcomes are kept in analyst notebooks and not handed to detection engineering. Audit asks for evidence of proactive threat detection effort and the answer is improvised. The board or audit committee has asked about coverage and the answer was a tool count rather than a coverage claim. Organisations with one or two of these signals can run a structured weekly hunting slot inside the existing SOC or detection engineering team; organisations with four or more typically need a named programme owner, a written charter, and an operating cadence.

How long does it take to build a threat hunting program?

A practical build runs across three phases over six to twelve months. The foundation phase (months 1 to 3) writes the charter, names the lead, settles the methodology choice (PEAK, TaHiTI, or a documented in-house variant), confirms the data sources, lands the hunt backlog as a working artefact, and runs the first two hunts end to end to prove the cadence. The operating phase (months 4 to 6) runs the full hunt loop on a fixed cadence (weekly or fortnightly is the most common starting point), builds the hunt-to-detection handoff with detection engineering, and starts the first metrics reads. The maturity phase (months 7 to 12) operates the full cadence including monthly programme review and quarterly methodology review, produces the first audit-ready evidence pack, builds the MITRE ATT&CK coverage matrix from the hunt record, and tunes the staffing model against actual throughput. Programmes that rush past the foundation phase typically rebuild it after the first quarter when the cadence breaks; programmes that work through it sustain the unit across SOC manager and CISO transitions.

← Back to Blog

Enterprise13 June 202621 min read

Threat Hunting Program Guide: Structure, Cadence, and Evidence

A threat hunting program is the named discipline that proactively searches the environment for attacker activity the deployed detection library did not catch. Done well, it is the unit that tells the audit committee how much of the MITRE ATT&CK technique set the organisation has actually hunted against and what changed in the detection library as a result. Done badly, it is a quarterly slide listing tools and conference attendances. This guide is for CISOs, SOC managers, detection engineering leads, security operations leaders, AppSec teams scaling detection across product surfaces, and security program owners building a hunting capability from scratch, rationalising an inherited ad hoc model, or evidencing a hunting effort that runs in practice but has never been formalised. It walks through the charter, the staffing model, the four-phase hunt loop, the PEAK and TaHiTI methodologies, the hypothesis types, the cadence, the metrics, the audit reads, and the framework crosswalk that turn hunting from a research activity into an operating function.

What Threat Hunting Is, and What It Is Not

Threat hunting is the proactive, hypothesis-driven search through telemetry for adversary activity the deployed detection library did not surface. It assumes the environment is already compromised somewhere and works to find the evidence rather than waiting for the detection content to alert. The mindset is investigative rather than reactive: the analyst poses a question that the existing rules cannot answer, runs queries to test it, and classifies the outcome. The discipline is not new (it traces to the Sqrrl team that published the original hunt loop in 2015), but the operating practice has matured significantly across the past decade as detection-library coverage stopped scaling with environment complexity.

Threat hunting is not security monitoring. Monitoring reacts to alerts the deployed content raised. Threat hunting is not incident response. IR confirms, contains, and recovers from already-detected compromises. Threat hunting is not detection engineering, although the two are tightly coupled: detection engineering writes and maintains the rule library, and hunting tests where the library does not yet cover. Threat hunting is not penetration testing. Pentests probe whether a control would block an attacker; hunting probes whether an attacker is already past the controls. The four disciplines share the asset map, the telemetry, and the platform, but they run on different cadences, against different inputs, and produce different evidence. A programme that conflates them tends to over-rotate on one at the expense of the others.

A working hunting programme produces three classes of outcome on every cycle: confirmed incidents handed to enterprise incident response with the hunt evidence attached, new or tuned detections handed to detection engineering with the rule logic and test cases, and recorded negative results that bound the coverage claim. A programme without those three outcomes is exploratory analysis, not a programme. The structural difference is the artefact: the hunt has a hypothesis, a scope, a query record, a finding classification, a routing decision, and a closure stamp. The artefact is what the audit reads.

Where Hunting Sits Inside the Wider Operating Model

The most common conceptual confusion in early hunting builds is the boundary with the security operations centre, the managed detection and response (MDR) provider, and the incident response function. Hunting sits upstream of all three. The SOC reacts to the validated alerts the deployed content raised on the customer telemetry stack. MDR is the outsourced packaging of monitoring, triage, and active response. IR confirms, contains, and recovers when a compromise is in scope. Hunting forms a hypothesis about activity that the SOC and MDR would not currently catch, tests it against the telemetry those units rely on, and flows confirmed findings into IR while flowing the rest back into detection engineering as new or tuned content.

The same boundary applies to extended detection and response (XDR), endpoint detection and response (EDR), and network detection and response (NDR): each is a technology category that surfaces alerts on a specific surface. Hunting works across the surfaces with hypotheses the surface-specific detection library was not designed to answer. The relationship with the security information and event management (SIEM) platform is the most operationally important: hunting runs against the long-term searchable record the SIEM maintains, so hunting capacity is directly limited by SIEM retention, parser fidelity, and query performance. Programmes that try to hunt without addressing the data layer first tend to rediscover that detection content is not the bottleneck; telemetry quality is.

Hunting also has a deliberate relationship with threat intelligence platforms (TIPs) and the broader intelligence function. Intelligence-led hunting starts from a CTI report and forms an operational hypothesis from it; the hunt outcome is fed back to the intelligence team as a coverage answer to the intelligence requirement. The relationship also extends to breach and attack simulation (BAS): BAS validates whether detection content fires on a known technique; hunting tests whether an undetected technique is in the environment. The two are complementary, not redundant.

The Hunt Loop: Four Phases on Every Hunt

Every chartered hunt runs through a four-phase loop. The loop has roots in the Sqrrl team's 2015 hunt cycle (Hypothesis, Investigation, Uncovering, Inform and Enrich) and has been extended by PEAK and TaHiTI. The phases run sequentially per hunt but the loop iterates continuously at the programme level. Hunts that skip a phase tend to leak knowledge and stop producing operational change.

Phase 1: Hypothesis

The analyst forms a falsifiable statement about adversary activity that the deployed detection library would not currently catch. A defensible hypothesis names the actor class or behaviour pattern (for example, "a service account is being used for lateral SMB authentication outside its baseline window"), the data source that would carry the evidence, and the time window to test against. Hypotheses without a data source named at formation tend to dissolve in the investigation phase.

Phase 2: Investigation

The analyst queries the named data source against the hypothesis, pivots across adjacent telemetry to confirm or refute, and records every query verbatim on the hunt artefact. The investigation phase is the phase where most analyst time is spent and where the most knowledge leakage happens; programmes that do not enforce query recording rebuild the same investigation three months later because nobody remembers which queries already ran. The phase ends when the analyst can name the affected assets and accounts, or has bounded the negative answer to a specific scope.

Phase 3: Uncovering

The analyst classifies the outcome against a constrained set: confirmed adversary activity (route to IR), suspicious requiring further investigation (route back to phase 2 with expanded scope), false positive on the data (record the pattern that produced the false signal), or true negative with bounded coverage (record the scope of the negative so the next hunt does not re-test the same window). Uncovering is the phase that turns analyst impression into a written outcome the next reviewer can act on.

Phase 4: Inform and Enrich

The hunt artefact is filed on the record. Confirmed activity is handed to incident response with the artefact attached. New or tuned detections are handed to detection engineering with the rule logic, test cases, and hunt evidence so the new content is deployable. Telemetry or capacity gaps that cannot be closed at the hunt layer are handed to programme governance. The hunt is then closed on the workspace with a routing record so every hunt has a traceable downstream effect rather than a slide in a quarterly report.

The loop is the structural answer to the most common hunting failure mode: hunts that produce stories but no operational change. Each phase exists to remove a specific failure: the hypothesis phase prevents fishing expeditions, the investigation phase prevents lost analyst knowledge, the uncovering phase prevents inconclusive endings, and the inform and enrich phase prevents one-shot value from being lost on the next cycle. Programmes that enforce the four phases on the artefact tend to keep producing operational change across staffing changes; programmes that skip phases tend to need re-founding every two years.

Methodology Choice: PEAK, TaHiTI, or a Documented In-House Variant

Adopting a named methodology is one of the highest-leverage decisions in the foundation phase. The methodology gives the team a shared vocabulary, a shared artefact shape, and a shared expectation for the handoff to detection engineering and IR. Two methodologies dominate the practical literature: PEAK from SURGe (the Splunk threat research team, published 2023) and TaHiTI from a Dutch financial-sector group (published 2018). Programmes that adopt one rather than improvising tend to sustain the cadence across staff changes more reliably.

PEAK (Prepare, Execute, Act with Knowledge)

PEAK splits the work into three named phases that map cleanly onto the hunt loop. Prepare covers hypothesis formation, scope definition, data source confirmation, and success criteria. Execute covers data gathering, query work, analysis, and method documentation. Act with Knowledge covers communicating results, handing confirmed activity to IR, handing tuned content to detection engineering, capturing knowledge, and updating the hunt backlog. PEAK also names three hunt types (hypothesis-driven, baseline anomaly-detection, and model-assisted) which makes the backlog easier to balance across cycles. Programmes that need a vendor-neutral published method with strong documentation tend to land on PEAK.

TaHiTI (Targeted Hunting integrating Threat Intelligence)

TaHiTI structures the work into three phases (initiate, hunt, finalise) and explicitly grounds hypothesis sourcing in cyber threat intelligence. Initiate captures the hunt trigger (a CTI report, an emerging TTP, a sector incident, an internal anomaly), enriches it into a hunting hypothesis, and scopes the data sources and time windows. Hunt runs the investigation, records the queries and findings, and classifies the outcome. Finalise produces the hunt report, hands confirmed activity to IR, hands tuned content to detection engineering, and feeds CTI requirements back to the intelligence function. TaHiTI suits programmes that already run an intelligence function and want a method that binds CTI consumption to operational hunting.

Documented in-house variant

Mature programmes sometimes operate a documented in-house variant that borrows from both. The acceptable form of in-house variant has the four-phase artefact, named hypothesis types, a named handoff with detection engineering and IR, and a method review cadence (typically quarterly). The unacceptable form is undocumented ad hoc practice that depends on the lead analyst's memory; that form does not survive the lead analyst's departure. The methodology document is the artefact the programme governance review reads each quarter.

The methodology choice is reversible but not cheap to reverse. Programmes that change methodology more than once a year tend to lose three to six months of operating momentum each time. The pragmatic recommendation is to pick PEAK if the programme is being founded without a heavy CTI function in place, pick TaHiTI if the programme is being founded inside or adjacent to a working CTI function, and only pick an in-house variant once the programme has run a year of disciplined cycles on one of the published methods and has evidence-backed reasons for the divergence.

Four Hypothesis Types a Balanced Programme Runs

Hypothesis sourcing is the activity that limits the programme's ceiling. Programmes that over-index on one hypothesis source tend to plateau quickly: pure intelligence-led programmes miss in-environment anomalies the CTI feed never names; pure baseline-anomaly programmes miss adversary techniques that hide in normal-looking traffic; pure TTP-led programmes miss the asset-specific weaknesses that do not map cleanly onto ATT&CK. A balanced programme runs the four types across a quarter and tracks the source mix.

Intelligence-led

Start from a CTI report, an emerging TTP advisory, a sector ISAC bulletin, an IR-from-an-adjacent-customer brief, or a vendor threat brief and ask whether the named technique is present in the environment now. The strength of this type is operational relevance to current adversary activity; the weakness is that the source is upstream of the team and not always tuned to the environment's actual exposure.

TTP-based

Start from a MITRE ATT&CK technique mapped to the asset surface and ask whether the technique would currently produce a detection. If not, hunt for the technique manually and feed the missing detection back to detection engineering. The strength is systematic coverage growth against a public technique catalogue; the weakness is that the catalogue does not always reflect novel adversary tradecraft.

Baseline anomaly

Start from a learned-normal model of a data source (authentication patterns, DNS request distribution, service-account behaviour, egress destination mix) and ask what does not fit. The strength is that this type catches novel adversary behaviour that has no published signature; the weakness is the false positive rate is highest here, so the team needs disciplined classification rules to avoid noise drift.

Crown-jewel

Start from the asset or identity register, name a high-impact target (a critical database, a production deploy key, a privileged service account, a customer data lake), and ask which TTPs would reach it given the current control set. Then hunt each TTP against the surrounding telemetry. The strength is direct relevance to the business risk picture; the weakness is the technique scope per target is large and each hunt is expensive.

Tracking the source mix is itself a programme-level metric. A practical target is roughly balanced thirds across intelligence-led, TTP-based, and the anomaly-or-crown-jewel pair, with deliberate skew in response to a named driver (a sector incident triggering more intelligence-led work for a quarter, an audit driving more TTP-based work, a major release driving more crown-jewel work). The source mix conversation is the conversation the monthly programme review has rather than the "how many hunts did we run" conversation that tends to drive vanity volume.

Staffing Model: Four Role Families That Make the Programme Run

A working hunting programme has four named role families. Headcount depends on scale, the telemetry footprint, and the cadence target. Smaller programmes consolidate roles onto a single analyst; larger programmes split each role across a small team. The roles can sit inside an existing SOC, detection engineering, or threat intelligence team provided the programme has a named lead and a written charter rather than an unnamed shared responsibility.

Hunting lead

Owns the methodology, the cadence, the metrics, and leadership reporting. The lead is the named accountable owner for the hunt backlog and the operating record. The lead is full-time at any non-trivial scale because the weekly cadence and the monthly programme review do not sustain themselves through volunteer effort.

Hunt analysts

Run the hunt loop end-to-end on assigned hypotheses, write the queries, record the investigation, classify the outcome, and produce the handoff artefacts. Hunt analyst load scales with the cadence target and the telemetry complexity rather than with organisational size. A common sizing rule is one hunt analyst per two to four hunts per week at sustainable depth.

Detection engineering liaison

Owns the hunt-to-detection handoff. Reviews the new and tuned content the hunts produced, validates the rule logic against the deployment pipeline, runs the test cases, and tracks the live-detection survival rate. Programmes that try to do this handoff without a named liaison tend to find that hunt-produced detection content sits in a backlog for months before deployment.

Programme governance

Maintains the methodology document, the hypothesis backlog, the source mix policy, the framework crosswalk, and the cadence record. Owns the quarterly methodology review and the annual programme assessment. The governance role often sits with the lead in small programmes and becomes a named part-time role at scale.

A practical sizing rule of thumb: an organisation with one SIEM, one EDR, and a small asset footprint runs the programme with a hunting lead plus one hunt analyst, with the detection engineering liaison sitting with an existing detection engineer; an organisation with multiple telemetry sources, a medium asset footprint, and one or two regulatory regimes runs the programme with a lead, two to three analysts, and a named liaison; an organisation with broad telemetry, a large asset footprint, and multiple regulatory regimes runs the programme as a four-to-eight-person unit. The role mapping is usually captured on the existing security RACI template so the operating model is auditable on paper before it is auditable in the record.

The Four-Layer Operating Cadence

The cadence turns the methodology from a document into evidence. Without it, hunting is a project that runs three times a year and is never compared against itself. With it, hunting is a unit that operates against a record with timestamped state changes, recorded outcomes, and reproducible reporting. The four layers are calibrated against operational volume, not against meeting tradition.

Daily backlog hygiene

A short window each working day where the lead reviews the hunt backlog, confirms the next hunt is ready (data source confirmed, hypothesis sharp, scope set), and the analyst running the current hunt records progress on the artefact. The daily layer is the layer that catches stuck hunts before they age out.

Weekly hunt cycle

The core operating beat. One or more chartered hunts run through the four phases each week. The weekly review closes the completed hunts on the workspace, hands the outcomes to IR or detection engineering, and assigns the next hunts from the backlog. The weekly beat is the cadence layer the audit committee reads as evidence the programme operates rather than aspires.

Monthly programme review

A leadership session that reads the throughput, outcome mix, coverage, and conversion metrics. The output is a recorded set of programme-level decisions (hypothesis backlog adjustments, telemetry asks, staffing requests, capacity escalations). The monthly review is what prevents the cadence from drifting into vanity volume by forcing an outcome-mix conversation rather than a hunt-count conversation.

Quarterly methodology review

A governance session that reads the methodology document against the operating evidence. The artefact shape against the actual hunt records. The hypothesis-source mix against the target. The detection-engineering handoff against the live-detection survival rate. The output is a versioned set of methodology updates with effective dates. The quarterly review prevents methodology drift from accumulating into an unwritten in-house variant.

Each cadence layer runs against the same record. The daily backlog hygiene works the backlog on the workspace. The weekly hunt cycle closes hunt artefacts on the same workspace. The monthly programme review reads metrics derived from the same workspace. The quarterly methodology review reads the methodology artefacts attached to the same workspace. The activity log captures the timestamped state changes from every cycle so the audit reads the cadence as one continuous record rather than as four separate meeting trails.

Metrics: Five Families the Programme Operates Against

Hunt-volume metrics on their own are vanity. A working programme operates against five metric families. Reporting in each family is anchored to the record so the leadership read is reproducible from the live workspace rather than from an assembled dashboard rebuilt every quarter.

Throughput metrics

Hunts completed per cycle. Mean hunt duration. Hunt backlog burn rate. Backlog age distribution. The metrics surface throughput stress before it becomes a missed-cycle trend.

Outcome mix metrics

Confirmed-incident rate, new-detection rate, tuned-detection rate, bounded-negative rate, false-positive rate. The mix is the most operationally interesting metric in the set because it tells the programme whether hunts are producing value or producing reports.

Coverage metrics

ATT&CK technique coverage produced by the programme. Data source coverage per hunt. Asset-tier coverage. Gap-closure latency from hunt-identified gap to remediation. Coverage metrics are what answer the audit committee question about proactive detection effort.

Conversion metrics

Hunt-to-detection conversion rate. Mean time from hunt to live detection rule. Detection survival rate at six months. Conversion metrics tell the programme whether the detection engineering handoff is working as a pipeline or breaking as a bottleneck.

Programme health metrics

Hypothesis-source diversity. Repeat-hypothesis rate. Analyst rotation. Training cadence. Methodology drift incidents per quarter. Health metrics surface drift before it produces an audit finding.

The metrics live on the same record the programme operates on. The monthly programme review reads them from the workspace rather than from a parallel spreadsheet that has to be rebuilt each cycle. Programmes that maintain metric dashboards detached from the record tend to find that the dashboard and the record disagree by month three and the review becomes a reconciliation conversation rather than a decision conversation.

Routing Hunt Findings into the Wider Operating Model

A hunt finding flows into exactly one of four downstream destinations and the destination is recorded on the artefact. Recording the routing decision is the structural answer to the most common hunting failure mode: hunts that produce outcomes that nobody acts on because there is no named recipient.

Confirmed adversary activity to IR

Routed to incident response with a named investigation reference and the hunt artefact attached. The IR team takes containment and recovery from there. The hunt artefact remains the audit-readable origin record so the post-incident review can trace the discovery path.

Misconfiguration or vulnerability to the backlog

Routed to the vulnerability finding intake workflow with a severity, an asset binding, a CWE category, and the hunt artefact attached for evidence. The finding then flows through the normal vulnerability lifecycle on the workspace with the hunt as the documented source.

New or tuned detection content to detection engineering

Routed to detection engineering with the rule logic, the test cases, and the hunt evidence so the new content is deployable rather than indicative. The artefact tracks the rule through the deployment pipeline so the hunt-to-detection conversion rate is calculable from the record rather than from analyst recall.

Telemetry or capacity gap to programme governance

Routed to programme governance when the hunt cannot be answered at the existing telemetry or capacity. Governance decides whether to expand the source set, add parser coverage, increase analyst capacity, or accept the bounded coverage gap with a documented reason. The artefact captures the routing so the gap is visible to leadership rather than buried in analyst notes.

The routing record is what makes hunting auditable. The audit question is not how many hunts ran; the audit question is what happened as a result of the hunts that ran. A programme that can answer the second question from the record without reconstruction is a programme the audit committee can defend.

Framework Crosswalk and Audit Evidence

A well-operated hunting programme produces evidence read by multiple compliance regimes from one source of truth. The same artefact (hypothesis, scope, queries, outcome, routing) answers each framework rather than each framework forcing a separate evidence assembly.

Framework	Control reference	What the hunt record evidences
ISO 27001	Annex A 5.7, 8.16, 8.32	Threat intelligence consumption, monitoring activities, change management on detection content driven by hunt outcomes.
SOC 2	CC7.2, CC7.3, CC7.4	Monitoring of system components, evaluation of security events, incident response coordination across the hunt-to-IR handoff.
PCI DSS	Req 11.5, Req 12.10	Intrusion detection and response, incident response procedures that the hunt cycle feeds.
NIST SP 800-53	SI-4, RA-3, IR-6	System monitoring breadth, risk assessment evidence, incident reporting traceable to the hunt that surfaced the activity.
NIST CSF 2.0	DE.AE, DE.CM, RS.AN	Adverse event analysis, continuous monitoring effort, incident analysis with the hunt artefact as the upstream evidence.
CIS Controls	Control 8, Control 13	Audit log management evidence, network monitoring and defense activity bounded by hunt coverage.
MITRE ATT&CK	Technique coverage	Coverage spine for the hunt backlog and the conversion artefact for detection engineering handoff.

The framework crosswalk is one artefact maintained on the workspace by programme governance, not seven separate evidence assemblies rebuilt for each audit. The crosswalk also reads alongside the broader security compliance automation workstream so the hunt evidence sits naturally inside the wider audit calendar.

When to Charter a Programme Rather Than Run Ad Hoc Hunts

Not every organisation needs a chartered hunting programme. Six signals indicate that ad hoc hunting has reached its limit and a chartered unit is the right next step. The signals are observable from the existing record without needing to commission an assessment.

The same hypothesis has been hunted three or more times without a recorded outcome that the next analyst can find.
Detection coverage of the named ATT&CK technique set cannot be answered from the existing record without analyst recall.
CTI reading is happening on a cadence but does not produce operational change downstream.
Hunt outcomes are kept in analyst notebooks and not reliably handed to detection engineering.
An audit has asked for evidence of proactive threat detection effort and the answer was improvised rather than read from a record.
The board or audit committee has asked about coverage and the answer was a tool count rather than a coverage claim.

Organisations showing one or two of these signals can run a structured weekly hunting slot inside the existing SOC or detection engineering team without a separate programme charter. Organisations showing four or more typically need a named programme owner, a written charter, an operating cadence, and a record substrate the cadence runs on. Organisations with all six are usually already paying coordination cost without coordination structure: chartering the programme converts that cost into capacity.

Common Failure Modes and How to Avoid Them

Seven failure modes recur across hunting programmes regardless of vertical or scale. Naming them in the charter and reading them at the quarterly methodology review tends to prevent the silent versions from accumulating into a programme stall.

Vanity volume

Counting hunts run rather than outcomes produced. The fix is to make outcome mix the headline metric on every monthly review and to demote hunt count to a supporting line.

Fishing expeditions

Starting investigation without a falsifiable hypothesis. The fix is to enforce the hypothesis phase on the artefact: no hunt enters investigation without a recorded hypothesis the next reviewer can read.

Knowledge leakage

Queries lived in the analyst's console and were never recorded. The fix is to require query capture on the artefact as a precondition for closing the hunt.

Inconclusive endings

Hunts that closed without a classified outcome. The fix is to require the uncovering phase to produce one of the four classifications (confirmed, suspicious, false positive, bounded negative) before close.

Broken detection handoff

Hunt-produced detection content sits in a backlog for months. The fix is the named detection engineering liaison and the conversion metric read at every monthly review.

Hypothesis-source monoculture

Programme runs only intelligence-led hunts and misses in-environment anomalies, or runs only TTP-based hunts and misses crown-jewel-specific risk. The fix is the source mix policy and the quarterly source mix conversation.

Methodology drift

The methodology document and the actual practice diverge silently until the programme runs on tacit rules nobody can reconstruct after a staff change. The fix is the quarterly methodology review reading the document against the live evidence.

Build Phases: Foundation, Operating, Maturity

A practical build runs across three phases over six to twelve months. Each phase has a named deliverable rather than a generic milestone. Programmes that compress the foundation phase tend to rebuild it after the first quarter when the cadence breaks.

Foundation phase (months 1 to 3)

Write the charter. Name the lead. Pick the methodology (PEAK, TaHiTI, or a documented in-house variant with a stated reason for the divergence). Settle the hypothesis-source mix policy. Confirm the data sources the programme depends on. Land the hunt backlog as a working artefact on the workspace. Run the first two hunts end to end against the methodology to prove the cadence is achievable. Foundation phase ends when the team can describe the methodology, the cadence, and the routing without referring to slides.

Operating phase (months 4 to 6)

Run the full hunt loop on a fixed cadence (weekly or fortnightly is the most common starting point at non-trivial scale). Build the hunt-to-detection handoff with detection engineering and confirm the first rules survive in the live library. Land the throughput and outcome mix metrics on the monthly review. Start the framework crosswalk from the first audit calendar event. Operating phase ends when the programme has produced a four-week run of cycles with no missed beats and the detection engineering liaison is reading conversion as a real metric.

Maturity phase (months 7 to 12)

Operate the full cadence including monthly programme review and quarterly methodology review. Produce the first audit-ready evidence pack covering the framework crosswalk and the coverage spine. Build the MITRE ATT&CK coverage matrix from the hunt record rather than from a parallel spreadsheet. Tune the staffing model against actual throughput rather than the original sizing assumption. Maturity phase ends when the programme survives a CISO or SOC manager transition and the audit committee can read a defensible answer to the proactive detection effort question.

Where SecPortal Fits Inside a Hunting Programme

SecPortal is not a SIEM, not an EDR, not an XDR, not an MDR provider, does not ingest live telemetry, does not run hunting queries against telemetry, does not execute response actions, does not maintain a detection library, and does not ship integrations into Splunk, Microsoft Sentinel, Google Chronicle, IBM QRadar, Sumo Logic, Elastic Security, CrowdStrike Falcon, SentinelOne Singularity, Microsoft Defender XDR, Palo Alto Cortex XDR, Jira, ServiceNow, Slack, PagerDuty, Opsgenie, or any SOAR. The programme runs on the SIEM, EDR, XDR, or data lake the organisation already operates. What SecPortal supplies is the record substrate the cadence and the audit reads operate against.

On the operating side, engagement management runs each hunt cycle as a scoped engagement with a named owner, start and end dates, and the cadence record; findings management captures hunt-derived findings with CVSS 3.1 severity, CWE category, asset binding, and the hunt artefact attached; bulk finding import accepts hunt-side outputs from outside tooling in CSV, Nessus, and Burp formats so the programme does not need to re-key results that already exist; retesting workflows pair each hunt-identified weakness to a verified close. The finding overrides mechanism records false positive, accepted risk, and severity adjustment decisions on the same record so the hunt outcome stays auditable across closure.

On the governance side, team management with RBAC scopes access across the hunting lead, hunt analysts, detection engineering liaison, and programme governance roles; MFA enforcement protects the workspace against account compromise; the activity log captures every hunt artefact state change with timestamp and actor for the audit trail and exports as CSV for the audit fieldwork response; document management holds the charter, the methodology document, and the framework crosswalk on the same workspace the cadence runs against.

On the reporting side, AI report generation drafts the per-cycle hunt narrative, the monthly programme review pack, and the leadership summary from the workspace record; compliance tracking maps hunt evidence against ISO 27001, SOC 2, PCI DSS, NIST 800-53, and NIST CSF 2.0 templates; continuous monitoring supports the recurring detection-baseline scans the programme pairs with hunts; and the white-labeled client portal on tenant subdomains supports cross-organisation programme reviews without forcing reviewers onto the main workspace. The platform is the operating record for the programme; the methodology, the cadence, and the hypotheses are decisions the organisation makes.

Putting It Together

A threat hunting programme is a structural answer to a coverage problem. The deployed detection library catches the techniques it was written for; the hunting programme catches the techniques it was not. Done well, the programme produces a coverage answer the audit committee can read, a detection content pipeline the SOC benefits from, and an incident-discovery channel that catches activity the surface-specific tools missed. Done badly, it produces quarterly slides naming intelligence sources the team read.

The build is six to twelve months at a sensible pace. The signal the build is working is not the hunt count, not the meeting volume, and not the tooling investment. It is the outcome mix on the monthly review, the conversion rate at the detection engineering handoff, and the coverage matrix readable from the live record. Programmes that do the structural work and let the cadence drive the record produce hunting capability that survives leadership change and audit fieldwork. Programmes that skip the structural work tend to rebuild after the first material incident or the first audit finding they cannot answer.

The next step is concrete. Name the lead. Pick the methodology. Draft the charter. Land the hunt backlog on a single workspace. Run the first two hunts end to end. The programme starts the moment the record starts.

Operate your hunting programme against one record rather than scattered analyst notebooks

SecPortal consolidates the hunt artefact, the engagement record, the findings the hunts produce, the activity log, the AI-drafted narrative, and the compliance crosswalk on one workspace. The cadence runs against the same record the audit committee reads.

Get Started Free See Findings Management

No credit card required. Free plan available forever.