A threat hunting maturity score can tell you whether your team has developed a disciplined hunting practice.
It cannot tell you which adversary techniques you are equipped to find.
That leaves a sizable hole in board reporting.
The 2025 Verizon Data Breach Investigations Report found that credential abuse accounted for 22% of breaches, with vulnerability exploitation close behind at 20%.
Security leaders facing that range of initial access need to understand what happens after an attacker gets in: which behaviors their teams can find, where coverage is thin.
Key takeaways of threat hunting reporting to the board
- Threat hunting maturity is not the same as threat coverage. A high maturity score can show that a SOC has strong processes, skills, and automation without revealing which adversary techniques it can actually detect.
- Hunt volume is an activity metric, not a coverage metric. Reporting that a team completed 40 hunts says little about whether those hunts addressed the threats most relevant to the organization.
- ATT&CK coverage gives boards a more meaningful measure. SOCs should track validated hunting and detection coverage against the MITRE ATT&CK techniques that matter most to their threat profile.
- Successful hunts should become durable detections. Measuring the percentage of validated hunts converted into permanent detection logic shows whether hunting is producing lasting defensive improvements.
- Maturity scores still have value, but they need context. Pair maturity with ATT&CK technique coverage, hunt-to-detection conversion, and time from hypothesis to recurring hunt to give leadership a clearer picture of defensive capability.
Why threat hunting maturity became the standard
There’s no doubt that threat hunting maturity models address a problem.
When David Bianco developed the Hunting Maturity Model, many security teams had little formal hunting capability.
The model described five levels, from HM0, where businesses relied primarily on automated alerting, through progressively more sophisticated hunting practices.
This gave security teams a way to determine whether they had the proper data, processes, skills, and automation to conduct their hunt effectively.
The SANS Institute later integrated the concept into its threat-hunting course and maturity models, which helped make it the default frame for reporting.
At the time, those were important questions.
Plenty of organizations were still trying to establish hunting as a repeatable discipline instead of an occasional investigation led by whichever experienced analyst had the time and knowledge to do it.
A decade later, many established SOCs have reached that point.
They have experienced analysts, documented methodologies, hypothesis-driven processes, and years of telemetry.
Yet boards are still being shown maturity scores as evidence that threat hunting is working.
A high maturity score can still hide coverage gaps
Imagine a SOC that runs 40 hunts every quarter.
Its analysts document their hypotheses, follow a consistent methodology, use threat intelligence to inform their work, and automate repeatable tasks. By conventional maturity measures, there is plenty to like.
Now ask which adversary techniques those 40 hunts covered.
Perhaps most concentrated on endpoint behavior because that is where the team has its richest telemetry and strongest expertise.
Identity activity received less attention, and SaaS was barely touched.
Cloud investigations depended on manual queries across separate systems.
Then ask how many successful hunts became permanent detections.
If nobody can answer either question, the 40-hunt figure suddenly tells us much less than it seemed to.
MITRE ATT&CK gives SOCs a common way to describe adversary behavior across tactics, techniques, and sub-techniques.
No sensible security team is trying to achieve equal coverage of the entire enterprise matrix.
Organizations face different adversaries, use different technologies, and carry different risks.
A useful coverage measure starts with the techniques relevant to the organization’s own threat profile.
HM3 or HM4 does not tell a SOC leader which of those techniques remain blind spots.
What limits threat hunting now
Analyst skill and process discipline remain fundamental to good threat hunting.
For many established SOCs, however, they are no longer the main reason a hunt stalls or never happens.
Ten years ago, it was impossible for most Tier 1 and Tier 2 analysts to run a hypothesis-driven hunt on their own; it required experience and knowledge of what to search for, something only a few senior analysts had.
This gap has now been filled in many SOCs through training and technology.
The friction often sits in the systems analysts have to work across.
Take a hypothesis involving a compromised identity being used to access a cloud workload and move data.
An analyst may need identity logs, endpoint telemetry, cloud events, email data, and other evidence to understand what happened.
If each source requires a separate query and manual correlation, the analyst spends a large part of the hunt assembling evidence.
Successful hunts create another problem.
Useful findings do not automatically become durable detections.
Someone has to translate the logic, test it, deploy it, and make sure it continues to work.
Developments in AI-augmented threat hunting are reducing some of that manual work, particularly around querying and correlating evidence across multiple sources.
Prophet Security describes this shift as using AI to query and correlate evidence across endpoint, identity, cloud, and email telemetry, reducing the need for analysts to assemble evidence across separate consoles.
Industry coverage of the AI SOC category has noted the same shift: agentic platforms are increasingly positioned to handle alert triage and correlation so analysts can spend more of their time on proactive hunting rather than manual evidence-gathering.
This makes broader and more repeatable hunting possible, but it also raises the bar for how programs should measure themselves.
Counting hunts made sense when simply establishing a consistent hunting practice represented progress. An established SOC should be able to say considerably more.
Forty hunts is a workload statistic
Suppose a SOC leader tells the board: “We ran 40 hunts last quarter, up from 28.”
It sounds positive. More hunting took place. But the board cannot tell whether the organization is better protected as a result.
Now consider what happens when the SOC can report that its hunts covered 34% of the ATT&CK techniques identified as relevant to its threat profile, up from 22%, and that 18 validated hunts produced permanent detection logic.
The board can see where security investment changed defensive capability.
Hunt volume still has operational value. Problems arise when that activity figure is used as evidence of detection coverage.
Three metrics belong alongside maturity
ATT&CK technique coverage against the organization’s threat profile gives the program a meaningful denominator.
Start with the techniques that credible adversaries are likely to use against the organization, then measure where hunts and detections provide coverage and where gaps remain.
The rate of conversion from hunts to detections answers an entirely different question: What happens once the hunt produces a result? A validated behavior that is detectable must be fed into the detection process.
Tracing that conversion reveals hunts that consistently produce investigative value but do not translate into detection.
Mean time from hypothesis to scheduled recurring hunt shows how quickly the SOC can operationalize a hunting idea.
When new intelligence identifies a technique relevant to the organization, the important operational question is how long it takes to turn that intelligence into something the SOC can look for consistently.
Some teams will struggle to produce these numbers. Their tooling may not connect individual hunts to ATT&CK techniques. Detection engineering may sit in a separate workflow. Cross-domain hunts may be difficult to track consistently.
If you cannot measure which relevant adversary behaviors you cover, you cannot confidently tell leadership how much coverage has improved.
Give the board a number it can interrogate
Maturity scores have been favored, in part, because they look good in executive reports.
Boards don’t need to understand query syntax or detection engineering to get that HM4 sounds better than HM2.
Coverage can be just as clear.
Take a SOC that hunts for one technique: an attacker using stolen credentials to reach a SaaS application and pull data out.
The hunt confirms the technique is detectable. The team builds a permanent detection for it. A blind spot just became covered ground.
“68% of the adversary techniques most relevant to us have validated hunting or detection coverage,” gives directors a number they can track.
So does: “30% of successful hunts became permanent detections this quarter.”
Those numbers beg useful follow-up questions. Why is coverage 68%? What is in the remaining 32%? Why are some successful hunts not turning into detections?
A maturity score still has a place. It tells leadership something about the capability the organization has built and the discipline behind it.
However, if your board pack says the team ran 40 hunts and achieved HM4, while nobody can say which relevant ATT&CK techniques remain uncovered, your board still does not know how much adversary behavior your threat hunting program can cover.
Before the next board or leadership update, it’s worth checking whether your current reporting can answer two questions:
- What percentage of the ATT&CK techniques relevant to your threat profile have validated coverage?
- And what share of successful hunts became permanent detections?
If your tooling can’t produce either number today, that gap is itself worth including in the report.