Blog

How Long Should You Keep Security Logs?

Use a risk-based method to set searchable and archived security-log retention periods without confusing a default SIEM window with a complete policy.

There is no single security-log retention period that fits every organization. A defensible policy starts with the investigation, legal, contractual, and operational questions each log source must answer. It then separates how long data must remain immediately searchable from how long it must be preserved in a protected archive.

For many organizations, a useful planning baseline is to keep the most important security logs searchable for at least 90 days and retain protected copies for at least 12 months. That is a starting point, not a universal compliance rule. Some environments need longer periods; low-value, high-volume telemetry may justify less. The decision should be documented by log source and approved by the people responsible for security, privacy, legal obligations, and cost.

Why one retention number is usually the wrong answer

A flat rule such as “keep every log for one year” sounds simple, but it ignores three practical differences:

  • Investigation value: identity, endpoint, firewall, email, cloud-administration, and critical-application logs answer different questions during an incident.
  • Access speed: analysts may need recent data in seconds, while older evidence can be restored from a less expensive archive.
  • Obligations: contracts, cyber-insurance conditions, litigation holds, and sector-specific requirements may apply to particular systems or records rather than every event the organization generates.

The NIST Cybersecurity Log Management Planning Guide describes log management as generating, transmitting, storing, accessing, and disposing of log data. That lifecycle view matters: retention is not just a storage setting. It also requires decisions about collection, access, protection, retrieval, and deletion.

Use two retention windows

Define two periods for each important source instead of treating all retained data as equally available.

Two-part security-log retention model
WindowPurposeQuestions to answer
Searchable retentionFast detection, investigation, reporting, and routine reviewHow far back do analysts commonly search? How quickly must results be available? Which fields must remain indexed?
Archived retentionOlder investigations, audit evidence, legal preservation, and trend analysisHow quickly can data be restored? Is it tamper-resistant? Are access and deletion controlled? Can the organization prove the archive is complete?

This distinction helps teams avoid paying premium search costs for every historical event while still preserving evidence that may be needed later. It also exposes an important contract question: when a provider says logs are “retained,” does that mean online and searchable, retrievable from cold storage, or merely summarized in reports?

A five-step method for setting retention

1. Start with the questions an investigation must answer

For each system, identify the events needed to reconstruct account use, administrative changes, remote access, policy changes, malware alerts, network connections, data access, and security-control activity. Prioritize sources that establish who acted, what changed, where the activity originated, and what systems or data were affected.

Do not assume that collecting a device’s default events is enough. A long archive with missing authentication, administrator, or policy-change events can still leave investigators unable to build a reliable timeline.

2. Map explicit requirements

Record the rule, contract, policy, or business reason behind every mandatory period. Do not borrow a number from another framework without confirming that it applies to your scope.

As one concrete example, the current PCI DSS standard requires in-scope audit-log history to be retained for at least 12 months, with the most recent three months immediately available for analysis. That requirement is useful as an illustration of the two-window model, but it does not automatically govern systems outside a cardholder-data environment.

3. Account for detection and investigation delay

A retention window must reach back far enough to show what happened before an alert. The CISA #StopRansomware Guide recommends retaining and adequately securing logs from network devices, local hosts, and cloud services, centralizing them for analysis, and maintaining critical-system logs for at least one year when possible.

Use that recommendation alongside your own incident history. If investigations repeatedly need older identity, VPN, email, or firewall data, extend those sources before increasing retention everywhere.

4. Tier sources by value and volume

Create a retention matrix rather than a single sentence in a policy. A practical first pass might look like this:

Example prioritization questions by log source
SourceWhy it may deserve longer retentionConfiguration check
Identity and directoryShows authentication, privilege, consent, and account changesAre successful and failed sign-ins, role changes, and application grants captured?
Firewall, VPN, and secure gatewaySupports exposure, remote-access, command-and-control, and data-flow analysisAre timestamps, actions, source, destination, user, and policy identifiers preserved?
Endpoint and serverSupports process, persistence, malware, and lateral-movement investigationWill event filtering remove data needed for a timeline?
Cloud administration and SaaSShows configuration, API, identity, and data-access activity outside the local networkDoes the subscription tier provide the required events and export period?
Critical business applicationsConnects technical activity to sensitive transactions or recordsCan an event be tied to a named user and authoritative time source?

The table is a decision aid, not a prescribed duration. Teams should assign searchable and archived periods after evaluating each source’s investigative value, obligation, event volume, privacy impact, and recovery time.

5. Test retrieval and deletion

A retention policy is only credible if the organization can retrieve protected data within the time promised. Sample an older period, restore it, search it, confirm timestamps and fields, and record how long the process takes. Also test that expired data is deleted according to policy and that legal holds or incident-preservation instructions suspend routine deletion when authorized.

Questions to ask a managed security provider

  • Which devices, endpoints, cloud services, identities, and applications are actually connected?
  • Which event types are collected, filtered, normalized, and searchable?
  • How many days of raw data are hot, warm, or archived?
  • What is the cost and expected time to retrieve archived data?
  • Are archives encrypted, access-controlled, and protected from unauthorized alteration or deletion?
  • Who monitors failed collectors, ingestion gaps, clock drift, and storage limits?
  • What happens to logs at contract termination, and how can the customer export them?
  • Which reports are summaries, and which underlying events remain available for investigation?

These questions prevent a common mismatch: buying “one year of retention” when only a short period is searchable, important sources are not connected, or older data cannot be restored quickly enough for an incident or audit.

How Network Box USA fits into the policy

Network Box USA SIEM is included with qualifying Edge Defense and NBX MDR services; it is not sold as a standalone service. The published service scope includes 15 days of hot raw-data storage, 75 days of warm raw-data storage, 90 days of dashboard-accessible data in total, and customizable cold storage.

That published window should be evaluated against the organization’s retention matrix. Connected sources, event volume, cold-storage needs, retrieval expectations, monitoring, and reporting must be defined during solution design. Network Box USA can support centralized logging, correlation, managed review, investigation, and evidence workflows within the agreed scope, but the customer remains responsible for determining its legal, contractual, and enterprise retention requirements.

Put the policy into one auditable matrix

For every in-scope source, document the owner, required events, searchable period, archive period, storage tier, access roles, integrity protections, retrieval target, deletion rule, governing obligation, and last successful test. Review the matrix when systems, contracts, regulations, or incident patterns change.

If your team needs to align log sources, searchable windows, archive needs, and managed monitoring responsibilities, request a Security Stack Review from Network Box USA.