Join our Newsletter — 33% off our NHI Course
Home FAQ Cyber Security What do teams get wrong about more telemetry…
Cyber Security

What do teams get wrong about more telemetry equals better detection?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated August 20, 2026 Domain: Cyber Security

They often assume that collecting more host data automatically improves outcomes. In reality, unfiltered telemetry creates storage pressure, noise, and alert fatigue unless it is paired with detection rules, correlation logic, and a policy for what not to monitor. The control challenge is selectivity, not volume.

Why This Matters for Security Teams

More telemetry only helps when the organisation can turn raw signals into decision-ready detections. Security teams often mistake visibility for coverage, then discover that noisy logs, duplicate events, and poorly scoped collection make real threats harder to spot. The result is higher cost, slower triage, and weaker confidence in alerts, especially when SOC workflows are already stretched. The NIST Cybersecurity Framework 2.0 places emphasis on outcome-driven risk management, which is the right lens here: collect what supports a detection or response decision, not everything that is technically available.

This matters across endpoint, cloud, identity, and application telemetry because each stream adds operational burden. Logging policy, retention, correlation, and escalation criteria need to be designed together. If those elements are separated, teams end up with a data lake that looks comprehensive but produces fragmented evidence during an incident. In practice, many security teams encounter the cost of overcollection only after an investigation is slowed by noise and missing context, rather than through intentional detection design.

How It Works in Practice

Effective detection engineering starts with specific use cases, then works backward to the minimum telemetry required to support them. That means defining the behaviour to detect, identifying the assets and identities involved, and deciding which fields are essential for correlation. For example, process creation, parent-child relationships, command line arguments, and identity context may be more valuable than broad event duplication from every endpoint sensor.

Good telemetry design usually follows a few practical steps:

  • Map detection goals to adversary behaviours using sources such as MITRE ATT&CK.
  • Prioritise data that supports correlation across identity, endpoint, cloud, and network layers.
  • Set retention and normalization rules so analysts can query consistent fields instead of raw log variants.
  • Drop or sample low-value events that do not support detection, investigation, or compliance needs.
  • Review whether each new data source adds signal, context, or just storage overhead.

The same principle applies to identity telemetry. Access events, privilege changes, MFA prompts, and service account activity often matter more than exhaustive session logging. For cloud environments, configuration changes and control-plane actions can be more useful than high-volume application logs. Where teams use SOAR or SIEM pipelines, the priority is to tune rules so alerts are explainable and actionable, not simply frequent. Guidance from CISA Cybersecurity Performance Goals reinforces the need to focus on controls that reduce risk, not just on collecting more evidence.

These controls tend to break down when telemetry is added by default across hybrid estates without a clear detection owner because data quality, schema drift, and storage sprawl overwhelm correlation logic.

Common Variations and Edge Cases

Tighter telemetry selection often reduces visibility breadth, requiring organisations to balance investigative depth against storage, licensing, and analyst overhead. That tradeoff is usually acceptable in mature environments, but it becomes harder in regulated sectors where retention, evidentiary needs, or forensic expectations are strict. The answer is not to collect everything by reflex, but to define where full-fidelity capture is truly necessary and where summarised or event-driven logging is enough.

There is no universal standard for exact log volume thresholds, and current guidance suggests that value depends on the threat model, environment size, and detection maturity. High-risk areas such as domain controllers, identity providers, privileged session brokers, and internet-facing workloads often deserve richer telemetry than commodity endpoints. In contrast, low-signal applications may only need a narrow set of events tied to authentication, configuration changes, and security exceptions. The same applies to NHI and agentic AI systems: if a service account or AI agent can act on behalf of systems, its tool use, secret access, and privilege changes should be monitored with intent, not by indiscriminate logging.

Teams should also be cautious about treating more raw data as a proxy for better detection quality. A lean telemetry strategy, paired with well-tuned rules and periodic validation, usually produces faster investigation and better confidence than a saturated pipeline. For evolving AI-driven workflows, OWASP guidance for LLM applications is a useful reminder that security value comes from control design and abuse-case coverage, not from volume alone.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0DE.CM-01Continuous monitoring works only when telemetry is selective and actionable.
MITRE ATT&CKT1083Attack coverage should drive which host data is worth collecting.
NIST AI RMFGOVERNAI-style decision support needs clear oversight of data quality and purpose.
OWASP Agentic AI Top 10A2Agentic systems can create noisy, high-volume events that need bounded logging.
CSA MAESTROTRUST-02Security telemetry for agents should support trust decisions, not raw exhaust.

Limit logging to agent actions, tool use, and privilege changes that support abuse detection.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on August 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org