How long should SIEM security monitoring retain security logs?
SIEM security monitoring should retain security logs for as long as your legal, regulatory, contractual and investigative requirements demand, rather than relying on one universal period. Define separate retention periods for searchable logs and lower-cost archives, based on the sensitivity of the data, likely investigation timescales and your organisation’s cyber security risk.
A defensible SIEM log-retention policy should match each log source to its evidential value, sensitivity, investigation window and applicable obligations. In practice, this means defining what remains immediately searchable, what moves to an archive, when records are placed on legal hold, and when they are securely deleted. A single retention period for every event is rarely appropriate.
Start by identifying the purpose of each log. SIEM data may support several different activities:
- Detecting and investigating active cyber security incidents
- Reconstructing what happened after a suspected compromise
- Tracing administrator and privileged-user activity
- Identifying unauthorised access to business systems or data
- Demonstrating that security controls and operational processes are being followed
- Supporting internal investigations, insurance requirements or contractual commitments
These purposes do not necessarily require the same period. A firewall connection event with limited context may have less long-term investigative value than an identity record showing a privileged sign-in, a change to access rights or the creation of a new account.
Classify log sources rather than treating all events equally. A useful policy groups data according to the risk it helps investigate. Authentication and identity logs, endpoint security events, privileged activity, cloud administration records, firewall and remote-access logs, email security events, and critical application audit trails often deserve greater consideration than routine operational messages. Logs from systems containing sensitive business information may also need stricter handling because they can include usernames, IP addresses, device details or fragments of personal data.
Classification should record the source owner, the systems covered, the events collected, the purpose of collection, the sensitivity of the data and the retention treatment. It should also identify events that should not be collected at all. Passwords, access tokens and unnecessary contents of communications should not be retained merely because a source system can produce them.
Separate searchable retention from archive retention. Security analysts need current, well-indexed data for correlation and investigation. Keeping every historical event in the most expensive, fastest storage can make a SIEM unnecessarily costly and difficult to operate. Older records may instead be transferred to lower-cost storage, provided they remain:
- Readable in their original or an agreed standard format
- Linked to accurate timestamps, source information and event context
- Protected against unauthorised alteration or deletion
- Discoverable within a known process
- Retrievable within a period that is suitable for the organisation’s investigative needs
Archive data is not useful if nobody can locate it, interpret it or verify that it has not been changed. The retention policy should therefore define how archived records are indexed, who can request restoration, how access is approved and how retrieval is recorded.
Consider the time needed to discover an incident. An attack may not be recognised when the first suspicious activity occurs. Initial indicators can be missed, an attacker may use legitimate accounts, or an incident may only become apparent after a supplier, customer or law-enforcement body raises a concern. Retention planning should allow for the period between the earliest relevant event, detection, investigation and any later review. The appropriate period depends on the organisation’s threat profile, the systems exposed to the internet, the complexity of its environment and the consequences of losing historical evidence.
Check the obligations that apply to the organisation. Data protection law does not usually prescribe one universal period for all security logs. Instead, organisations should be able to explain why personal data is collected, how long it is kept, who can access it and why continued retention is necessary. The UK GDPR and Data Protection Act 2018 principles around purpose limitation, data minimisation, storage limitation and security are relevant where logs contain information relating to identifiable people.
Other requirements may come from a sector regulator, a customer contract, an insurer, a quality framework or an internal records policy. These obligations can apply to the underlying business record rather than to a copy held in the SIEM, so they should be assessed separately. A compliance requirement should not automatically lead to indefinite retention of every technically related event.
Document exceptions and legal holds. If an incident, dispute, investigation or regulatory request requires particular records to be preserved, normal deletion rules may need to be suspended for the relevant data. A legal hold should identify the systems, date range, event types, responsible owner and reason for preservation. It should also include a review point so that the hold is removed when it is no longer required. Without this control, data may either be deleted too early or retained indefinitely without a clear justification.
Build deletion into the design. Retention is incomplete unless it explains what happens at the end of the period. Automated expiry can reduce reliance on manual action, but it should be tested to confirm that it covers primary storage, indexed copies, exports, replicas and archives. Exceptions must be visible, and deletion records should show what was removed, when and under which policy. Backups require particular care because their lifecycle may not match the SIEM’s normal retention schedule.
Measure the effect on SIEM performance and cost. Retention decisions affect storage capacity, indexing, search speed, ingestion design and the effort required to manage archived data. Before changing a policy, assess event volume, duplication, verbose sources and the value of collecting every available field. Filtering low-value noise at the source can be more effective than simply storing more data. This should be balanced carefully: reducing volume must not remove fields needed to connect an identity, device, process, network flow and action during an investigation.
Review the policy when the environment changes. New cloud services, additional sites, remote-access arrangements, acquisitions, changes to legal obligations and major incidents can all alter the appropriate retention approach. A periodic review should confirm that important sources are still sending complete records, clocks are synchronised, archive retrieval works and the defined periods remain justified. Retrieval exercises are particularly valuable because a policy that cannot produce usable evidence when needed is only theoretical.
For a small or medium-sized organisation, the practical outcome is usually a documented, risk-based schedule covering each important source, its searchable period, its archive treatment, access controls, legal-hold process, review owner and deletion method. S2 Technology Group can help organisations assess their logging requirements as part of wider IT support and cyber security planning, while keeping retention decisions aligned with the systems, risks and obligations of the business.
SIEM log retention should normally be measured from when an event occurred, not simply from when the SIEM received it. Delayed forwarding, temporary collection failures, clock differences and time-zone settings can otherwise cause relevant records to expire earlier than intended.
Document how the retention period is calculated for each source. The policy should account for the event timestamp, ingestion timestamp and any delay before a record becomes available for analysis. Centralising timestamps in a consistent format and monitoring for clock drift helps investigators establish a reliable sequence of events.
Collection gaps also need to be visible. A SIEM should record when a source stops sending data, rather than allowing an absence of events to appear as normal activity. This distinction is important when deciding whether the available history is sufficient to investigate an incident or whether additional records must be obtained from the original system.
