Newsletter Article
Retention Is Not Ingestion
Snare Insider Newsletter Series Article
Make sure you Subscribe
The gap between the alert and the answer
That distinction surfaces repeatedly across this week’s InfoSec World and CyberCon programs.
InfoSec World’s From Alert to Evidence session opens with a line every SOC lead will recognise: security tools can generate a high-confidence alert in seconds.[1] Determining what actually occurred — how the attacker got in, how far the activity spread, which systems and data were affected — can still take hours or days. A Threat Summit session, From Chasing Alerts to Understanding Attacks, traces one organisation’s move from reactive alerting to kill-chain-aware detection, built on better visibility and contextual investigation.[2] At CyberCon, sessions on incident pre-mortems and security architecture “whodunits” ask the same question from the response side: when an incident is reconstructed after the fact, where do the gaps turn out to be?[3]
The industry data points the same way. IBM’s Cost of a Data Breach Report 2025 puts the mean time to identify and contain a breach at 241 days — a nine-year low, but still the better part of a year.[4] Mandiant’s M-Trends 2026 reports a global median dwell time of 14 days, up from 11, rising to a median of 122 days for cyber-espionage intrusions. It also reports that the median time between initial access and hand-off to a secondary threat group fell from more than eight hours in 2022 to 22 seconds in 2025.[5]
Attackers are moving faster. Investigations still have to look back further.
This is fundamentally an evidence problem.
What the guidance actually says
In 2025, Australia’s ASD’s ACSC, the US CISA and international partners published a set of joint guidance on implementing SIEM and SOAR platforms. It’s some of the most practical vendor-neutral advice available on the economics of security logging, and its principles apply globally.
On cost, the practitioner guidance is direct: “Most SIEM pricing models are based on the quantity of logs ingested by the platform,” and where licensing places no cap on ingestion, organisations “should be mindful of the potential to incur very significant costs if ingestion is not carefully managed.” It also notes that some platform default settings will tend to increase the quantity of logs ingested.[1]
On retention, the same guidance recommends implementing a log retention and archiving policy — at a minimum, one year for logs that record administrative and security-related events, and 90 days for informational logs used to contextualise other events.[1]
And the companion Priority Logs for SIEM Ingestion guidance draws the line between the two explicitly. It recommends a threat-led approach to what enters the SIEM, discourages “logging for the sake of logging” — and states that the authoring agencies “strongly discourage using a SIEM as the central repository for all logs.” A SIEM, it says, “should only be used for centralisation of specific security logs according to the organisation’s risk profile.”[2]
That’s a significant statement from some of the world’s leading cyber agencies. It says, in effect, that the SIEM is an analytics platform — and that the organisation’s evidence needs a home of its own.
Not every retained event needs to be a continuously ingested SIEM event
High-value security events justify immediate SIEM ingestion because they contribute directly to detection and monitoring: authentication failures and anomalies, privilege changes, security-control tampering, EDR detections, high-risk cloud control-plane actions.
Other events have significant forensic or compliance value but comparatively little value in continuous real-time analytics: verbose process and file activity on low-risk systems, routine allowed network flows, informational application logs, high-volume DNS. The Priority Logs guidance itself notes that the volume of firewall or DNS logs “may overshadow the importance of the information received.”[2]
Those events still matter. When an investigation reaches back 60 or 90 days to establish initial access, they may matter a great deal. They just don’t all need to be parsed, indexed and correlated in your most expensive tier every second of every day.
The architecture therefore becomes a question of data placement:
| Placement decision | Typical evidence | Where it lives |
| Detect — needs immediate correlation and alerting | Authentication anomalies, privilege changes, security-control events, high-risk cloud actions | SIEM / real-time analytics |
| Search — needs fast, ad hoc retrieval | Recent endpoint, identity and network activity used for triage and hunting | Searchable log store or warm tier |
| Retain — needs long-term forensic and compliance availability | Full-fidelity security and administrative events | Integrity-protected archive |
| Replay — needs analytics only when an investigation requires it | Historical evidence for a specific timeframe, host or identity | Retained store, routed back into analytics on demand |
| Reduce — can be aggregated or de-duplicated for analytics | Repetitive, high-volume, low-variance events | Summarised or de-duplicated before forwarding to the SIEM; raw events retained in full for forensic use |
| Retire — no longer provides sufficient security value | Debug-level noise, duplicate feeds, data with no investigative use | Not collected, or expired by policy |
Your evidence should survive a SIEM decision
There’s a second architectural benefit that is easy to miss when the conversation is only about cost.
Organisations change SIEMs. They consolidate vendors. They move workloads to new clouds. They change MSSPs. They introduce new analytics and AI capabilities alongside the SIEM they already have.
The historical evidence required for security investigations shouldn’t disappear — or become expensive to move — simply because the analytics platform changes. When the SIEM is the only place evidence lives, the organisation’s investigative history becomes a dependency on that one platform, and every future platform decision carries an evidence-migration cost of change.
That makes the collection layer strategically important. Logs should be capable of being collected, normalised, retained and routed independently of the destination that happens to analyse them today. This isn’t an argument against the SIEM; it’s what allows the SIEM to do its job well, and allows an organisation to add a second analytics destination, run a parallel migration, or onboard a new MSSP without re-collecting its own history.
It gives security teams another option whenever requirements change:
route the evidence somewhere else.
Five steps to separate retention from ingestion
- Classify sources by purpose. For each log source, record whether it’s needed for detection, search, retention or not at all — using the threat-led approach in the ASD’s ACSC and CISA guidance.
- Set retention by evidence class, against regulatory requirements and realistic dwell times, not SIEM licence tiers.
- Filter and route at the collection layer, so decisions about what reaches the SIEM are made before ingest rather than after, while a full copy of every event is still retained.
- Retain full-fidelity evidence independently, with integrity protection and a documented path to replay it into analytics when needed.
- Test the replay path. Retrieve 90-day-old evidence for a single identity and load it into your analytics platform. If that takes days, your retention isn’t yet investigation-ready.
Where Snare fits
Snare is designed as that independent collection and evidence layer.
Snare Agents collect endpoint and server events at source; identity, cloud, SaaS and network sources feed Snare Central directly via syslog, API and cloud audit feeds.
Snare Central retains a complete copy of that evidence for search, reporting and forensic investigation, independently of any analytics platform.
Snare Reflector routes selected events to the SIEM and other destinations based on the organisation’s own rules. Filtering shapes what each destination receives, not what is kept.
Snare works alongside existing SIEM investments: the SIEM keeps doing detection, and the organisation keeps control of its evidence.
Key takeaway
Retaining security evidence and continuously ingesting it into a SIEM are different decisions.
Treating them separately can improve both investigative readiness and cost control.
Go deeper: AI Ready Checklist explains how to decide what to collect, what to retain, what to ingest into your SIEM, and how to maintain forensic visibility without treating every log as an expensive real-time analytics event.
References
- ASD’s ACSC, CISA et al., Implementing SIEM and SOAR Platforms: Practitioner Guidance, May 2025, Section 4 (Principles 4 and 7): https://www.cyber.gov.au/sites/default/files/2025-05/implementing_siem_and_soar_platforms_-_practitioner_guidance.pdf
- ASD’s ACSC, CISA et al., Priority Logs for SIEM Ingestion: Practitioner Guidance, May 2025: https://media.defense.gov/2025/May/27/2003722069/-1/-1/0/PRIORITY-LOGS-FOR-SIEM-INGESTION-PRACTITIONER-GUIDANCE.PDF
- PCI Security Standards Council, Payment Card Industry Data Security Standard (PCI DSS) v4.0.1, June 2024, Requirement 10.5.1: https://www.pcisecuritystandards.org/document_library/
- Mandiant (Google Cloud), M-Trends 2026, 23 March 2026: https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026
- IBM Security, Cost of a Data Breach Report 2025. Reported in Help Net Security, 4 August 2025: https://www.helpnetsecurity.com/2025/08/04/ibm-cost-data-breach-report-2025/
- CISA, “Guidance for SIEM and SOAR Implementation” (series overview): https://www.cisa.gov/resources-tools/resources/guidance-siem-and-soar-implementation
