A telemetry baseline is the reference picture of normal system activity built from logs, endpoint data, network traffic, and other monitoring sources. Security teams use it to distinguish expected behaviour from suspicious activity, prioritise relevant threats, and spot gaps in what is actually being collected.
What a telemetry baseline actually represents
A telemetry baseline is not a static threshold. It is a living reference of what “normal” looks like across the signals your environment already produces, such as logs, endpoint telemetry, network flows, and platform events.
Its value comes from comparison. By understanding the usual rhythm of activity, security teams can tell whether a spike, outage, drift, or new pattern is expected behaviour, noisy but benign change, or something that deserves investigation.
Why telemetry baselines matter for detection
Baselines are one of the main ways defenders reduce alert fatigue. Without a reference picture of normal activity, every anomaly looks equally important, and monitoring becomes a volume problem instead of a detection problem.
A good baseline helps separate routine operational variation from unusual behaviour that may indicate misuse, compromise, or instrumentation gaps. It also shows where collection is incomplete, because a baseline built on partial data can hide exactly the activity you most need to see.
Security programs often pair baselining with hardening and standard configuration work. CIS Benchmarks are useful here because they define secure reference states for common platforms, while a telemetry baseline defines the observed runtime picture you expect to monitor against.
What shapes a reliable baseline
A useful baseline must reflect the specific environment, not an abstract average. Workloads change by time of day, user population, business cycle, deployment model, and seasonality, so a baseline that ignores context tends to produce false positives or miss real drift.
The baseline should also be source-aware. Endpoint, cloud, identity, application, and network signals each tell a different part of the story, and gaps between them matter. If one feed disappears, changes format, or stops covering a critical asset class, the baseline may still look stable even though visibility has degraded.
For broader monitoring models, it helps to align the baseline to recognized control families. NIST SP 800-53 Rev 5 Security and Privacy Controls ties baselining to audit, logging, configuration, and monitoring controls, while NIST Cybersecurity Framework 2.0 frames telemetry as part of identify, detect, and respond capabilities.
Common failure modes and how defenders use the baseline
Telemetry baselines fail when teams assume “normal” is permanent. Real systems drift, new services appear, agents are added or removed, and business processes change, so an old baseline can become misleading even if the environment is healthy.
Defenders use the baseline both to detect suspicious activity and to spot operational blind spots. If a key source goes quiet, produces unexpected volume, or changes its event shape, that can be just as important as an obvious security anomaly. In mature programs, the baseline becomes a practical way to validate that monitoring coverage still matches the assets and behaviours that matter.
When adversary behaviour is part of the detection problem, telemetry baselines often support techniques mapped in MITRE ATT&CK Enterprise Matrix, because deviations from normal can reveal credential access, lateral movement, or persistence activity that blends into ordinary system noise.
Risk and Threat Considerations
A weak or outdated telemetry baseline can create a false sense of security. If defenders trust an incomplete picture of normal behaviour, they may miss stealthy abuse, overlook loss of logging, or underweight suspicious changes that should have stood out.
Failure mechanism: Attackers and operational failures both benefit when the reference state is stale, incomplete, or too broad, because unusual activity can be hidden inside expected variation or absent from the data set entirely.
Impact: The result can be delayed detection, missed compromise, poor incident triage, and gaps in evidence when teams later need to reconstruct what happened.
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 SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-8 — Audit Log Management | Telemetry baselines depend on steady log collection and review coverage. |
| Recommendation — Standardize and monitor logging sources so baseline comparisons remain trustworthy. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Baselines are used to analyze audit records for unusual or expected behavior. |
| SI-4 — System Monitoring | Telemetry baselines support continuous monitoring of system and network activity. | |
| Recommendation — Compare audit activity to the baseline to prioritize anomalies for review. Use continuous monitoring to detect deviations from expected telemetry patterns. | ||
| NIST CSF 2.0 | DE.CM-01 — The network is monitored to detect potential cybersecurity events | A telemetry baseline gives meaning to monitored network and host activity. |
| Recommendation — Define normal network activity so monitoring can flag meaningful deviations. | ||
| MITRE ATT&CK | T1087 — Account Discovery | Baseline deviation helps surface discovery and other behaviors that blend into normal activity. |
| Recommendation — Map abnormal activity to ATT&CK techniques and investigate related discovery behavior. | ||
Practitioner Guidance
Why practitioners should care: Treat the baseline as a monitored security asset, not just a reporting artifact. Its value depends on continuous validation that the sources, scope, and time windows still match the environment you are trying to defend.
What to watch for: Rebuild or recalibrate when major infrastructure, logging, deployment, or business changes occur, and pay attention when the baseline itself shifts suddenly, because that may indicate either real environmental change or a visibility problem.
Practitioner takeaway: A good telemetry baseline is one that stays close enough to reality to detect change, but not so loose that it normalises the very behaviours you need to catch.
Related resources from NHI Mgmt Group
- When should organisations treat runtime telemetry as a primary control?
- Should organisations require security telemetry before adopting SaaS tools?
- Why does leaving Linux outside the passwordless baseline increase identity risk?
- Who should own trust telemetry when reporting spans NHI and cryptography controls?
