Threat Hunt Hypothesis Backlog Template: Score and Track

Hunt teams rarely run out of ideas; they run out of a way to choose between them, so hunts follow whoever read the latest report and good hypotheses are forgotten in a chat thread. A hypothesis backlog is the queue that fixes this: one row per candidate hunt, with the behaviour, the ATT&CK technique, the data needed, a priority score and a status, reviewed on a fixed cadence. This template gives you the backlog columns, an intake rule for each trigger, a scoring model, a status lifecycle and example rows. Each row that is selected becomes a full record in the Threat Hunt Hypothesis and Report Template, and its outcome comes back to the backlog when the hunt closes. It is written for hunt leads, SOC managers and detection engineers; for the discipline itself, see the Threat Hunting Guide.

How to use this template

Placeholders: replace text in square brackets, such as [Hunt Lead], [monthly] and [HB-NNN], with your own names and values.
Where to keep it: a ticket system, a shared spreadsheet or a repository file all work. The TaHiTI methodology, published by the Dutch banking community, notes that a simple tool such as SharePoint or JIRA is enough, provided it lets the team see which item is most relevant next.
One row, one behaviour: a backlog row holds a draft hypothesis, not a full hunt plan. Refinement, queries and findings belong in the hunt record once the row is selected.
Nothing is deleted: closed rows stay in the backlog with their outcome, so the team can see what was covered, when, and over which data.
Method neutral: the columns support both PEAK (Prepare, Execute, Act with Knowledge, from SURGe by Splunk) and TaHiTI (Initiate, Hunt, Finalize). Section 7 maps them.

1. Purpose and scope

This backlog records every candidate threat hunt for [Organisation], ranks them by risk, and tracks each from intake to outcome.
It covers hypothesis-driven, baseline and model-assisted hunts across [endpoint, identity, cloud, SaaS, network and OT] data. For baseline hunts the "hypothesis" column holds the question about normal behaviour instead.
It supports the threat hunting capability required by [Organisation]'s [Security Operations Standard] and NIST SP 800-53 Rev. 5 control RA-10 Threat Hunting.

2. Backlog columns

Use these columns as your backlog header. Mandatory columns are needed to accept a row; the rest are completed during review or selection.

Column	What to enter	Required at intake?
ID	[HB-NNN], never reused	Yes
Date added / added by	Date and name	Yes
Trigger	Source of the idea with a reference: intelligence report URL, incident ticket, red team finding, coverage gap ID (see section 3)	Yes
Hypothesis	One testable sentence naming a behaviour, where it would happen and what would show it	Yes (draft)
Hunt type	Hypothesis-driven, baseline or model-assisted	Yes
ATT&CK ID	One or two technique or sub-technique IDs, for example T1098.001	Yes
Actor (optional)	Named group or actor type, only from intelligence the team trusts	No
Location	Tenant, subscription, segment or host group where the behaviour would appear	Yes
Data source	Log sources and fields needed, for example "Entra ID audit log, application credential changes"	Yes
Data available?	Yes / partial / no, with retention in days. "No" rows go to the data gap list (section 5.3)	At review
Existing detection	Rule or analytic IDs already covering the behaviour, or "none"	At review
Priority score	From section 4	At review
Effort	Estimate in hunter days	At review
Status	From section 5	Yes
Owner	Hunter assigned when selected	At selection
Hunt record	Link to the hunt record, [HUNT-YYYY-NNN]	At selection
Last executed	Date the hunt last ran, to schedule re-runs	At closure
Outcome	Proven, disproven or inconclusive, with a one-line result	At closure
Follow-up	Detection ticket, incident ID, data gap ticket, new backlog rows	At closure

The core intake fields follow TaHiTI's investigation abstract, which holds a date, an initial hypothesis, a trigger with references and a hunt priority. The behaviour, location and evidence columns follow PEAK's ABLE method (Actor, Behaviour, Location, Evidence), in which the actor is optional and the behaviour should be one or two techniques, not a whole kill chain.

3. Intake and triggers

Anyone in [security operations, threat intelligence, incident response, red team or detection engineering] may add a row. The [Hunt Lead] accepts or returns it at the next review.
A row must cite its trigger. Accepted triggers are listed below. Atomic indicators alone (hashes, IP addresses, domains) go to indicator matching in the SIEM, not to the hunt backlog.

Trigger	Example	What to record
Threat intelligence on TTPs	A government advisory describes an intrusion set adding credentials to cloud applications	Report reference, techniques, sector relevance
Incident response	An incident closed without a confirmed root cause or initial access route	Incident ID, open questions
Red team or penetration test	Testers moved laterally without raising an alert	Report reference, techniques used
Detection coverage gap	An ATT&CK coverage review shows no analytic for a technique relevant to the environment	Technique ID, coverage review reference
Previous hunt	A hunt surfaced a related behaviour outside its scope	Parent hunt record
Environment change	New SaaS platform, merger, new log source	Change reference, crown jewels affected
Hunter expertise	An analyst knows an abuse pattern for a platform the team runs	Short rationale

These trigger types follow TaHiTI, which treats intelligence on TTPs as the main source and also lists security monitoring gaps, unresolved incidents, red teaming, earlier hunts, crown jewel analysis and MITRE ATT&CK.

4. Prioritisation

Score each accepted row at review. TaHiTI recommends ranking by threat level first, with active campaigns and actors targeting your sector much higher, then adjusting for existing detection and prevention. The scoring model below puts that into numbers; change the weights to suit your risk appetite.

Factor	1	2	3
Threat relevance (x3)	Generic technique, no sector reporting	Reported against peers or the region	Active campaign against the sector or [Organisation]
Asset impact (x2)	Low-value systems	Business systems	Crown jewels, identity providers, privileged or non-human identities with broad access
Detection gap (x2)	Tested analytic exists	Partial or untested analytic	No analytic
Data readiness (x1)	Data missing	Partial or short retention	Data available for the full look-back

Priority score = (threat x 3) + (impact x 2) + (gap x 2) + (data x 1). The maximum is 24.
Rows scoring [18 or more] are P1 and should start within [two weeks]. Rows scoring [12 to 17] are P2 and enter the next planning cycle. Lower rows are P3 and are reviewed each cycle.
A row with data readiness 1 cannot be selected until the data gap is closed; it stays visible so the gap is funded.
The [Hunt Lead] may override a score with a written reason, for example a request from the CISO after a peer incident.

5. Status lifecycle

Status	Meaning	Exit condition
New	Added, not yet reviewed	Accepted, merged with a duplicate, or rejected at review
Ready	Scored, data available, waiting for capacity	Selected in planning
Blocked: data	Needed data is not collected or retained long enough	Data gap ticket closed
In progress	Hunt record open, owner assigned	Hunt record closed with an outcome
Closed	Outcome recorded	Re-run date reached, then back to Ready
Rejected	Out of scope, duplicate or not testable	Reason recorded

5.1 Outcomes

Proven: the behaviour was found. The incident response process is invoked at once, without waiting for the hunt report, and the incident ID is recorded in the row.
Disproven: the behaviour was not found in the stated data and period. Record what was checked and any detection or hardening improvement identified.
Inconclusive: data or analysis could not answer the question. Record why, refine the hypothesis or data, and return the row to Ready or Blocked.

These outcomes follow TaHiTI's validation results; a disproven hunt still has value when it confirms coverage or finds a gap.

5.2 Re-runs

Closed rows with no automated detection created should be re-run [every 6 to 12 months] or when their trigger recurs. Rows converted into a tested detection need not be re-run.

5.3 Data gap list

Rows blocked on data are summarised for [the logging or platform owner] each cycle, with the hunts each gap blocks, so collection is prioritised by hunting value.

6. Example backlog rows

Example rows for a mixed Microsoft and multi-cloud estate. ATT&CK v20 detection strategy IDs are shown where they help the hunter find MITRE's analytic guidance.

ID	Hypothesis	ATT&CK ID	Data source	Priority	Status	Outcome
HB-014	An attacker has added a secret or certificate to an existing application registration to keep access after password resets	T1098.001 (DET0531)	Identity provider audit log; service principal sign-in logs	22 (P1)	In progress	[pending]
HB-019	A non-domain-controller host has requested directory replication from a domain controller	T1003.006 (DET0594)	Domain controller security event logs; network flow between DCs and other hosts	20 (P1)	Ready	[pending]
HB-022	Inbox rules forward mail from finance mailboxes to external domains	T1114.003 (DET0576)	Mailbox audit records; mail flow logs	17 (P2)	Closed	Disproven over 90 days; detection rule created
HB-025	Users are approving repeated MFA prompts they did not initiate	T1621 (DET0160)	Identity provider sign-in logs with MFA detail	18 (P1)	Closed	Proven on one account; incident raised
HB-031	Internet-facing web servers spawn command shells from the web server process	T1505.003 (DET0394)	EDR process telemetry on web tier	15 (P2)	Blocked: data	EDR not deployed on [DMZ hosts]
HB-034	Data from file servers is uploaded to personal cloud storage services	T1567.002 (DET0570)	Proxy or secure web gateway logs; endpoint network events	13 (P2)	Ready	[pending]
HB-037	Baseline: which service accounts authenticate interactively, from where and how often	T1078 context	Directory authentication logs, 30 days	14 (P2)	New	[pending]

Identity rows, including those on service accounts, tokens and application credentials, usually score high on impact. The Identity Threat Hunting Guide has more hypotheses for that area.

7. Hand-off to the hunt record

Backlog column	Hunt record section	PEAK step	TaHiTI step
Trigger, hypothesis, ATT&CK ID, location	1. Scope and triggers	Select Topic, Research Topic, Generate Hypothesis, Scope Hunt	Initiate; Define / refine
Owner, effort	2. Roles and contacts	Plan	Define / refine
Data source, data available	3. Detection and triage	Gather Data, Pre-Process Data, Analyze	Execute
Outcome, follow-up	Act sections and closure	Document Findings, Create Detections, Communicate Findings	Finalize
Status, last executed, new rows	Back to backlog	Re-Add Topic to Backlog	Update the hunting backlog

When a row is selected, the owner opens a hunt record and copies the backlog columns into it. The hypothesis may be refined in the record; the backlog row is updated to match.
New ideas found during a hunt are added as new rows with the parent hunt as trigger, not pursued inside the current hunt. PEAK advises noting new avenues while keeping focus on the current hunt.
When the record closes, the owner updates status, outcome, last executed and follow-up in the backlog within [two working days].

8. Review and roles

The [Hunt Lead] runs a backlog review [every two weeks / monthly] with [threat intelligence, detection engineering and an incident response representative] to accept new rows, rescore and select the next hunts.
All Ready rows are rescored at least [quarterly], because threat relevance and detection coverage change.
The [SOC Manager] reports backlog metrics to [the security leadership team] [quarterly].

Role	Backlog duties
[Hunt Lead]	Owns the backlog; accepts and rejects rows; runs reviews; approves score overrides
Hunters	Add rows; run selected hunts; update rows at closure
Threat intelligence	Adds TTP-based rows; scores threat relevance
Detection engineering	Confirms existing detection coverage; takes detection follow-ups
Logging or platform owner	Confirms data availability; closes data gaps
Incident response	Adds rows from unresolved incidents; receives proven findings

Implementation guidance

Seed the backlog. Collect hunt ideas from the last [6 months] of intelligence reports, incident reviews and red team findings, and a coverage review against ATT&CK techniques relevant to your platforms. Twenty to forty well-formed rows is a workable start.
Test hypotheses at intake. Reject rows that name a topic ("look for exfiltration") or an actor only. Return them with a request for a behaviour, location and data source.
Check data before scoring. Ask the platform owner to confirm each data source and its retention. This step alone often produces the most useful output of the first cycle: a ranked list of logging gaps.
Run two cycles, then calibrate. After two review cycles, compare scores with what the hunts found and adjust weights. Keep the old scores in the row history.
Connect follow-ups. Link detection tickets in the detection engineering backlog (see the Detection Engineering Guide) and incident IDs in the case system, so outcomes can be counted.

Metrics to report

Backlog health: rows by status and priority; P1 rows waiting more than [two weeks].
Throughput: hunts closed per quarter and median time from selection to closure.
Outcome mix: share of proven, disproven and inconclusive hunts. A high inconclusive rate usually points to data gaps.
Conversion: percentage of closed hunts that produced a new or improved detection.
Data gaps: number of rows blocked on data and the age of the oldest.
Coverage: number of distinct ATT&CK techniques hunted in the last 12 months against those judged relevant.

Common backlog mistakes

Topics, not hypotheses: rows such as "check for compromised accounts" cannot be scored or closed. Enforce the hypothesis column at intake.
Indicator dumping: loading every IP address and hash from a report into the backlog. TaHiTI starts hunts from TTP-level intelligence; indicators belong in automated matching.
Losing negative results: deleting disproven rows means the same ground is hunted again. Keep them, with the data and period checked.
Ignoring data readiness: selecting hunts whose data does not exist wastes hunter time and ends inconclusive. Block them and escalate the gap instead.
Never rescoring: a row scored during a past campaign can sit at P1 long after detection was built. Rescore quarterly.
Proven findings waiting for the report: a proven hypothesis is an incident. Escalate at once, as both PEAK (Escalate Critical Findings) and the report template require.

Framework mapping

Framework	Requirement	Template sections
NIST SP 800-53 Rev. 5	RA-10 Threat Hunting (search for indicators of compromise; detect, track and disrupt threats that evade existing controls; run at a defined frequency); SI-4 System Monitoring; CA-7 Continuous Monitoring	1, 4, 5.2, 8
NIST CSF 2.0	ID.RA-03 internal and external threats identified and recorded; DE.AE-02 adverse events analysed; DE.AE-07 threat intelligence integrated into analysis; ID.IM-02 improvements identified from tests and exercises	3, 4, 5, 7
MITRE ATT&CK v20	Technique IDs and detection strategies (DET IDs) as the shared language for hypotheses and coverage	2, 6, metrics
TaHiTI and PEAK	Investigation abstract and backlog; ABLE; Re-Add Topic to Backlog	2, 3, 5, 7

Threat Hunt Hypothesis Backlog Template: Hypotheses, Data and Priority