5 Security log retention is a question every SOC eventually has to answer formally, usually after an auditor asks or an incident investigation runs out of history. Keep logs too briefly and investigators cannot reconstruct how an attacker got in. Keep everything forever and storage costs climb while personal data accumulates beyond what privacy law allows. The right answer combines regulatory minimums, the realities of attacker dwell time and a storage design that makes long retention affordable. This article covers the main requirements that shape security log retention, how organizations structure retention by log type and tier and what it means for SIEM and storage architecture. It is general information, not legal advice. For what to keep in a central repository, see what a security data lake is. Regulatory and framework requirements Requirements vary by industry and jurisdiction. Common examples include: PCI DSS. Version 4 of the Payment Card Industry Data Security Standard requires audit log history to be retained for at least 12 months, with at least the most recent three months immediately available for analysis (requirement 10.5.1). US federal agencies. In May 2026, OMB Memorandum M-26-14 replaced the 2021 logging memorandum M-21-31. M-26-14 sets minimum baselines of six months of searchable log data for continuous event monitoring and one year of retrievable data for threat hunting, investigation, response and forensics, down from M-21-31’s twelve months of active and eighteen months of cold storage for priority logs. HIPAA. The Security Rule requires audit controls that record and examine activity in systems containing electronic protected health information. HIPAA requires certain compliance documentation to be retained for six years, and many healthcare organizations align log retention with that period. Financial services regulation, such as the EU’s Digital Operational Resilience Act, requires ICT logging and monitoring as part of risk management, with retention set by the institution’s policies and supervisory expectations. Frameworks such as ISO 27001 and the NIST Cybersecurity Framework require logging and log protection but generally leave specific periods to the organization. See what is the NIST Cybersecurity Framework and what is NIS2 for broader context. Privacy limits on retention Security logs often contain personal data: user names, IP addresses, email addresses, device identifiers and browsing activity. Under GDPR and similar laws, personal data should be kept no longer than necessary for its purpose. Security is a legitimate purpose, but organizations should be able to justify their retention periods, limit access and delete logs when they are no longer needed. That argues for documented, defensible retention schedules rather than indefinite storage. Dwell time: the operational argument for longer retention Regulation sets minimums, but investigations set practical needs. Attackers often remain in an environment for weeks or months before being detected. When an incident is discovered, investigators need logs going back to the initial intrusion. If logs only cover 30 or 90 days, the beginning of the attack may already be gone. The scality.com blog explores this in its article on ransomware dwell time and backup retention. The same logic applies to security logs: retention should exceed the time it may take to detect a compromise, with margin. Structuring retention by log type Not all logs are equally valuable. A practical retention schedule groups logs by their investigative and compliance value: Authentication and identity logs (directory services, single sign-on, VPN): high value for investigations, often retained longest. Endpoint detection and response telemetry: high value, high volume. Network security logs (firewall, proxy, DNS, intrusion detection): high value for scoping incidents. Cloud audit logs (control plane activity in cloud platforms): high value and essential for cloud investigations. Application and database audit logs: value depends on the system’s sensitivity. Verbose operational and debug logs: lower security value, often retained briefly. Each group gets a retention period and a tier assignment. Hot, warm and cold tiers Retention does not mean keeping everything instantly searchable. Most organizations use tiers: Hot or searchable tier: recent logs available for real-time detection and fast search, often three to twelve months depending on requirements. Warm or retrievable tier: older logs that can be searched with some delay or restored when needed. Archive tier: long-term retention for compliance or legal holds, rarely accessed. PCI DSS’s distinction between twelve months retained and three months immediately available, and the federal distinction between actively searchable and retrievable data, both reflect this model. See hot storage vs cold storage for the general concepts. What retention means for SIEM architecture SIEM licensing and storage costs often scale with ingest and retention. Retaining a year or more of high-volume logs in a classic SIEM deployment can be expensive. Architectures that help include: Decoupled storage, where the SIEM places warm data on object storage and keeps only a local cache on indexers, so retention can grow without adding compute. Security data lakes, which store large volumes of logs in open formats on object storage and let multiple tools query them. See what is a security data lake. Tiered retention within the SIEM, moving older data to cheaper storage while keeping it retrievable. Object storage is central to all three because it offers low cost per terabyte, scale and immutability. Protecting retained logs Retention is only useful if the logs survive. Attackers frequently try to delete or tamper with logs to hide their activity. Protections include: Immutability on stored logs, so they cannot be altered or deleted before retention expires. See S3 object lock: immutability and WORM. Separate credentials for log storage, distinct from the systems that generate logs. Integrity verification so tampering would be detected. Off-site or multi-site copies so logs survive site-level incidents. The principles are covered in storage audit trail. Deletion at end of retention Defensible deletion matters for security logs too. When retention expires, logs containing personal data should be deleted unless a legal hold applies. Automated lifecycle policies on object storage can expire data on schedule, with records kept of what was removed. See the scality.com post on S3 lifecycle policies. Estimating the storage impact Before committing to a schedule, estimate what it will cost to hold. Multiply daily ingest per log group by its retention period, apply the compression your SIEM or data lake achieves and add protection overhead on the storage platform. The results often surprise teams: verbose logs that seem harmless at 30 days can dominate capacity at a year, while high-value authentication logs may be modest in volume. This exercise usually leads to shorter retention for low-value sources and longer retention for the logs investigators actually rely on, which is both cheaper and more useful. It is also worth modeling growth. New data sources, more endpoints and expanded cloud usage tend to increase ingest every year. A schedule that fits today’s storage may not fit next year’s, so plan capacity on the storage platform with a growth margin and revisit the numbers whenever a major source is onboarded. See storage capacity planning for the method. A sample retention schedule An illustrative schedule for an organization subject to PCI DSS, with a desire to cover realistic dwell times: Authentication, EDR, network security and cloud audit logs: 90 days hot, 12 to 24 months total. Application audit logs for in-scope systems: 90 days hot, 12 months total. Verbose operational logs: 30 days hot, then deleted. Logs under legal hold: retained until released. Adjust to your regulatory obligations, risk appetite and privacy assessments. Checklist: security log retention List regulatory and contractual requirements by jurisdiction and industry. Assess privacy obligations for personal data in logs. Set retention to exceed realistic attacker dwell time. Group logs by investigative value and assign periods per group. Define hot, warm and archive tiers with clear access times. Use scalable storage, such as object storage, for long retention. Protect logs with immutability, separate credentials and integrity checks. Automate deletion at end of retention, with legal hold support. Review the schedule annually and after major incidents. Putting it together Security log retention should satisfy three tests: meet the regulatory minimum, cover the time attackers may go undetected and stay within privacy limits. Tiering lets organizations keep recent logs fast and older logs affordable, while object storage makes long retention practical and immutability keeps the evidence intact. Write the schedule down, enforce it automatically and revisit it as regulations and threats change. Frequently asked questions How long does PCI DSS require logs to be kept? PCI DSS version 4 requires at least 12 months of audit log history, with at least the most recent three months immediately available for analysis. What are the current US federal log retention requirements? OMB Memorandum M-26-14, issued in May 2026, replaced M-21-31. It sets minimum baselines of six months searchable and one year retrievable. Does GDPR limit security log retention? GDPR requires that personal data be kept no longer than necessary. Security logs can be retained for security purposes, but periods should be justified and documented. Why keep logs longer than the regulatory minimum? Attackers can remain undetected for long periods. Longer retention helps investigators trace an intrusion back to its start. Where should long-term security logs be stored? On scalable, cost-efficient storage, often object storage, with immutability to prevent tampering and lifecycle policies to delete on schedule. Further reading See security data lakes, what is SIEM and storage audit trail.
