SIEM Log Retention Calculator
Work out how many days of logs a given storage budget actually buys, and whether it clears your compliance retention floor.
About SIEM Log Retention Calculator
Compression and index overhead pull in opposite directions: 8× compression on a payload that carries 25% index overhead nets an effective 0.156× of raw bytes per copy, which two replicas then double. Dividing available capacity by that daily figure gives the honest retention window. PCI DSS wants a year with 90 days immediately available, and most regulators want more — discovering your 'twelve-month' SIEM only holds seven months of data during an investigation is a very expensive surprise.
Formulas
SIEM Log Retention
Stored GB/day = raw GB/day × (1 + index overhead) ÷ compression ratio × replicas; retention days = usable TB × 1,000 ÷ stored GB/day.
- index overhead
- Extra bytes for the searchable term index, 10–35%
- compression ratio
- 6–10× is typical for text logs
- replicas
- Copies kept for durability and search parallelism
Policy shortfall
Storage for policy = stored GB/day × required days ÷ 1,000; shortfall = that figure minus usable TB.
- required days
- Retention floor set by policy or regulation
- usable TB
- Capacity after filesystem and cluster reserve
Worked example
With the default values below, SIEM Log Retention Calculator returns Retention Achievable of 738. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Raw ingest per dayaccepts 0–1,000,000 GB/day
- 520 GB/day
- Usable storage availableaccepts 0–100,000 TB
- 120 TB
- Compression ratioone of No compression — 1×, Conservative — 6×, Typical text logs — 8×, Aggressive columnar — 10×, Best case, highly repetitive — 12×
- Typical text logs — 8×
- Search index overheadaccepts 0–100 %
- 25 %
- Replica copies (including primary)accepts 1–6 copies
- 2 copies
- Required retention (policy or regulation)accepts 1–3,650 days
- 365 days
Results
- Retention Achievable
- 738 days
- Storage Consumed per Day
- 162.50 GB/day
- Storage Needed for Policy
- 59.31 TB
- Shortfall Against Policy
- 0.00 TB
- Effective Bytes-Stored Ratio
- 0.313 × raw
- Compliance Verdict
- Compliant with room to extend retention or add sources
Step by step
- 1Values used
- 2SIEM Log Retention
- 3Policy shortfall
- 4Retention Achievable= 738 days
- 5Storage Consumed per Day= 162.50 GB/day
- 6Storage Needed for Policy= 59.31 TB
- 7Shortfall Against Policy= 0.00 TB
- 8Effective Bytes-Stored Ratio= 0.313 × raw
- 9Compliance Verdict= Compliant with room to extend retention or add sources
Assumptions and limits
- The result is derived only from the 6 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 3 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
How is SIEM Log Retention calculated?
Stored GB/day = raw GB/day × (1 + index overhead) ÷ compression ratio × replicas; retention days = usable TB × 1,000 ÷ stored GB/day. Compression and index overhead pull in opposite directions: 8× compression on a payload that carries 25% index overhead nets an effective 0.156× of raw bytes per copy, which two replicas then double. Dividing available capacity by that daily figure gives the honest retention window.
Why does SIEM Log Retention matter?
PCI DSS wants a year with 90 days immediately available, and most regulators want more — discovering your 'twelve-month' SIEM only holds seven months of data during an investigation is a very expensive surprise.
What values do I need to enter?
This calculator takes 6 inputs: Raw ingest per day, Usable storage available, Compression ratio, Search index overhead, Replica copies (including primary), Required retention (policy or regulation). The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Can I count cold object storage towards retention?
Yes for compliance, usually not for detection. Regulators care that the data exists and is retrievable; correlation rules and hunts only see what is in hot or warm tiers, so track searchable retention and retained retention as two separate numbers.
Do replicas really double my storage?
For index-replicated platforms, yes — a replication factor of 2 stores every byte twice. Object-store-backed architectures instead rely on the store's own erasure coding, which typically costs 1.2–1.5× rather than 2×.