A common sign is when coverage maps look healthy but investigations stall because the underlying logs lack critical fields such as command-line data or identity context. Another warning is when a detection fires but analysts cannot reconstruct what happened. That usually means telemetry validation was never built into the control design.
How to tell telemetry is healthy versus merely present
Broken telemetry often looks healthy at the coverage layer because events are arriving, dashboards are populated, and the platform reports broad sensor adoption. The real test is whether the data supports reconstruction, triage, and root-cause analysis. If a detection cannot tell you who acted, what command ran, or which object was touched, the telemetry is functionally incomplete even if it is technically “on”.
A stronger way to judge telemetry is to ask whether the event set captures the fields analysts need to pivot without guesswork. That usually means process context, identity context, parent-child relationships, and enough timing to sequence actions reliably. When those elements are missing, the programme may be collecting volume rather than evidence.
Healthy telemetry also behaves consistently across the estate. If one host class, cloud account, endpoint group, or application tier produces richer data than the rest, coverage metrics can hide a material blind spot. The programme is only as good as its weakest logging path.
What broken telemetry looks like in investigations
The clearest sign is analyst friction. Investigations stall when the first alert opens, but the analyst cannot answer basic questions such as what launched the activity, whether privilege changed, or whether the action was local, remote, or automated. That gap usually shows up as empty command-line fields, absent user or service context, missing audit trails, or logs that cannot be joined reliably across tools.
Another sign is when detections are rule-complete but explanation-poor. You may be able to say that a condition fired, yet you cannot reconstruct the sequence with confidence. If the analyst has to jump to EDR, SIEM, cloud logs, or host artefacts every time just to understand a single alert, the telemetry design is not carrying its share of the detection burden.
Telemetry can also be broken in subtler ways. Normalisation defects, schema drift, inconsistent time synchronisation, and sparse enrichment can make apparently rich data operationally unusable. In practice, these failures matter because they prevent correlation, suppress context, and make benign versus suspicious activity harder to distinguish.
Why detection coverage can be misleading
Coverage maps are useful only when they measure the right thing. A detection engineering programme can score well on source count, agent deployment, or log ingestion while still failing to support meaningful detections. That happens when teams optimise for collection completeness instead of analytical utility, so the programme confuses telemetry presence with telemetry quality.
Detection content also degrades when the control design assumes fields that are not validated. If engineers never test whether the log record actually contains the attributes their rule depends on, the detection may remain logically correct but operationally fragile. The result is a control that looks mature in documentation and brittle in production.
The most reliable warning is the gap between alerting and understanding. If analysts can see that something happened but cannot explain how or by whom, the telemetry pipeline is not giving detection engineering enough evidence to work with. In mature programmes, the logging standard is judged by investigative value, not by raw event count.
Risk and Threat Considerations
Broken telemetry creates blind spots that attackers can exploit because the environment appears monitored while the evidence needed for detection is incomplete. That increases dwell time, weakens triage confidence, and makes it harder to prove whether suspicious activity was isolated or part of a broader compromise.
Failure mechanism: Missing context fields, inconsistent schemas, or unvalidated log sources prevent the analyst from reconstructing the event chain, so detections may trigger without producing usable investigative evidence.
Impact: Teams miss lateral movement, privilege abuse, and post-compromise activity more easily, and they spend longer confirming scope, which increases response time and business exposure.
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 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 | T1003 — OS Credential Dumping | Broken telemetry can hide post-compromise credential abuse that ATT&CK models as credential-access activity. |
| Recommendation — Map detection gaps to ATT&CK techniques and verify logs preserve the evidence needed to spot them. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | The topic is about whether telemetry actually supports effective security monitoring and investigation. |
| Recommendation — Validate that monitored events include the context needed for actionable anomaly detection. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | The question hinges on whether the right events and fields are being logged for investigation. |
| AU-6 — Audit Review, Analysis, and Reporting | Analyst inability to reconstruct events is a direct audit-analysis failure mode. | |
| SI-4 — System Monitoring | Broken telemetry undermines continuous monitoring and the effectiveness of detection engineering. | |
| Recommendation — Define logging requirements around investigative questions, not just source onboarding. Review audit records for reconstructability and escalation value, not raw volume. Test monitoring controls against real investigative scenarios before trusting coverage claims. | ||
Practitioner Guidance
What to verify: Treat every high-value detection as a telemetry test. Confirm that the underlying record contains the specific fields the investigation will need, not just the event type, and verify that the data can be correlated across sources without manual rescue work.
What to measure: Track whether alerts can be reconstructed end to end with the native telemetry alone. A useful internal signal is the percentage of investigations that require supplemental forensic collection because the original logs were too thin to answer basic questions.
Common mistake: Do not equate “we ingest the log source” with “we can investigate from it”. Detection engineering only becomes durable when telemetry validation is part of rule design, testing, and acceptance, not a follow-up task after the alert already exists.
Practitioner takeaway: Healthy detection programmes prove that telemetry is investigation-grade, not merely present, and the fastest way to find broken telemetry is to pressure-test whether an analyst can explain an alert without external guesswork.
Related resources from NHI Mgmt Group
- What are the signs that IAM login profile telemetry is failing to support detection engineering?
- What are the signs that a telemetry pipeline is failing detection engineering?
- What are effective practices for operationalizing NHI threat detection?
- What breaks when a detection programme stops at telemetry?