What breaks when telemetry is not normalised before analysis?

Why This Matters for Security Teams

telemetry normalisation is the step that makes event data usable across tools, teams, and time. Without it, the same activity can appear under different field names, timestamp formats, host identifiers, or severity scales, which weakens correlation and response quality. That matters in SOC operations, cloud monitoring, identity analytics, and AI-assisted detection because the analyst, rule engine, and model are no longer looking at the same shape of evidence. NIST guidance on logging and security event handling in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that logs only become operationally useful when they are retained, protected, and made actionable.

The practical risk is not just inconvenience. Unnormalised telemetry can hide duplicate alerts, break asset-to-identity mapping, and undermine detections that depend on consistent object naming or event sequencing. It also creates a governance problem: if two pipelines interpret the same source differently, response metrics and audit evidence become hard to trust. In practice, many security teams encounter telemetry quality issues only after an investigation stalls, rather than through intentional data design.

How It Works in Practice

Normalisation usually means translating raw source fields into a common schema before analysis, enrichment, or model training. That may include mapping usernames, device IDs, IP addresses, process names, action types, and severity values into standard attributes so searches and detection logic can work across endpoint, cloud, identity, and network datasets. The goal is not to flatten all data into one identical record, but to create a consistent analytical layer that preserves source detail while enabling comparison.

Good implementations typically include:

• Common field mapping across collectors, parsers, and SIEM pipelines
• Time synchronisation and timezone handling before correlation
• Identity resolution for users, service accounts, and non-human identities
• Severity and outcome standardisation so rules do not depend on vendor-specific labels
• Versioned schema governance so detection content does not drift silently

This matters especially when detections rely on behaviour rather than single indicators. For example, a sequence-based alert may need consistent process lineage, parent-child relationships, and authentication context to determine whether activity is benign or malicious. If the telemetry feeding a SIEM or SOAR platform is inconsistent, automation may misfire, suppress a true positive, or generate duplicate incidents. MITRE ATT&CK is useful here because it helps teams align normalised events to attacker techniques instead of isolated raw logs, while MITRE ATT&CK supports technique-based detection design.

Normalisation also matters for AI-assisted analysis. Large language models and detection models perform better when labels are stable and source semantics are explicit. Without that, the system spends effort learning translation quirks instead of behavioural patterns, and human reviewers must interpret every alert manually. These controls tend to break down when organisations ingest high-volume SaaS, endpoint, and cloud logs with different vendor schemas because the mapping layer becomes inconsistent across teams and pipelines.

Common Variations and Edge Cases

Tighter normalisation often increases implementation overhead, requiring organisations to balance analytic consistency against ingestion speed, schema maintenance, and source fidelity. There is no universal standard for this yet, so best practice is evolving rather than fixed.

In smaller environments, teams may accept lightweight normalisation for a limited set of high-value sources such as identity, firewall, and endpoint telemetry. In larger environments, especially those using multiple clouds or managed services, a full canonical schema may be more realistic, but only if ownership is clear and change control is disciplined. If the schema is too rigid, important edge-case fields can be lost; if it is too loose, correlation value drops.

Identity-heavy use cases deserve special attention. When user, service account, and NHI identifiers are not normalised together, it becomes difficult to distinguish legitimate automation from compromised credentials or abused tokens. That is where telemetry quality intersects with identity security and PAM governance. For broader AI security context, NIST AI Risk Management Framework and OWASP guidance for LLM applications both point to data integrity and output reliability as core concerns. Current guidance suggests treating normalisation as a control plane, not a parsing task, because its failures ripple into detection, response, and reporting.

Related resources from NHI Mgmt Group

• Should organisations require security telemetry before adopting SaaS tools?
• What breaks when vendor access is not governed before a SaaS incident?
• What breaks when JWT claims are checked before signature validation?
• What should organisations control before exposing identity telemetry to AI assistants?