Should teams prioritise recall or precision when using LLMs for ATT&CK enrichment?

When does recall beat precision in ATT&CK enrichment?

For ATT&CK enrichment, recall is usually the better first priority when the enrichment supports detection engineering, hunt triage, or coverage analysis. Missing a real technique label can hide important coverage gaps, while an extra label is often recoverable. Precision becomes more important when the output drives alerting, reporting, or automated downstream actions where false positives create measurable noise.

Why recall is usually the safer default for enrichment

LLM-assisted enrichment is often filling in labels on top of imperfect human-authored content. In that setting, a missed technique can look like a clean result even though the rule or note is incomplete. High recall helps surface more candidate ATT&CK mappings for review, which is especially useful when labels are being used to improve coverage rather than to make an enforcement decision.

That does not mean anything uncertain should be accepted blindly. It means the enrichment step should be designed to expose likely matches for validation, not to act as a final truth source. If the workflow is exploratory, analysts generally get more value from over-inclusion that can be reviewed than from a narrow model that misses relevant technique relationships.

MITRE ATT&CK itself is best used as a threat-intelligence and detection language, so enrichment should preserve enough breadth to support later analyst judgment and MITRE ATT&CK Enterprise Matrix-based mapping. When the same enrichment is feeding governance or assurance reporting, the acceptable error profile tightens and precision deserves more weight.

How to balance precision without losing coverage

The practical decision is not recall versus precision in the abstract, but where the output will land. If the label set is feeding a hunt notebook, a rules backlog, or a coverage dashboard, tolerate some over-tagging and let analysts prune it. If the label set is used for customer-facing reporting, KPI rollups, or automated routing, require stronger evidence before accepting a technique label.

Community-contributed ATT&CK annotations are often incomplete, inconsistent, or unevenly applied, so an apparent false positive may simply be an untagged but valid technique. That is why enrichment should usually produce ranked candidates or evidence-backed suggestions, not just a single irreversible label. Where the model is uncertain, a “possible” or “review needed” state is often more honest than forcing precision too early.

For technique enrichment in detection engineering, use the model to widen the search space, then apply a human review step for the final corpus or rule library. A useful reference point is NIST Cybersecurity Framework 2.0, which reinforces that identification, protection, detection, response, and recovery are all part of the control loop, not just the labeling step.

What good ATT&CK enrichment looks like in practice

Good enrichment separates model utility from final authority. The model should maximise candidate coverage, attach a confidence signal, and preserve the evidence that led to each suggested technique. Analysts then decide whether the label is strong enough for the intended use case. That workflow prevents precision concerns from collapsing the enrichment process into under-labeling.

Teams also need to define the failure mode they care about most. If the main cost is missed coverage, measure recall-like behaviour against a sampled ground truth set. If the main cost is noisy reporting, measure how often enrichment produces labels that survive analyst review. The metric should match the operational decision, not the novelty of the model.

Practitioner Guidance: Treat ATT&CK enrichment as a coverage aid unless the output is directly driving production decisions. Start by optimizing for recall, then add a review threshold or confidence gate where precision matters. If analysts repeatedly reject the same technique suggestions, tighten the prompts, source evidence, or post-processing rules before you lower coverage.

Practitioner takeaway: For most detection engineering workflows, the better default is to catch more plausible technique mappings first and let analysts remove noise later, because missing a real ATT&CK relationship is usually harder to recover from than reviewing a few extra candidates.

Related resources from NHI Mgmt Group

• How should security teams use LLMs to map Sigma rules to MITRE ATT&CK?
• How do teams know if ATT&CK enrichment is actually helping detection engineering?
• How should security teams use MITRE ATT&CK to prioritise risks in CI/CD pipelines?
• When should teams prioritise recall over precision in AI SOC alert triage?