The Hunt Documentation Standard

Why documentation is non-negotiable

You will be tempted to skip this. The queries are interesting. The analysis requires focus. Documenting each step feels like overhead. It is not overhead. It is output. Without documentation, five things are true:

The hunt cannot be repeated by another analyst (or by you, three months from now, when you have forgotten the details). The negative finding cannot be cited in a compliance audit. The detection rule produced lacks traceability to the evidence that justified its thresholds and exclusions. The organization cannot measure hunting program effectiveness. And the knowledge from the hunt dies with the analyst's memory.

The documentation standard does not require a formal report for every hunt. It requires structured notes, completable in 15 to 20 minutes across the hunt session, that capture the information needed for all five purposes. You fill in each section as you complete the corresponding Hunt Cycle step, not as a retrospective report after the hunt finishes.

Hunt record structure. Seven sections map to the six Hunt Cycle steps plus an administrative header. The record is completed incrementally during the hunt, not as a post-hunt report.

The seven sections

Section 1: Header. Administrative metadata. Hunt ID (format: TH-YYYY-NNN), analyst name, start date, completion date, and status (In Progress, Completed Confirmed, Completed Refuted, Completed Inconclusive). The ID enables cross-referencing between hunt records, detection rules, and IR cases.

Section 2: Hypothesis (from Step 1). The hypothesis statement with all four properties. The source category (ATT&CK gap, prior incident, TI report, environmental change, rule failure, or community research). The source reference (report URL, incident ID, technique ID). The ATT&CK technique mapping.

Section 3: Scope (from Step 2). Data sources and confirmation they are populated. Detection window and baseline window (if applicable). Population (full tenant or targeted, with exclusion rationale). Success criteria for both positive and negative findings.

Section 4: Collection (from Step 3). Record every query in the chain. For each query: step number, purpose (orientation, indicator, enrichment, or pivot), tables queried, result count, your assessment of whether the volume was expected, and the decision taken (narrow, pivot, escalate, or close).

Preserve the full KQL for every query by copying directly from Advanced Hunting. Do not summarize or paraphrase queries. A description like "searched for new IPs" is useless to the next analyst. The exact KQL is what makes the hunt reproducible. It is also what feeds the detection conversion in Section 1.6. If the analyst who reviews this record cannot copy the KQL into Advanced Hunting and get the same results, the documentation has failed its primary purpose.

Include null-result queries. A query that returned zero results proves you looked. Without it, a reviewer cannot tell whether you tested that aspect of the hypothesis or skipped it. NE's documentation standard requires at minimum the orientation query, the primary indicator query, and the enrichment query for every hunt. Pivot queries are included when the hunt produced a confirmed finding.

Section 5: Analysis (from Step 4). For each suspect result, record the enrichment across all five dimensions from Section 1.4: user context (role, travel history, access patterns), temporal context (time of day, correlation with phishing delivery), geographic context (IP location, ASN, VPN status), behavioral context (post-signin actions compared to baseline), and infrastructure context (IP reputation, user agent anomalies). Record the number of correlated dimensions and the confidence classification (High, Medium, Low).

This section documents reasoning, not just findings. "User signed in from Romania" is a finding. "User is a marketing coordinator with no admin roles, no documented travel, signed in at 02:47 local time from a residential proxy IP, followed by inbox rule creation within 90 minutes" is reasoning. A future reviewer reading the analysis section should understand not just what you decided, but why each decision was justified. When a confirmed finding goes to IR, the analysis section becomes the evidentiary foundation for the investigation.

Section 6: Conclusion (from Step 5). Record the outcome (Confirmed, Refuted, Inconclusive) with a finding summary of 2 to 3 sentences that a non-technical stakeholder can understand. For confirmed findings: the IR case number and containment actions taken. For refuted findings: what scope was examined and what constitutes the negative finding. For inconclusive findings: what gap prevented resolution and where the refined hypothesis sits in the backlog.

Write the conclusion to be self-contained. Someone reading only this section should understand what was found (or not found) without reading the collection or analysis details. Rachel Okafor reads conclusion sections across all quarterly hunts to assess program effectiveness. If the conclusion says "see analysis above," it fails its purpose.

Section 7: Detection Conversion (from Step 6). Whether a detection rule was produced. If yes: the rule name (HUNT-campaign-sequence: description), the Sentinel analytics rule ID, severity, ATT&CK mapping, deployment date, and 14-day validation status. If no: the reason (query too complex for scheduled execution, technique better suited for periodic hunting, data source insufficient for automated monitoring).

Include the exclusion list from your false positive analysis (Section 1.6). When a future analyst needs to tune the rule, they can trace back to this section, see which exclusions were applied and why, and make informed decisions about whether to add or remove them. Without this traceability, rule tuning becomes guesswork. With it, every tuning decision is grounded in the hunt data that produced the rule.

Worked example: abbreviated hunt record

This hunt took 6 hours of querying and analysis and 20 minutes of documentation. The output: a negative finding confirming no OAuth abuse in the last 90 days, plus a permanent detection rule monitoring for it going forward. Before this hunt, NE had zero visibility into malicious OAuth consent. After the hunt, NE has documented assurance and automated monitoring. That is the value of one structured hunt with proper documentation. Before this hunt, if someone asked "are we vulnerable to OAuth consent phishing," NE could only speculate. After this hunt, NE has a documented answer backed by 90 days of evidence, and automated monitoring that will alert on the first malicious consent going forward.

Making documentation sustainable

Incremental completion is the key. You fill in the hypothesis and scope sections before querying (5 minutes). You log each query and its results as you run them (30 seconds per query, since you are copying KQL you already wrote). You record the analysis reasoning as you examine each suspect result (1 minute per result). Conclusion and conversion sections are completed at the end (5 minutes). The total incremental cost is 15 to 20 minutes spread across a 4-to-8-hour hunt session.

Store hunt records in a location accessible to the team. NE uses a shared OneNote notebook with one page per hunt. Other organizations use SharePoint document libraries, Confluence spaces, or dedicated sections in their incident management platform. What matters is two requirements: the records must be searchable (so a peer reviewer or future analyst can find hunts by technique, date, or outcome) and they must be persistent (so they survive analyst turnover).

Searchability means tagging each hunt with its ATT&CK technique, its outcome, and the data sources it examined. When a new analyst joins NE's team and wants to understand what hunting has been done against credential access techniques, they can filter the hunt log by T1078 and T1110 and see every hunt Rachel and Tom have conducted, including the ones that found nothing. Over 12 months of consistent documentation, NE's hunt log becomes a detailed map of what has been examined, what was found, and where gaps remain. New hypotheses are immediately checked against the log to avoid duplicating prior work.

Using the HUNT- prefix naming convention links detection rules to their source hunts. This query tracks the tangible output of your hunting program over time:

// Hunt program output: detection rules produced from hunts
SecurityAlert
| where TimeGenerated > ago(180d)
| where ProviderName == "ASI Scheduled Alerts"
| where AlertName startswith "HUNT-"
| summarize
    AlertCount = count(),
    FirstFired = min(TimeGenerated),
    LastFired = max(TimeGenerated)
    by AlertName
| sort by FirstFired asc
// Each row = one detection rule produced by a hunt
// Count rows = hunt-derived detections in production
// Should grow by ~1 per month in a healthy program

Documentation as metrics fuel

Hunt records are the data source for every hunting program metric. Hunts conducted per quarter, hypotheses tested, findings confirmed, coverage gaps closed, and detection rules produced are all countable from a well-maintained hunt log. Without documentation, these metrics are estimates. With documentation, they are facts.

NE reports four metrics to Rachel Okafor quarterly: total hunts conducted, techniques tested (mapped to ATT&CK), findings (confirmed plus refuted plus inconclusive), and detection rules deployed. Each metric is a direct count from the hunt log. When Rachel asks "how many ATT&CK techniques do we have automated coverage for that we didn't have six months ago," the answer is the count of HUNT-prefixed analytics rules deployed in the period. No estimation required. When NE's annual security review asks whether the hunting program produces measurable value, the hunt log provides the evidence. Without it, hunting is an activity. With it, hunting is a measured, accountable security function.