In this section
TH0.8 Organizational Readiness for Hunting
Section 0.7 built the financial case: a $33,000 annual hunting program that produces permanent detection rules, compresses dwell time, and pays for itself the first time it catches one intrusion early. You can present the ROI argument. But ROI assumes the program can execute. Not every SOC is ready to hunt. This section defines five prerequisites, provides the queries to assess each one in your own environment, and identifies exactly what to fix first if you're not ready yet.
Scenario
Rachel Okafor has Phil's budget approval. She assigns Tom Ashworth to run Northgate Engineering's first hunt campaign — an OAuth consent abuse sweep across the last 90 days. Tom opens Sentinel, writes a CloudAppEvents query to find consent grants to unfamiliar applications, and gets zero results. Not because OAuth abuse hasn't occurred. Because CloudAppEvents isn't ingested. Tom's hunt fails before it begins. The hypothesis was sound. The analyst was capable. The data wasn't there. The next two weeks go to enabling the data connector, verifying ingestion, and waiting for retention to build. The hunt that should have started Monday starts in three weeks.
Prerequisites are not optional
Hunting is a capability that builds on other capabilities. It is the thing you deploy after your detection foundation is solid enough that hunting can extend it rather than duplicate it. An organization that can't triage alerts effectively should not hunt — the hours are better spent fixing alert triage. An organization that doesn't ingest the data sources hunting requires should not hunt — the queries will return empty results. An organization without an IR process should not hunt — because when hunting finds a compromise, the finding needs to go somewhere.
This is sequencing, not gatekeeping. The five prerequisites below are achievable by any M365 security operation that has been running for 6–12 months. If yours is newer, the KQL for Security and SOC Operations courses on this platform build the foundations this course requires. Assess honestly. A readiness gap identified now saves weeks of wasted effort later.
Prerequisite 1 — Sufficient data ingestion
Hunting queries data. If the data is not in your SIEM, the hunt cannot find anything. The minimum data sources for the hunt campaigns in this course fall into three tiers.
Required tables with no workaround: SigninLogs (every authentication hunt in TH4 references this table — without it, your identity visibility is zero), AADNonInteractiveUserSignInLogs (AiTM token replay detection, service principal monitoring, and privilege escalation investigation depend on non-interactive sign-in records that SigninLogs alone doesn't capture), AuditLogs (directory changes, application consent grants, conditional access modification monitoring), CloudAppEvents (email manipulation, file access, and application API abuse campaigns), and SecurityAlert (the ATT&CK coverage analysis in TH3 and several campaign modules correlate hunting findings with existing alert data).
Required for endpoint campaigns: DeviceProcessEvents, DeviceFileEvents, DeviceRegistryEvents, DeviceNetworkEvents, and DeviceLogonEvents — Defender for Endpoint telemetry that the endpoint threats hunt (TH9), lateral movement hunt (TH10), and pre-ransomware activity hunt (TH12) require.
Valuable but not blocking: AADServicePrincipalSignInLogs enriches the privilege escalation hunt in TH6. IdentityLogonEvents and IdentityDirectoryEvents from Defender for Identity enrich TH10 (lateral movement) and TH7 (email threats). MicrosoftGraphActivityLogs, if available, adds API-level visibility to TH5 and TH6.
Run this in your Sentinel workspace. The output is your data inventory. Compare it against the required tables above. Every missing table is a hunting blind spot — a domain where hunt campaigns will return empty results regardless of how well the hypothesis is constructed or how skilled the analyst is.
Prerequisite 2 — Baseline detection rules
Hunting fills the gaps between detection rules. If there are no rules, there is no gap to define — there is just a void. You need enough rules to establish a functioning alert and incident pipeline so that when hunting discovers a compromise and escalates it to IR, the IR process can handle it. You also need enough rules that the ATT&CK coverage analysis in TH3 produces a meaningful heatmap rather than a blank grid.
A practical threshold: if your Sentinel workspace has fewer than 20 active analytics rules, prioritize detection engineering before hunting. The SOC Operations course provides the detection rule library and deployment methodology. Twenty or more rules with ATT&CK technique mappings give you enough of a detection foundation that hunting can productively identify and fill the gaps between them.
The CardinalOps 2025 report found that organizations are ingesting enough data to cover 90% of ATT&CK techniques on average, but their SIEM rules cover only 21%. The gap between available data and deployed rules is precisely the space where hunting operates. If your available data covers 90% but your rules cover 21%, you have a 69-percentage-point surface area for hunting to explore. If your data covers 30% because you haven't enabled connectors, hunting has a 9-point surface at best. Fix data ingestion first. Then fix rule coverage. Then hunt the remaining gap.
This count tells you how many distinct analytics rules have fired in the last 90 days. Rules that exist but haven't fired may still be active — check the Sentinel Analytics blade directly for the full active rule count. The CardinalOps data found 13% of production SIEM rules are completely broken and will never fire. Count active rules, not deployed rules.
Prerequisite 3 — KQL proficiency
Every hunt campaign in this course is built on KQL queries. Not basic queries — aggregations, joins, time-series functions, let statements, and multi-table correlation. If the analyst running the hunt can't modify a KQL query to adapt it to their environment's naming conventions, filter for their tenant's specific service principals, or adjust time windows based on their retention, the hunt degrades to copying and pasting a query and hoping it works. That is automated scanning, not hunting.
The minimum KQL skill set for productive hunting: writing join operations between SigninLogs and AuditLogs, using summarize with make_set and dcount for behavioral aggregation, constructing let statements to parameterize queries for reuse, applying series_decompose_anomalies or percentile for statistical baselining, and building cross-table correlation queries that pivot from an identity finding to endpoint activity to cloud application behavior.
If these operations are unfamiliar, complete the KQL for Security Operations course as a parallel track. Hunting without KQL fluency constrains the hunter to pre-built queries. Pre-built queries test pre-built hypotheses. The value of hunting is testing hypotheses specific to your environment, which requires queries written for your environment.
Prerequisite 4 — Incident response process
When hunting finds a compromised account — and it will, eventually — the finding needs to go somewhere. Without a defined IR process, the hunter escalates the finding and it sits. Session tokens continue to be replayed. Persistence mechanisms remain active. Data exfiltration continues. The hunt found the compromise, which is the hard part. The containment should be the easy part. It is only easy if the process exists before the finding.
The minimum IR process for hunting support: a defined escalation path (who gets notified when a hunt produces a true positive), documented containment actions (session revocation, password reset, conditional access block, application consent revocation), and a documentation standard (incident comment format, evidence preservation, handoff to IR for full investigation). If your SOC has an informal process — "we'd figure it out" — that is acceptable for initial hunts. If no process exists at all, address that gap first. The Incident Response course on this platform teaches the complete framework.
Prerequisite 5 — Protected time
This is the prerequisite that kills most hunting programs before they start. Protected time means hours explicitly allocated to hunting, removed from the alert queue, uninterrupted by triage requests. Four hours per week is the minimum viable allocation. Eight hours per week enables one full campaign per month with documentation time.
The failure mode is universal: leadership approves the hunting program, the analyst opens Sentinel on Monday morning, an alert fires, the analyst triages it, two more fire, and by noon the hunting time has evaporated. This happens every week until hunting is quietly abandoned. The alert queue always has work. The hunting backlog never screams. Without structural protection, urgent always consumes important.
Protected time requires organizational commitment, not just individual discipline. The SOC lead must actively defend the hunting allocation. Alerts that arrive during hunting hours go to another analyst. If staffing doesn't allow that rotation, the hunting hours move to a day when the second analyst is available. The schedule is non-negotiable the same way an on-call rotation is non-negotiable.
Figure TH0.8 — Hunting readiness prerequisites. All five must be met for hunting to produce actionable results. Gaps in any prerequisite should be addressed before investing analyst hours in hunt campaigns.
The maturity sequence
Where does hunting fit in the SOC maturity journey? After detection engineering, before continuous monitoring. The progression is predictable across organizations of all sizes.
Stage 1 is alert triage. Alerts fire, analysts triage them. The SOC is reactive. Most organizations start here and some never leave. Prerequisites 4 (IR process) and 5 (protected time) are typically the gaps — the SOC is consumed by alert volume with no capacity for proactive work.
Stage 2 is detection engineering. The SOC begins building custom analytics rules to close coverage gaps. Alert quality improves. False positive rates decrease. The team can articulate what they detect and what they don't. Prerequisites 1 through 3 are typically met at this stage. The 21% ATT&CK coverage figure from CardinalOps represents the average organization at this stage — building rules, but unable to close the gap through rule-writing alone.
Stage 3 is proactive hunting. The detection foundation is solid. The SOC has capacity, even if limited, for proactive work. Hunting begins as structured campaigns against a prioritized backlog of hypotheses. This course teaches this stage. Each campaign produces a detection rule, closing the gap incrementally while building the environmental understanding that detection engineering alone can't provide.
Stage 4 is continuous monitoring. Hunt campaigns that proved their value are automated as scheduled queries. UEBA baselines run continuously. The SOC operates across all three layers of the detection pyramid simultaneously. TH16 (Scaling Hunts) teaches the automation and scheduling that enables this stage.
If your SOC is at Stage 1, this course is not your next step. KQL for Security and SOC Operations build the foundation. If your SOC is at Stage 2 — detection engineering is active, alert quality is improving, and you can protect analyst hours — you are ready.
The minimum viable hunting program
Most organizations that hunt effectively don't have dedicated hunting teams. They have SOC analysts who spend protected hours on hunting as part of a rotation. One analyst per week on "hunt duty" while the others handle the alert queue. The minimum viable program is one analyst, 4 hours per week, with a prioritized backlog of hypotheses derived from the ATT&CK coverage gap analysis in TH3.
That single analyst, with that allocation, can execute one hunt campaign per month from this course. Twelve campaigns per year. Twelve detection rules produced. Measurable coverage improvement. The staffing question is not "can we hire a threat hunter?" The question is "can we protect 4 hours per week for one existing analyst?" Almost every SOC with two or more analysts can do this with a rotation adjustment. The ISC2 2025 Cybersecurity Workforce Study found that 88% of organizations experienced at least one significant security event due to skills deficiencies — but hunting doesn't require a new hire. It requires structural protection of existing capacity.
The organization approves the hunting concept but defers execution until they can hire a dedicated threat hunter — a role with a specialized job description, a higher salary band, and a recruitment timeline measured in months. Meanwhile, two SOC analysts with solid KQL skills sit on the alert queue eight hours a day, processing alerts against the same 21% coverage baseline. Four protected hours per week from either analyst would produce 12 hunt campaigns per year. Instead, those campaigns don't run for 6-12 months while HR recruits. The gap doesn't close. The techniques in the known-unknown layer remain unexamined. The hire, when they arrive, still needs to learn the environment before they can hunt effectively. The existing analysts already know the environment. They're ready now. They just need the time.
Threat Hunting Principle
Readiness is a prerequisite assessment, not a maturity gate. Five conditions must be true before hunting adds value: the data exists in Sentinel, enough detection rules exist to define the gap, the analyst can write and adapt KQL, an IR process can act on findings, and protected hours are structurally defended from the alert queue. Assess each one honestly. Fix gaps in order. Don't hunt into a void — and don't wait for perfection before starting.