Why does sending all telemetry into a legacy SIEM create cost and control risk for large enterprises?

Sending all telemetry into a legacy SIEM creates cost and control risk because the organization pays ingestion, storage, and analytics fees on data it may not need. It also hands the vendor control over proprietary formats and limits reuse of the underlying telemetry. That dependency makes investigations slower, increases lock-in, and weakens the organization’s ability to operate on its own data.

Why This Matters for Security Teams

Legacy SIEMs were built to collect logs, not to serve as the system of record for every telemetry stream in a large enterprise. When security teams push all data into one platform, they inherit indexing, retention, and query costs that scale faster than operational value. That becomes a control problem as well as a budget problem, because the platform starts deciding what is practical to keep, search, and enrich.

The risk is magnified when the telemetry includes high-volume identity, cloud, endpoint, and NHI activity. NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now notes that NHIs outnumber human identities by 25x to 50x in modern enterprises, which means telemetry from service accounts, API keys, and automation can overwhelm platforms that were not designed for machine-speed activity. In parallel, the NIST Cybersecurity Framework 2.0 reinforces that visibility must support response, not merely collection. In practice, many security teams discover the cost of overcollection only after investigations slow down and retention policies become a vendor negotiation rather than an internal decision.

How It Works in Practice

The core issue is that a legacy SIEM often becomes both the collector and the gatekeeper. Every log source is normalized into a vendor-specific schema, every query is constrained by proprietary search logic, and every retained byte is billed as part of a consumption model. That creates three operational dependencies: the organization pays to ingest data that may never be queried, it loses flexibility to reuse raw telemetry elsewhere, and it becomes harder to prove what was actually retained versus what was summarized or dropped.

This is where modern architecture guidance is moving toward tiered telemetry. Security teams increasingly separate:

• hot data for active detection and triage,
• warm data for investigations and hunt workflows,
• cold data in lower-cost storage for compliance or forensic replay.

That model aligns more closely with control objectives in NIST SP 800-53 Rev 5 Security and Privacy Controls, which emphasize auditability, retention, and access control without requiring every dataset to live inside one analytics engine. It also fits the NHI problem space described in Ultimate Guide to NHIs — Key Challenges and Risks, where excessive privileges, weak visibility, and poor rotation practices increase operational exposure.

For large enterprises, the practical pattern is to keep raw telemetry in an enterprise data lake or equivalent control plane, then forward only the events needed for detections, correlation, or regulatory workflows into the SIEM. That preserves the ability to reprocess data, tune detections, and move analytic workloads without reingesting the same records at a premium. These controls tend to break down in environments with extremely high event volume and inconsistent log schemas because normalization, retention, and query latency quickly become the bottleneck.

Common Variations and Edge Cases

Tighter centralization often improves convenience, but it also increases spend and vendor dependence, so organisations have to balance analyst simplicity against data sovereignty and long-term operating cost. The right answer is not always to remove the SIEM; current guidance suggests right-sizing its role.

There is no universal standard for this yet, but the most defensible approach is usually risk-based routing. High-value security telemetry, such as authentication failures, privilege changes, and NHI secret usage, may still belong in the SIEM. Low-value, high-volume telemetry often belongs elsewhere until a rule, incident, or compliance need justifies promotion. That distinction matters because NHI compromise signals can be buried inside machine-generated noise, and NHIMG’s Top 10 NHI Issues shows how frequently organisations still struggle with visibility and lifecycle control. It also helps to review platform concentration risk using the Sumo Logic Breach case study, which is a reminder that security data platforms themselves can become strategic attack surfaces.

The edge case is regulated environments that need immutable, long-retention evidence in one place. In those settings, enterprises often keep a compliance copy in the SIEM while preserving the authoritative telemetry in storage they control directly. That compromise reduces lock-in without sacrificing evidentiary value.

Related resources from NHI Mgmt Group

• Why does identity provider sprawl create security risk in large enterprises?
• Why do legacy RADIUS deployments create access control risk?
• Why do password resets create compliance and security risk in large enterprises?
• Why do legacy loyalty platforms create control risk for customer engagement programmes?