Threat Hunting vs Incident Response: Triggers, Handoff and Evidence Handling

The most expensive moment in a threat hunt is the one where the hunter finds something real and nobody is sure whether it is still a hunt or already an incident. Hunting is proactive: it starts from a hypothesis and assumes no alert has fired. Incident response is reactive: it starts when an incident is declared and runs to a plan with authority to contain, notify and recover. The two share telemetry, tools and often people, so the line between them blurs exactly when it matters most. This guide compares them on triggers, authority, evidence standards and tooling, sets out escalation criteria for when a hunt becomes an incident, explains what changes in evidence handling at that point, and positions compromise assessments between the two. It is written for SOC and hunt leads, incident managers and CISOs who own both functions. The mechanics of each discipline are covered in the linked guides.

Key takeaways

• Short answer: threat hunting looks for compromise nobody has detected yet; incident response handles compromise that has been detected and declared. Hunting asks questions, incident response acts on answers.
• The trigger is the difference. A hunt starts from a hypothesis, intelligence or a baseline; incident response starts when adverse events meet the organisation's incident criteria, which NIST CSF 2.0 captures as DE.AE-08.
• Write the escalation criteria down. Hunters need a short list of findings that require immediate escalation, findings that need a second opinion first, and findings that stay in the hunt record.
• Evidence rules change at declaration. Hunt data is analytical; once an incident is declared, NIST SP 800-61 Rev. 3 treats collected incident data as evidence whose integrity and provenance must be preserved.
• Hunting continues after the hand-off. Hunters scope the intrusion for responders during the incident and test whether the adversary has returned after recovery.

The short answer

SURGe's PEAK framework defines hunting as any manual or machine-assisted process intended to find security incidents that automated detection has missed, and NIST SP 800-53 Rev. 5 control RA-10 Threat Hunting requires a capability to search for indicators of compromise and to detect, track and disrupt threats that evade existing controls. Incident response, as NIST SP 800-61 Rev. 3 (final, April 2025) frames it, is part of cyber security risk management organised around the CSF 2.0 functions, with the Respond function covering incident management, analysis, reporting and communication, and mitigation. SP 800-61 Rev. 3 itself names threat hunting as one way to identify threats, under ID.RA-03.

In practice: hunting is a research activity with no deadline other than its time box; incident response is an operational activity with a clock, a commander and legal consequences. The Threat Hunting Guide and the Incident Response Guide cover each in depth.

Side-by-side comparison

Threat hunting: proactive by design

Threat model. An adversary using valid accounts, built-in tools or techniques with no matching rule has already avoided automated detection. TaHiTI calls hunting the proactive search for signs of malicious activity, and treats it as largely intelligence-driven.

Operating model in words. A risk-ranked backlog, a testable hypothesis, a data check, exploration, and a written close. TaHiTI's finalise phase hands results to security incident response, security monitoring, threat intelligence and vulnerability management. A proven hypothesis, meaning malicious activity is found, starts incident response.

• Controls: read-only access to telemetry, a documented escalation path, a hunt record template, and queries that are quiet (they do not change endpoints or notify users).
• Where it breaks: a hunter keeps investigating a live intrusion alone because the hypothesis is "not proven yet", or quietly fixes what was found, which destroys evidence and leaves the incident undeclared.

Incident response: reactive by mandate

Threat model. Compromise is known or strongly suspected, and the aim is to limit harm. SP 800-61 Rev. 3 defines an incident as an occurrence that actually or imminently jeopardises, without lawful authority, the confidentiality, integrity or availability of information or an information system.

Operating model in words. Declaration against criteria, a named incident commander, analysis to establish what happened and the root cause (RS.AN-03), mitigation to prevent expansion, coordinated communication, recovery, and improvements fed back (ID.IM-03). See the NIST SP 800-61 Incident Response Guide.

• Controls: an incident response plan, severity matrix, playbooks, out-of-band communications, evidence preservation procedures and retainers.
• Where it breaks: responders contain the first host they are shown, before anyone knows the scope, and the adversary keeps the access they had elsewhere.

When does a hunt become an incident?

CSF 2.0 DE.AE-08 says incidents are declared when adverse events meet the defined incident criteria, and SP 800-61 Rev. 3 recommends applying those criteria to the known and assumed characteristics of analysed activity. Hunters should not decide declaration alone, but they must know when to stop and call it in. A tiered rule set works well:

Two details save time. First, agree that escalation from a hunt is never a failure of the hunt; it is the best outcome. Second, pre-agree which hunt topics are high risk enough (for example identity provider compromise or domain admin abuse) that a single confirmed indicator is escalated without further hunting.

The hand-off: what transfers and what the hunter does next

• What transfers: the hypothesis, every query and its time range, the entities found (accounts, hosts, IPs, applications), timestamps with time zone, what was ruled out, and the data gaps. TaHiTI's finalise outputs include the documented results and conclusions for security incident response.
• Who leads: the incident commander from the moment of declaration. The hunter becomes a scoping analyst under the incident structure, not a parallel investigator.
• Operational security: hunting queries are generally invisible to an adversary, but endpoint collections, account lockouts and user contact are not. Once an incident is suspected, any action the adversary could notice is the incident commander's decision.
• Scoping during the incident: responders need to know where else the behaviour occurs. Hunters run the same logic across the estate to find every affected identity and host before containment, so containment is done once, not repeatedly.
• After recovery: hunters test whether the adversary has returned, using the incident's techniques as hypotheses for the following weeks, and hand the proven logic to detection engineering. See Threat Hunting vs Detection Engineering.

Evidence handling: from hunt data to incident evidence

Hunt data is analytical: query results, exports and notebooks. It does not need chain of custody, but it may become evidence later, so treat it with discipline from the start. SP 800-61 Rev. 3, under RS.AN-07, says incident data and metadata are collected with integrity and provenance preserved, notes that collected incident data is still considered evidence even when chain of custody procedures are not used for every incident, and recommends retention in line with the organisation's evidence preservation procedures.

• During the hunt: keep queries and results in a controlled repository, record UTC timestamps, and never alter source systems. Export result sets that support a finding and hash them.
• At declaration: freeze the hunt workspace, export bookmarks or result sets with the producing queries, and give the incident team a list of the systems and logs touched.
• Volatile data first: RFC 3227 (BCP 55) sets the order of volatility, from registers, cache and memory through temporary file systems and disk to remote logs and archival media, and advises collecting before analysing and minimising changes. Hunters should not reboot, scan or "clean" hosts they have found.
• Log retention: place a hold on relevant log sources so short default retention does not overwrite the evidence window the hunt relied on.
• Chain of custody: once evidence may be used by a regulator, insurer or court, record who collected what, when, where it was stored and each transfer, as RFC 3227 describes. See the Evidence Handling and Chain of Custody Guide.

Shared tooling, different use

Both functions use the same platforms. What changes is the mode of use. Tools are listed alphabetically as examples of documented features, not recommendations.

The value of a shared platform is continuity: a hunt finding escalated as an incident keeps its query, entities and mappings rather than being retyped. Agree in advance which fields must transfer. Endpoint collection at scale produces large volumes quickly (Velociraptor's documentation gives the example that a 100 MB file collected from 10,000 machines would need over 1 TB), so prefer targeted artefacts during both hunting and response.

Where compromise assessments sit

A compromise assessment is a time-bound, scoped engagement to answer "are we compromised now?" across an estate, often commissioned before an acquisition, after a peer is breached or when leadership needs assurance. It uses hunting methods but has an assurance purpose and a report for leadership. It is broader than one hunt and narrower than a standing programme, and like a hunt it escalates into incident response the moment it confirms active compromise. See the Compromise Assessment Guide.

• Choose a hunt to test a specific technique or data source as part of a continuous programme.
• Choose a compromise assessment when a decision depends on a defensible statement about the whole estate at a point in time.
• Choose incident response when the incident criteria are met; do not commission an assessment to avoid declaring.

Worked scenario

A hunter tests whether service accounts are being used interactively. One account shows a remote interactive logon to a file server from a workstation in finance, followed by an archive file created in a user-writable path. No alert fired. The finding matches the "strongly suspicious" tier, so a senior analyst reviews it within the hour and agrees it has no business explanation. The incident manager declares a suspected incident at medium severity.

The hunter freezes the hunt workspace, exports the result set with its query and hashes, and hands over the timeline. Under the incident commander's direction the hunter then runs the same logic estate-wide and finds the account used on two more servers. Responders capture memory from the finance workstation before isolating it, rotate the service account credential and remove its interactive logon right. After recovery, the hunt team adds the account's behaviour to a recurring hunt for six weeks, and the logic goes to detection engineering as a candidate rule. The incident's post-incident review records that the hunt shortened detection by an unknown but real margin, and that service account interactive logon rights should be reviewed estate-wide. See the Identity Incident Response Playbook.

Organising the two functions

• Small organisations: the same analysts hunt and respond. Write the escalation tiers anyway, because the conflict of interest (finishing the hunt versus declaring) is greatest when one person holds both roles. Use a retainer for surge response; see the Incident Response Retainer Buyer's Guide.
• Mid-sized: a SOC with hunting on rotation and an incident manager on call. Hunters are named in the incident response plan as scoping support.
• Large: separate hunt and incident teams with shared tooling, a joint escalation runbook and hunters in the incident response RACI. Use post-incident reviews to seed the hunt backlog.
• Outsourced hunting: the contract must state escalation timeframes, who declares, how evidence is preserved and who may take containment actions.

Implementing the hand-off

1. Agree incident criteria and escalation tiers with the incident manager, legal and the hunt lead, and add them to the incident response plan and the hunt record template.
2. Name the channel: one route (on-call phone, case queue with paging) used for every escalation from a hunt, with an acknowledgement time.
3. Define the hand-off record: the fields that must transfer, and the freeze and export steps for the hunt workspace.
4. Exercise it: include a hunt-originated scenario in the next tabletop exercise; test that hunters know when to stop and that responders accept the hunt record without re-collection.
5. Review after every escalation: was the tier right, how long did declaration take, what data was missing. Adjust the tiers, and roll back any tier that produced false escalations by moving the finding type down one level with the reason recorded.

Measuring the interface

• Time from hunt finding to declaration decision: the core hand-off metric.
• Incidents originating from hunts and the dwell time of each (TaHiTI lists both), read as context, not as a hunter target.
• Escalations later judged benign: a small, stable number shows the tiers are calibrated.
• Hunt records accepted by responders without re-collection: a test of evidence discipline.
• Post-incident hunts completed: recurrence checks run after each significant incident.

Framework mapping

Common failure patterns

• The hunter who keeps going: a live intrusion is investigated for days inside a hunt because nobody wants to declare too early. Fix with written tiers and a time limit on the "strongly suspicious" tier.
• Quiet remediation: a hunter disables an account or deletes a file, which tips off the adversary, destroys evidence and leaves no incident record.
• Re-collection from scratch: responders cannot use the hunt's data because queries, time zones and exports were not recorded, so hours are lost rebuilding the picture.
• Hunting stops during incidents: hunters are pulled into the incident queue and the programme pauses for months. Name hunters as scoping support with a defined end point.
• No recurrence hunting: the incident closes and nobody tests whether the adversary returned.
• Assessments used to avoid declaring: a compromise assessment is commissioned when the incident criteria were already met, delaying containment and notification.

Practitioner checklist

• Write incident criteria and hunt escalation tiers into both the incident response plan and the hunt template.
• Give hunters one escalation channel with an acknowledgement time.
• Pre-agree which hunt topics escalate on a single confirmed indicator.
• Keep hunt queries, results and UTC timestamps in a controlled repository from the first query.
• Freeze and export the hunt workspace at declaration and place holds on relevant logs.
• Name hunters as scoping support in the incident response RACI, under the incident commander.
• Run recurrence hunts on each significant incident's techniques after recovery.
• Include a hunt-originated scenario in tabletop exercises.

Standards and references

• NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• IETF: RFC 3227 Guidelines for Evidence Collection and Archiving
• FI-ISAC NL / Betaalvereniging: TaHiTI Threat Hunting Methodology
• Splunk SURGe: Introducing the PEAK Threat Hunting Framework
• Splunk SURGe: PEAK Threat Hunting Metrics
• Microsoft Learn: Threat hunting in Microsoft Sentinel
• Velociraptor: Hunting

Related NHI Mgmt Group resources: Threat Hunting vs Detection Engineering · Compromise Assessment Guide · Threat Hunter Career Guide · Incident Response vs Digital Forensics · Threat Hunt Hypothesis and Report Template