What breaks when a SOC treats every log as equal in the SIEM?

Why This Matters for Security Teams

A SIEM is only as effective as the telemetry it receives, and treating every log source as equal turns detection engineering into storage management. High-volume but low-signal feeds can obscure the events that matter most, such as identity abuse, privilege escalation, lateral movement, and control-plane misuse. That is why security teams need a value-based ingestion strategy that reflects business risk, not just log availability. Guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls consistently points toward selective logging, monitoring, and retention decisions tied to control objectives rather than indiscriminate collection.

The practical failure mode is predictable. Teams often assume more data creates better visibility, but the opposite can happen when alert queues, storage costs, and analyst workload grow faster than detection quality. If the SOC cannot distinguish high-value telemetry from routine noise, it loses the ability to prioritise threats that map to real attack paths. In practice, many security teams encounter weak detection coverage only after an incident has already exhausted the logs they thought would help.

How It Works in Practice

The better model is to classify telemetry before ingestion and route each source according to its security value. Not every log needs premium SIEM indexing. Some data is best retained in cheaper storage for forensic retrieval, while other feeds deserve immediate correlation, alerting, and enrichment. This is especially important for identity, endpoint, and cloud control-plane data, where a small set of events often provides disproportionate investigative value.

Operationally, teams should define categories such as:

• High-value detection telemetry, such as authentication, privilege changes, admin actions, and cloud audit events.
• Contextual telemetry, such as asset inventory, vulnerability status, and application metadata that improves triage.
• Bulk or low-value logs, such as verbose application traces, routine health checks, and debug output.

The SOC then maps each class to a storage and retention tier, with explicit rules for what must reach the SIEM in near real time. This is aligned with the control logic in ENISA Threat Landscape, which emphasises that defenders should focus on observable attacker behaviour, not merely volume. The same principle applies to correlation rules: the SIEM should ingest the signals that improve detection fidelity, not every machine-generated event by default.

Good implementations also tag logs by use case. For example, a failed admin login on a production identity provider may trigger immediate alerting, while routine CDN access logs may stay outside the SIEM unless they support a specific threat hunt or compliance need. This keeps costs predictable and preserves analyst attention for investigations that change risk. These controls tend to break down when cloud platforms, SaaS tenants, and legacy on-prem systems all dump heterogeneous logs into a single pipeline because normalisation, deduplication, and retention policy become impossible to maintain consistently.

Common Variations and Edge Cases

Tighter log filtering often reduces cost and alert fatigue, requiring organisations to balance better signal quality against the risk of missing something useful. That tradeoff is real, especially where the environment is dynamic or the threat model is immature. There is no universal standard for exactly which logs must always be ingested into the SIEM, so current guidance suggests using threat-informed decisions and revisiting them as the environment changes.

Edge cases matter. Regulated environments may require longer retention for specific records even when those records are not useful for day-to-day detection. Mergers, outsourced operations, and multi-cloud estates can also create temporary exceptions where broad ingestion is justified until logging standards are normalised. In identity-heavy environments, the highest-value logs are often those tied to privileged sessions, API keys, service accounts, and authentication failures, because those events reveal the path attackers actually use.

Teams should also be careful not to offload all decision-making to the SIEM vendor’s default parsers and content packs. If data quality is poor at source, no correlation engine will fix it. Better practice is to define log criticality, validate it against investigation use cases, and review it after major platform changes or incidents. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it reinforces that logging should support control objectives, not just archive everything available.

Related resources from NHI Mgmt Group

• What breaks when inbox filtering treats every user the same?
• What breaks when SOC response still depends on human approval at every step?
• What breaks when log schemas drift during a SIEM migration?
• What breaks when a SOC depends on SIEM-specific expertise?