Teams should decide before ingestion, using enrichment to attach threat intelligence, asset ownership, and identity context while the event is still in motion. That allows full-fidelity retention only for telemetry with clear security value, while lower-value records can move to cheaper storage without losing recoverability.
How to decide what deserves full SIEM retention
The cleanest decision point is before ingestion, not after an analyst needs the event. SOC teams should define retention tiers by the security decisions a record can support: can it help confirm compromise, reconstruct scope, or prove control failure? If yes, it belongs in full-fidelity retention. If it is mainly operational noise, summarize it, sample it, or move it to cheaper storage.
That approach works best when telemetry is enriched while it is still hot. Asset ownership, identity context, and threat intelligence turn raw events into evidence, which makes the retention decision far more defensible. A login event from a privileged host is not the same as a background heartbeat, and the difference should be visible before the event ages out of the pipeline.
What makes telemetry security-relevant enough to keep
Full SIEM retention should be reserved for telemetry with a clear investigative or control value. Common examples include authentication events, privilege changes, security tool alerts, admin activity, east-west movement indicators, and records tied to crown-jewel systems or regulated data. The key test is whether the event can answer a likely question during triage, incident response, or post-incident review.
Events that rarely inform a security decision can usually be downgraded. High-volume application logs, repetitive health checks, and low-context routine transactions often matter less than identity, privilege, and asset context. In practice, the difference is not the source system alone, but the combination of source, actor, action, and business criticality.
How to tier data without losing investigative value
A practical model is to classify telemetry into three groups: full retention for high-value security evidence, reduced retention for contextual records, and low-cost archival for records that are only needed for rare reconstruction or compliance reasons. This is where enrichment matters most, because a record with ownership and identity context can be safely downgraded or retained based on the actual risk it represents.
Teams should also treat storage design as part of detection engineering. If a record is likely to support alert tuning, threat hunting, or incident scoping, the retention choice should preserve the fields that make those uses possible. Where a record only becomes useful after correlation, keep the correlation keys in the hot path even if the raw payload is moved elsewhere.
For breach-driven judgement on what logs become valuable after compromise, the Sumo Logic breach lesson on credential compromise and log management shows why retention policy should account for the evidence needed to trace access paths and rotate exposed credentials.
Risk and Threat Considerations
Retention decisions create exposure when they are made too late or with too little context. If the SOC keeps everything in expensive hot storage, detection quality may be fine but cost and operational friction rise sharply. If it keeps too little, investigators lose the timeline, actor context, or privilege evidence needed to understand how a compromise unfolded.
Failure mechanism: The failure mode is usually a visibility gap created by overcompression, premature deletion, or blind reliance on generic retention rules that ignore asset criticality and identity context. Once the event leaves full-fidelity storage, enrichment cannot be recovered unless the original fields were preserved elsewhere.
Impact: The result is slower containment, weaker root-cause analysis, and a higher chance that alerting, forensics, or legal review cannot prove what happened. In a real incident, that can turn a recoverable security event into an attribution and scope problem.
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 surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | Telemetry retention depends on identity and access evidence needed for investigations. |
| DE.AE-02 — Anomalies Are Analyzed to Ensure Appropriate Response | Retention should preserve events that support anomaly analysis and response decisions. | |
| Recommendation — Retain identity and access records that support verification and incident scoping. Keep full-fidelity telemetry that enables anomaly analysis and response triage. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Logging scope drives which events exist for later security review and retention. |
| AU-11 — Audit Record Retention | Retention periods and storage tiers directly govern how long logs remain usable. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Retention must preserve records needed for review, analysis, and reporting. | |
| Recommendation — Define logged events by the investigative value they provide. Set retention tiers based on security value and operational need. Keep the records analysts need to review, analyze, and report on incidents. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Log management includes deciding which logs to retain at full fidelity. |
| Recommendation — Prioritize retention for logs that support investigation and response. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | Logging control selection affects which telemetry is captured and retained. |
| Recommendation — Define logging scope so critical events remain available for review. | ||
| MITRE ATT&CK | T1070 — Indicator Removal on Host | Retained logs help detect and investigate attacker attempts to erase traces. |
| T1110 — Brute Force | Authentication telemetry is often essential for detecting credential attacks. | |
| T1078 — Valid Accounts | Identity-context telemetry is central to investigating stolen-account abuse. | |
| Recommendation — Keep telemetry that can reveal trace removal and post-compromise actions. Preserve auth events that expose credential abuse and account attacks. Retain identity-rich logs that show valid-account abuse and lateral movement. | ||
Practitioner Guidance
What to prioritise: Start with telemetry that carries identity, privilege, admin, and crown-jewel context, because those records are the most likely to justify full retention. If a data source never changes containment, scoping, or proof of misuse, it should be a candidate for lower-cost treatment.
What to verify: Before you downgrade any stream, verify that you still retain the fields needed to correlate actors, assets, and time windows across tools. If enrichment or indexing is lost, the cheaper storage tier may be functionally useless during an incident.
Practitioner takeaway: Full retention should be a security decision, not a storage habit, and the best cutoff is the point where telemetry stops adding investigative certainty.
Related resources from NHI Mgmt Group
- How should security teams govern non-human identities for SOC 2 compliance?
- How should organisations decide what belongs in full SIEM retention?
- How should security teams decide which telemetry belongs in the SIEM?
- How should security teams decide what telemetry to send into a cloud SIEM when ingest-based pricing is in place?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org