I sat through a threat hunting proof of concept (PoC) last year where solution showed up on nine of the first twelve slides and analyst showed up on none of them. The pitch promised continuous hunting by senior hunters, with findings surfaced inside the console we already paid for. Around the pricing slide I asked the question I now open every one of these calls with: when a hunt turns up something ambiguous on a Saturday, who writes the ticket, and whose name is on it Monday morning?
The account executive looked at the solutions engineer, and the solutions engineer said the service would deliver findings with recommended remediations; everything upstream of that sentence was theirs. Everything downstream of it began with the alert triage and containment and included the detection rule that should have come out of the finding, and it was mine, none of it in the quote.
Solution is a marketing label, not a commitment: vendors use it to cover software, a managed service, or a methodology, without specifying which. Across the vendor materials I reviewed for this piece, responsibility boundaries varied and were often less specific than the hunting-activity descriptions themselves. A buyer's job on these calls is to find the exact sentence where the handoff happens and then price what sits on the far side of it.
In Brief:
- For procurement purposes, threat-hunting offers generally fall into three categories: self-service tools, managed services, and time-bounded assessments. Each has a different point where responsibility for the hunt, the follow-up, and the resulting detection returns to the customer.
- Provider materials often describe hunting cadence or continuous coverage, but buyers should confirm whether the SOW specifies hunt hours, named resources, minimum hunt volume, or a turnaround commitment from finding to detection rule; those commitments are rarely spelled out.
- Several hunting frameworks include operationalizing what a hunt finds, often by improving detection content, but valid outcomes can also include response actions, telemetry improvements, or a documented negative result. That operationalization step is inconsistently contracted for, and detection-engineering staffing constraints are widespread across the industry.
- One useful procurement question exposes a lot on any call: ask for a hunt-derived detection or analytic from a comparable engagement, who owns it now, and what you'd need to do to deploy and maintain it.
Solution is the label vendors use instead of tool, service, or methodology
For this comparison, threat hunting means a structured analyst-led search for malicious activity that isn't already resolved through routine alert handling. It's often guided by a hypothesis, per MITRE's TTP-based hunting methodology.
On a sales call that definition is nearly useless, because it never says whose analyst. Automated analytics and routine alert investigation are adjacent activities, not threat hunting. Retrospective searches for known indicators are IOC sweeps rather than hypothesis-driven hunting, though some programs fold them into a broader practice per the Hunting Maturity Model.
For procurement, that means mapping at least four responsibilities: hypothesis development, hunt execution, triage and follow-up, and operationalization, plus data onboarding, incident-response authority, and content ownership, with a named role behind each one.
Distinguish provider-led hunting included in MDR from any separately contracted customer-specific hunting by examining who sets priorities, develops hypotheses, and owns the resulting actions. When MDR material refers to provider output as "recommended actions," review the SOW and RACI to determine whether the provider also investigates, contains, or remediates. Verifying that scope before assuming the follow-up lands on your desk is the point.
Three packagings, three different handoff points
Vendor deliverables stop where my team's queue starts, based on the services and public materials I reviewed for this piece. Responsibility boundaries vary by product, tier, and contract, not merely by packaging category, and each one is defensible on its own terms.
The tooling vendor's story ends at the hypothesis
Self-service tools often make customer responsibility more visible because the customer operates the query and investigation workflow, but data, licensing, and managed-service add-ons can still affect the boundary. Microsoft Defender XDR Advanced Hunting provides a query-based interface for eligible Defender XDR data, with native hunting data generally queryable for up to 30 days and longer retention available through a connected Sentinel workspace.
As a self-service feature, it requires the customer to define hunting objectives and run the queries. Splunk's PEAK framework works similarly: its Prepare phase includes defining the hunt hypothesis, and the contract should specify who performs that phase. Elastic's and SentinelOne's published hunting material should be checked the same way, against the specific product edition and managed-service scope being evaluated, since neither vendor's self-service documentation assigns hypothesis-writing to anyone but the customer by default.
Responsibility can shift through several paths, not only a single managed-tier upgrade: professional services, co-managed operations, and partner engagements all move the line differently, so the exact offering is worth verifying rather than assumed. In the specific Microsoft managed-service proposal I evaluated, the provider took on hunting and investigation while real-time remediation stayed customer-controlled.
CrowdStrike's self-service platform content supports customer analysts, and its managed OverWatch service takes on more of the hunting work. But the current tier's responsibilities for notification, investigation, and remediation need confirming in the applicable SOW rather than assumed from the product name. Which hypotheses, priorities, and follow-up actions stay yours is a contract question, not a tier question.
The MDR-plus-hunting bundle's story ends at the follow-up
When I was managing an MDR provider for a cloud-native company with about a dozen people in SecOps, the monthly hunt report landed in a shared channel on the first of the month. It read well: methodology, findings, remediation recommendations, screenshots.
The recommendations became tickets in my queue alongside the escalations we were already working, and the SOW did not define a completion or verification service-level target for those customer-owned items. Expel's current MDR material points the same way: its reporting, hunt methodology, and remediation authority depend on service tier and configuration, and some remediation may run through optional automation or a hands-on workflow rather than waiting on customer sign-off by default.
Whether customer-specific hunting, emerging-threat coverage, and custom research are included, optional, or tier-limited is worth confirming rather than assuming from the marketing page.
The other service descriptions put the handoff in writing if you go looking for it:
- Confirm in Red Canary's current service description whether validated notifications, containment, and direct remediation are included or separately purchased.
- Confirm Sophos's responsibility matrix for containment and remediation, and treat case handling as a separate line of coverage from proactive hunting.
- Verify in Rapid7's higher-tier SOW which recovery tasks, including quarantine reversal and exclusion maintenance, remain customer responsibilities.
- CrowdStrike's OverWatch responsibilities vary by tier: confirm whether the selected one includes only notification or also managed alert response.
- Arctic Wolf buyers should use the SOW to identify who can authorize, execute, and verify each remediation step.
The consultancy's story ends when the engagement does
Many compromise and threat-hunting assessments are time- and scope-bounded, and that is how I read the service descriptions I reviewed. Duration, retention window, and follow-on support are the specifics to confirm in the engagement letter. Mandiant's, Secureworks', and Sophos's assessment materials should each be checked the same way: whether deliverables include a prioritized roadmap, a post-engagement report, or implementation support, and how endpoint volume and retention are sized in the current proposal.
A compromise assessment is typically a time- and scope-bounded investigation that evaluates whether evidence of compromise is present in the agreed data and review period; it can't prove the absence of compromise outside that scope.
In the public materials I reviewed from Mandiant, Unit 42, CrowdStrike, Secureworks, Kroll, Sophos, and Trustwave, the transferability of hypotheses, detections, and playbooks was not consistently specified, so buyers should require deliverables, IP rights, and handoff terms in writing. Some providers describe applying hunt learnings across their own customer base instead of handing them to you.
Others frame the assessment as complete once the organization understands how to improve its response, which is a deliverable, not a promise of continuing coverage. I use these engagements for a defensible yes-or-no for a board or an acquisition, documenting the assessment's data scope and residual uncertainty alongside the answer.
A time-bounded assessment doesn't create an ongoing hunting capability on its own: that depends on the knowledge transfer and implementation the engagement actually included, not on the report's existence.
What solution quietly assumes your SOC already has
Most threat-hunting offerings depend on agreed telemetry sources and data access, and many customers don't have it. Some vendors supply or manage portions of that telemetry, but buyers still have to validate coverage, quality, retention, and access before relying on the service, since data quality and quantity are recurring barriers alongside the persistent shortage of skilled staff.
Mandiant's M-Trends 2025 report found that the initial infection vector was undetermined in 34% of Mandiant investigations during 2024, a gap Mandiant associates with visibility limitations, including incomplete logging and detection, among other investigative constraints. Bianco's Hunting Maturity Model makes a related point: organizations that collect little IT data beyond what's needed for alerting are severely limited in their ability to proactively find threats. Outside expertise can't compensate for telemetry the organization never collected or retained.
The second assumption is that someone on your side turns findings into detections, though that responsibility can sit with the customer, the provider, or a shared team depending on the contract.
Several hunting methods, including the Sqrrl loop, PEAK's Act phase, TaHiTI, and MITRE's TTP-based approach, include a feedback phase where findings can improve analytics, monitoring, or future hunt priorities.
The staffing behind that step is thin industry-wide. In the 2025 SANS Detection Engineering Survey, 71% of responding organizations cited resource and time constraints as their primary obstacle, and 41% reported difficulty finding skilled detection-engineering personnel.
When hunting isn't connected to a documented engineering workflow, its findings may not consistently feed detection content or coverage analysis, and a hunt creates more durable value when its methods and outcomes are documented and reviewed.
The one question that exposes where the story ends
Ask every vendor the same thing: show me an anonymized hunt-derived analytic from a comparable engagement, tell me who owns it today, and show me the deployment evidence behind it.
A hunt-derived rule can demonstrate operationalization, but it isn't the only acceptable outcome; a validated negative finding, a telemetry improvement, or a documented risk decision are also legitimate results when a detection rule isn't the right output. The artifact's existence is objectively checkable, which makes the question a real test, though checking existence alone doesn't verify provenance, ownership, or effectiveness.
Self-service vendors may point to query libraries while leaving rule development to the customer, and an MDR may show fleet-wide content whose exportability after renewal is worth confirming in writing. Consultancy evidence often takes the form of a written report unless you've separately specified detections or implementation support as deliverables.
For governance purposes, each accepted follow-up action should have an accountable owner or a documented disposition, such as accepted risk, deferral, or rejection, before I consider an engagement closed.
I run this as three line-item checks on every hunting contract now, and I ask vendors for documented ownership evidence, a RACI, and contract acceptance criteria, rather than a general assurance that they hunt. On your next call this week, ask for the rule and its owner, then write whatever lands on the far side of that boundary into the SOW before you sign.
Frequently asked questions about threat hunting solutions
What's the difference between a threat hunting tool, service, and solution?
A self-service tool commonly provides query and analytics capabilities, sometimes with libraries or templates; unless managed services are included, the customer generally owns prioritization, triage, response, and any detection engineering. A managed hunting service may develop hypotheses, run hunts against agreed telemetry, and return findings through alerts, cases, tickets, or reports, with the SOW determining the provider's follow-on responsibilities. Solution is an imprecise umbrella term that covers both without committing to either, so the reliable way to classify what's being sold is to ask which party owns hypothesis development, execution, follow-up, and detection conversion.
Does a threat hunting solution replace an in-house hunt program?
In the offers reviewed for this article, customers retained some responsibilities under every packaging, though which ones varied by product, tier, and contract rather than by category alone. Self-service tooling requires access to personnel who can define and execute hunts. MDR bundles often return recommendations after hunting, though containment and detection-engineering responsibilities vary by tier, and a consultancy engagement is time-bounded but can leave lasting capability if knowledge transfer or implementation support was part of the scope. Whether customer-directed, environment-specific hunting is included, optional, or separately scoped is a contract question, so require the SOW to say who can request, design, and execute it.
What should a buyer own regardless of which vendor packaging they choose?
Buyers remain accountable for confirming telemetry coverage and retention even when a provider manages the data, and for establishing who can authorize response actions and who owns any hunt-derived detection content. Contract for an accountable hunt lead, a defined cadence, documented outputs, and a handoff into the appropriate engineering owner. Written commitments on those items distinguish a substantive hunting service from a notification-only offering.
How do you evaluate a threat hunting solution in a PoC?
Include handoff ownership in the PoC success criteria alongside telemetry coverage, hunt quality, and response authority, not just the console. Request documented hunt objectives before execution, then measure the time from a validated finding to a documented ticket with an accountable owner and, where appropriate, a detection change with a repository location. Evaluate a managed service in the context of its named hunting team and escalation process, not just the platform. One practical design pairs approved Atomic Red Team tests, mapped to MITRE ATT&CK, against an isolated test endpoint that represents relevant production controls, with safety and rollback procedures defined before testing starts.