Detection relevance should come first. Lowering volume without a context model only creates a quieter queue, while contextual prioritisation changes which events are surfaced and why, which is what improves analyst focus and operational outcomes.
Why detection relevance should outrank log volume reduction
Teams get better outcomes when they treat logs as decision support, not as a raw quantity problem. Volume reduction can be useful for cost and signal hygiene, but it does not by itself tell analysts which events matter. Relevance is the control point because it determines which events are prioritised, correlated, and explained in context.
A useful log strategy starts with the questions defenders need answered: who acted, what changed, what was accessed, and whether the sequence fits normal behaviour. That means the first design choice is not “how much can we drop?”, but “what context makes an event actionable?” Once that is clear, you can tune collection, enrichment, and routing around meaningful detections rather than around a quieter queue.
Good relevance also reduces false confidence. A smaller stream can still miss the right evidence if filtering is blind to asset criticality, user role, transaction type, or attack stage. MITRE D3FEND is useful here because it frames detection as a set of defensive techniques tied to adversary behaviour, which reinforces the idea that context determines value more than raw event count.
How context changes what analysts actually see
Context turns logs from isolated records into interpretable signals. A failed login is low value on its own, but a failed login from a new geography, followed by token use and privilege change, becomes a different class of event. The same is true for cloud, endpoint, identity, and application telemetry: the event is only useful when it sits inside a meaningful sequence.
This is why teams should enrich before they suppress. Enrichment can add asset owner, environment, sensitivity, baseline behaviour, and known-good automation patterns, which helps separate routine activity from unusual or risky behaviour. A volume-first approach often discards that nuance too early and forces analysts to reconstruct context later, usually with more effort and lower confidence.
Detection engineering references such as SANS Security Resources are valuable because they keep the focus on practical SOC workflows, incident handling, and signal quality. That is the right frame for this decision: improve the intelligence of the alert stream before worrying about whether the stream is smaller.
What to optimise when deciding between less data and better detections
The right sequence is usually: define the behaviours you want to catch, map the telemetry needed to catch them, then remove what does not contribute. If you invert that order, you risk building a cheaper pipeline that is less capable. In practice, the best pruning decisions come after detection use cases are written and tested against real investigative paths.
Teams should also distinguish between storage reduction and analytic reduction. Retaining less raw data may be fine if high-value fields, summaries, and correlated events are preserved for search and investigation. What should not be trimmed prematurely is the context required to answer escalation questions quickly, especially for authentication anomalies, privilege changes, lateral movement, and suspicious access patterns.
If you need a prioritisation reference for detection tuning, FIRST EPSS shows how probability-based prioritisation can outperform simple volume thinking in other security workflows. The principle transfers cleanly here: prioritise what is most likely to matter, not what is merely easiest to suppress.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | Enterprise Matrix | Detection relevance depends on mapping events to adversary behaviour and sequences. |
| Recommendation — Map alert logic to ATT&CK techniques and tune detections around observable adversary steps. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Log usefulness depends on collecting, retaining and tuning logs for investigation. |
| Recommendation — Tune log collection and retention to preserve events that support investigations. | ||
| NIST CSF 2.0 | DE.CM-01 — The organization monitors networks and systems to detect potential cybersecurity events | This question is about improving monitoring signal quality, not just reducing telemetry volume. |
| DE.AE-02 — The organization analyzes detected cybersecurity events to understand attack targets and methods | Contextual prioritisation changes how events are interpreted and escalated. | |
| Recommendation — Improve monitored event relevance so detection produces actionable cybersecurity signals. Use context to analyze whether events match likely targets and methods. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Alert relevance affects whether audit data can be reviewed efficiently and meaningfully. |
| Recommendation — Filter and analyze audit records for actionable anomalies before reducing volume. | ||
Practitioner Guidance
What to prioritise: Start with the detection outcomes you need, then identify the smallest set of events and fields that make those outcomes reliable. If a log source does not improve triage, correlation, or investigation, it is a candidate for reduction; if it improves any of those, it is a candidate for enrichment or retention.
What to measure: Track analyst time-to-triage, alert precision, and the percentage of escalations that are explainable from the collected context. A quieter queue is not success if it hides the events that drive actual investigations.
Common mistake: Treating log reduction as a proxy for security maturity. Mature detection programs usually reduce noise after they prove relevance, not before.
Practitioner takeaway: Optimise for the quality of the decision an alert enables, because a smaller but context-poor stream is usually less useful than a larger stream that cleanly separates routine behaviour from meaningful deviation.
Related resources from NHI Mgmt Group
- How do security teams decide whether to prioritise NHI governance, workload identity protection, or identity threat detection first?
- How should SOC teams prioritise detection work when a week contains both APT activity and high-volume infrastructure noise?
- How should security teams balance log volume and detection fidelity in a security pipeline?
- Should security teams prioritise service-account visibility or broader detection tuning first?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org