They often assume that more data automatically means better detection. In reality, unfiltered telemetry can bury the evidence that matters and increase the time needed to resolve incidents. If teams cannot answer which data is used, by whom, and for what purpose, they are collecting noise, not observability.
Why This Matters for Security Teams
More telemetry sounds like a safe answer to blind spots, but it often creates a different problem: analysts spend longer separating signal from background activity. The issue is not volume alone. It is whether the data is tied to a detection objective, a response workflow, and a retention rule that matches operational need. Without that discipline, logging becomes an expensive archive rather than a security control.
The NIST Cybersecurity Framework 2.0 is useful here because it pushes teams to align visibility with governance, detection, and response outcomes rather than treating collection as a goal in itself. Security leaders often overestimate how much extra data improves investigations, while underestimating the overhead created by parsing, storing, normalising, and securing that data. The result is delayed triage, higher tool complexity, and weaker operational focus.
There is also a control-risk angle. If telemetry includes sensitive identifiers, secrets, or user activity without clear purpose limitation, it can expand privacy exposure and internal access risk. Mature teams ask which events support detection engineering, which support forensics, and which are simply duplicated across tools. In practice, many security teams encounter telemetry sprawl only after alert fatigue, storage costs, and missed incidents have already made the problem visible.
How It Works in Practice
Effective telemetry strategy starts with use cases, not collectors. Teams should define which attack paths, failure modes, and compliance requirements the data is meant to support, then map each source to a specific decision point. That usually means prioritising identity events, endpoint signals, cloud control-plane logs, and high-value application traces before expanding into lower-value sources. The guidance in CISA's Known Exploited Vulnerabilities Catalog is a good reminder that visibility should focus on exploitable risk, not raw exhaust.
In practice, teams get better results when they treat telemetry as an engineered product:
- Define the security question first, such as credential misuse, privilege escalation, or data exfiltration.
- Collect the minimum event fields needed to answer that question at speed.
- Standardise schemas so correlation rules and detections are portable across tools.
- Set retention by investigative need, regulatory obligation, and cost tolerance.
- Review whether each source is used for alerting, hunting, forensics, or audit.
Engineering teams often need to separate observability data from security telemetry. Application traces may help root-cause analysis, but they are not automatically good security signals unless they expose relevant abuse patterns. Security teams should also consider enrichment carefully: the more joins, transformations, and forwarded copies a record goes through, the more likely it is to degrade fidelity or create blind spots. The MITRE ATT&CK knowledge base is useful for checking whether your telemetry actually covers the techniques you expect to detect. These controls tend to break down when teams centralise logs from many platforms without agreed schemas, because correlation logic becomes brittle and analysts lose trust in the data.
Common Variations and Edge Cases
Tighter telemetry governance often increases engineering overhead, requiring organisations to balance investigative depth against storage, privacy, and processing constraints. That tradeoff becomes sharper in cloud-native and high-throughput environments, where every additional signal can multiply ingestion cost and rule complexity. Best practice is evolving, but there is no universal standard for how much telemetry is enough.
One common edge case is regulated data. If logs contain personal data, payment data, or customer identifiers, retention and access controls must be designed with the same care as production systems. The CIS Controls support this by emphasising secure log management, but teams still need local decisions about masking, segmentation, and who can query the data. Another edge case is incident response during an active attack: temporary collection expansion can be justified, yet it should be time-bound and reviewed after containment.
For identity-heavy environments, there is a direct intersection with credential governance. Telemetry that records authentication failures, token use, privilege changes, and API access can be highly valuable, but only when it is linked to a clear identity model. If the organisation cannot tell whether a record belongs to a person, service account, workload, or AI agent, the data is too ambiguous to drive reliable response. That is where collection strategy should be reset around trust boundaries rather than raw event count.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST AI 600-1 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 | Telemetry should support continuous monitoring, not uncontrolled data accumulation. |
| MITRE ATT&CK | T1078 | Credential abuse is a common reason teams need targeted telemetry. |
| NIST AI RMF | Risk governance applies when telemetry is used to observe AI-driven systems and agents. | |
| OWASP Agentic AI Top 10 | Agent actions can create noisy traces that need deliberate collection and validation. | |
| NIST AI 600-1 | GenAI systems need evidence of prompts, outputs, and guardrail decisions without overcollection. |
Log agent tool use and decisions selectively, then validate that telemetry can distinguish misuse from normal execution.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
