Log Retention: Keeping What's Needed for Investigation
Cybersecurity · 2 min
Articles by Fábio Ribeiro
Storing logs without criteria increases costs and noise. Learn how to define useful retention for security, continuity, and auditing.
TL;DR
- Log retention should be based on investigation scenarios, not just technical capacity.
- Not all events require the same detail, protection, or retention period.
- Log quality depends on coverage, normalization, context, and access control.
- Excessive retention can increase costs, risk, and operational complexity.
- The policy should be reviewed when systems, risks, contracts, or regulatory requirements change.
The Right Question Is Not How Much to Store
Many organizations start their log retention policy by platform capacity: how much space is available, how much it costs to store, and how long events can technically be kept. The more useful question is different: __what information will be needed to reconstruct an incident, confirm a change, respond to an audit, or demonstrate the execution of a control?__ This approach avoids two frequent extremes: storing everything without context, creating cost and noise, or storing only aggregated events that do not allow for confident investigation.
Define Scenarios Before Defining Timelines
Retention must be designed based on concrete scenarios: *improper administrative access*, critical configuration change, authentication failure, suspicious exfiltration, service unavailability, or privileged action execution. For each scenario, it is important to identify sources, necessary fields, retention needs, required analysis period, and involved teams. [Observability and AIOps platforms](/pt/solucoes/sistemas-monitorizacao) can help centralize events, but they do not replace the decision of which logs have operational, evidentiary, or compliance value.
Not All Logs Have the Same Value
Identity, administration, network, systems, critical application, backup, and **cloud service events** should not be treated as if they have the same weight. Some require greater detail and protection against alteration; others can be aggregated or retained for less time. It is also important to distinguish *technical logs* from voluminous telemetry, records with personal data, security evidence, and performance metrics. A mature policy defines log classes, owners, purpose, location, retention period, and deletion criteria.
Context Is As Important As Volume
Logs without context rarely accelerate an investigation. An access event is more useful when it can be related to identity, device, application, location, approved change, and affected service. Linking to inventories, dependencies, and operational procedures improves the interpretation of signals. When an incident occurs, [well-defined runbooks](/pt/blog/runbooks-automatizacao-resposta-incidentes) help transform this data into repeatable decisions: *what to validate first, who to involve, what evidence to preserve, and when to escalate*.
Protecting Logs Against Abuse and Loss
Logs themselves can become sensitive. They can reveal usage patterns, addresses, usernames, exposed keys, application errors, or customer information. Therefore, retention must include access control, segregation of duties, encryption when appropriate, audit trails on queries, and *immutability mechanisms* when risk justifies it. In a model with [SOC/NOC as a Service](/pt/solucoes/soc-noc-as-a-service), it is important to contractually clarify who can view, export, modify, and delete records.
Review the Policy Based on Risk
A log retention policy should not remain static. New applications, SaaS services, integrations, regulatory changes, audits, and incidents should lead to *periodic reviews*. The decision is not just technical: it involves security, operations, legal, compliance, and business stakeholders. The goal is to maintain sufficient evidence to investigate and demonstrate control, without accumulating data without a clear purpose. A good policy helps reduce uncertainty when an incident occurs and makes the balance between cost, risk, and utility more predictable.