Not every log belongs in your SIEM. Not every log belongs in cheap storage either. The trick is to put each event where it creates the most value, and to make that decision with a repeatable checklist rather than habit.
What each system is for
SIEM (security information and event management)
- Real-time security analytics, correlation and alerting.
- Investigations and case management.
- Threat intelligence matching and MITRE ATT&CK-mapped detections.
- Built for high-fidelity, security-relevant signals.
Log management and observability
- Collection, storage, search and dashboards for operations and audit.
- Verbose telemetry: successful authentications, health checks, component logs, metrics and traces.
- Built for cost-efficient storage and broad analytics, not real-time correlation.
The routing pattern
Route at the pipeline layer, before data reaches either system. Detection-grade identity, endpoint, network security and cloud control-plane events go to the SIEM's hot tier. Verbose operational data goes to log management or a security data lake with lifecycle policies. Enrich at the edge so detections stay precise while volumes stay lean.
Checklist: does this event belong in the SIEM?
- Detection mapping: is it used by a current or planned detection, ideally ATT&CK-mapped? If not, default to log management.
- Investigation value: do its fields materially speed up triage or root cause in the first 24 hours after an alert?
- Regulatory need: if retention is mandatory but detection value is low, store it outside the SIEM with controlled recall.
- Duplication: if a cleaner source carries the same signal, keep one and drop or summarise the rest.
- Quality: reject events that fail parsing, lack key fields or break your schema standard.
Cost levers that keep fidelity
- Field pruning: keep only the fields detections and investigations use.
- Summarisation: roll up high-frequency successes into counts with first and last timestamps.
- Sampling: for very chatty sources where full fidelity isn't needed.
- Tiered retention: hot for days, warm for weeks, cold for months and archive for years.
- Schema standardisation: map to OCSF, ECS or CIM so you don't store several shapes of the same data.
Example placements
| Keep in the SIEM (hot) | Prefer log management |
|---|---|
| Authentication failures, MFA challenges, privilege escalation | Authentication successes at scale (summarised) |
| EDR alerts with process ancestry | Service health checks and debug logs |
| Network denies, IDS/IPS alerts, east-west anomalies | Performance metrics and traces |
| Cloud audit and control-plane changes | Long-term audit copies for compliance |
Frequently asked questions
Will moving data out of the SIEM hurt investigations?
Not if you keep investigative context, such as user, asset, IDs and timestamps, in the SIEM and support on-demand recall from log management or the archive.
How do we prove detection coverage didn't drop?
Track a before-and-after scorecard: ATT&CK techniques covered, high-fidelity alert rate, false-positive rate, and mean time to detect and respond.