SIEM vs Log Management: When Correlation Justifies the Cost

Many organisations pay SIEM prices to store logs nobody queries, while others keep every log in a cheap store that never raises an alert, and both end up blind in different ways. Log management collects, stores, searches and disposes of log data; a SIEM adds normalisation, correlation across sources, detection rules, alerting and case handling on top. The question is not which is better but which security outcomes you need, which logs feed them and what each outcome is worth paying for. This guide compares the two as concepts, sets out the decision criteria (detection use cases, retention and compliance duties, team size and ingest cost), the controls each option needs, the ways each fails, and the tiered hybrid that most mature teams end up running. It is written for SOC leads, detection engineers, security architects and the budget holders who sign off ingest licences. Platform depth is in the SIEM Guide and the Log Management and Retention Guide; this page is about choosing between them and splitting data across them.

Key takeaways

• Log management is about keeping and finding evidence. NIST SP 800-92 Rev. 1 (Initial Public Draft) defines log management as generating, transmitting, storing, accessing and disposing of log data; it does not, by itself, watch for attacks.
• A SIEM earns its cost through correlation and alerting. If you have no detection use cases that need events from several sources joined in near real time, a SIEM will mostly be a costly log bucket.
• Do not use the SIEM as a log centraliser. The joint ASD and partner practitioner guidance on SIEM and SOAR says high-volume consumption is more likely when the SIEM is used mainly to centralise logs, and that it should not be used for that purpose when the goal is compliance or audit.
• Retention and detection have different homes. Keep security-relevant logs for at least a year (the joint guidance's suggested starting point for administrative and security events), but send the SIEM only what a rule, hunt or investigation needs at speed.
• Route, do not choose. A pipeline that sends each source to the cheapest tier that still serves its purpose lets one estate run both, with the log store as system of record and the SIEM as the detection layer.

The short answer

Log management alone is enough when your needs are evidence retention, audit, troubleshooting and occasional investigation, and when detection is already handled elsewhere (for example by an EDR or XDR product, or a managed detection service watching its own telemetry). Add a SIEM when you need detections that join events across identity, endpoint, cloud, network and SaaS sources, alerting with triage and case records, and somebody to build and tune those detections. The joint executive guidance published on 27 May 2025 by the Australian Signals Directorate with partner agencies is plain that neither a SIEM nor a SOAR is a "set and forget" tool, that both need highly skilled staff, and that most SIEM pricing is based on the quantity of data ingested. If you cannot staff detection engineering, buy outcomes (managed detection, XDR) and keep a good log store; do not buy a SIEM and hope.

Side-by-side comparison

Each option in depth

Log management

Threat model: the attacker you worry about is the one you discover later, through a third party, a customer complaint or a regulator, and the question is whether you can reconstruct what happened. Attackers also target the log store itself: clearing event logs (ATT&CK T1685.005 Clear Windows Event Logs) and abusing valid accounts (T1078) to blend in. Architecture in words: agents or forwarders ship logs from hosts, network devices, cloud audit services and applications to a central store; an index supports search; older data moves to cheaper storage with lifecycle rules; access is restricted and integrity protected. Controls: a logging policy that says what is logged, where and for how long; consistent time sources (NIST SP 800-53 AU-8 Time Stamps); protection of audit information (AU-9) with write-once storage where possible; retention per AU-11; storage capacity monitoring (AU-4); and alerts on gaps in collection. The NIST SP 800-92 Log Management Guide covers the planning playbook.

Failure modes: no one reviews anything, so detection depends on luck; parsing is skipped, so searches miss fields; retention is set by default rather than by your detection time; and log sources quietly stop sending. Worked scenario: a 300-person professional services firm runs EDR with a managed detection service and Microsoft 365. It ships firewall, VPN, identity provider and cloud audit logs to a log store with 13 months of retention and a few threshold alerts (collection gaps, admin role grants). When a partner's mailbox is abused, the MDR provider spots the endpoint side, and the firm's log store supplies the sign-in and mailbox audit trail for the investigation and the regulator. A SIEM would add little here because nobody would write or tune its rules.

SIEM

Threat model: attackers who move across domains, for example a stolen session token used from a new location, a new OAuth consent, mass file downloads and a cloud key created minutes later. No single source shows the attack; the sequence does. The NCSC's SOC guidance makes the same point: real attacks often trigger several detections, and combining lower-severity alerts can help catch sophisticated actors. Architecture in words: collectors feed a parsing and normalisation layer (the joint guidance gives the example of aligning field names such as src_ip and sourceAddress and aligning timestamps across time zones); a detection engine runs correlation and scheduled rules; enrichment adds asset, identity and threat intelligence context; alerts become incidents with case records; and SOAR handles repeatable response. Controls: a use case register tied to your threat model, detection as code with testing, segmented indexing to restrict analyst access to data sources (as the joint guidance suggests), SIEM administrator access under privileged access management, and health monitoring of every source. See the Securing the SIEM itself page.

Failure modes: every log ingested "just in case" so cost outruns value; rules copied from a vendor pack with no tuning, so analysts drown; no owner for content, so rules rot as sources change schema; and the SIEM's own accounts become a privileged target. Worked scenario: a 4,000-person insurer has its own SOC of eight analysts and two detection engineers, multiple clouds and a large SaaS estate. Its priority detections join identity provider risk signals, cloud control plane events and SaaS audit logs, so a SIEM with normalised identity fields is justified. Its firewall and DNS volumes, by contrast, go to a cheaper tier with summary data forwarded to the SIEM. The Microsoft Storm-0558 Key Breach shows the value of the pattern: a government SOC detected anomalous mail access through a custom alert built on mailbox audit events it was licensed to collect.

Decision criteria

Small vs large organisations: small organisations usually get more protection per pound from EDR or XDR with a managed service plus a well-run log store. Mid-sized organisations often add a SIEM for identity, cloud and SaaS detections only. Large and regulated organisations run both, with explicit routing rules and a content team. See SIEM vs XDR for the detection-layer choice.

Routing logs by purpose

The joint practitioner guidance recommends making security the primary focus with SIEM ingestion limited to security feeds, using data lakes or alternative storage for logs with no security value, and "cold storage" that holds logs until a query needs them. In practice that means deciding per source what it is for, then where it goes. The live SIEM guide sets out the tiers; the table below is the routing decision that sits in front of them.

A dedicated pipeline layer makes this routing maintainable: parse once, drop unused fields, enrich, then fan out to several destinations. See the Security Data Pipeline Guide and the Security Data Lake Guide; for a common schema across destinations see the OCSF Guide.

The tiered hybrid pattern

Most mature estates end up with three layers, each with its own controls:

• System of record: a log store or lake holding all security-relevant logs for the full retention period, immutable where possible, with access limited to investigators and auditors. This is where retention duties are met.
• Detection layer: the SIEM, holding a hot window (often 30 to 90 days) of the sources its rules and hunts actually use, with normalised fields and enrichment.
• Response layer: SOAR or case management fed by SIEM alerts, with the ability to query the system of record during an investigation.

Two design rules keep the hybrid honest. First, a source only enters the SIEM with a named use case, hunt or investigation need; review the list each quarter and demote sources that no rule uses. Second, the system of record must be searchable within your incident time targets, or investigators will push for everything to go back into the SIEM.

Implementing or rebalancing

1. Write the use case register first: list the threats you must detect, mapped to ATT&CK where useful, and for each the sources and fields needed. Use cases without a source gap analysis are wishes.
2. Set retention by duty and detection time: the joint guidance says retention must accommodate your mean time to detect; record legal and contractual minimums per source.
3. Stand up the system of record: central collection, time synchronisation, integrity protection and access control, with collection-gap alerts from day one.
4. Add the pipeline: parse and normalise once, tag each event with its destination, and start in mirror mode, sending to both old and new destinations until you have compared results.
5. Onboard SIEM sources in priority order: identity, cloud control plane, EDR alerts, SaaS audit, then network summaries. Use the SIEM Log Source Onboarding Checklist.
6. Deploy detections in test mode: run new rules silently against live data, measure false positives, tune, then enable alerting. Keep the previous rule version for rollback.
7. Demote low-value sources: once a source is in the system of record and no rule uses it, stop SIEM ingestion, watching for any broken dashboard or hunt before cutting over fully.
8. Exercise it: the joint guidance recommends exercises that test SIEM and SOAR performance; run a purple team scenario and an evidence retrieval drill against the system of record.

For a full rollout see the SIEM rollout playbook; for a platform change see the SIEM Migration Guide.

Where identity fits

Identity logs carry the highest detection value per GB in most estates, and machine identities are a growing share of them: service principals, workload identities, API keys and OAuth applications signing in without a human. Their sign-ins and permission changes belong in the SIEM with identity enrichment, while the access to the logging platforms themselves (forwarder credentials, API tokens used by the pipeline, SIEM service accounts) needs the same rotation and least privilege as any other privileged non-human identity. See Detection Engineering for Non-Human Identities.

Detection and measurement

• Detection cost per use case: SIEM ingest and licence cost divided by active, tested use cases. A rising figure with flat use cases signals a log bucket.
• Ingest utilisation: share of SIEM-ingested volume referenced by at least one rule, hunt or dashboard in the last 90 days.
• Source health: percentage of required sources reporting within their expected interval, from collection-gap alerts.
• Use case coverage: share of priority threats with a tested detection, mapped to ATT&CK.
• Evidence retrieval time: time to answer a standard investigation question from the system of record.
• Alert precision: true positive rate per rule, used to retire or tune noisy content. See the Alert Fatigue Reduction Guide.

Common failure patterns

• SIEM as an expensive log bucket: every source ingested for retention, ingest cost consumes the budget, and detection content never gets built.
• Log store with no alerting: logs are complete but nobody looks until after an incident, so dwell time is set by the attacker or a third party.
• Retention by default: platform default retention is kept, and the investigation needs data from before it.
• Silent source loss: a forwarder breaks or an API token expires and nothing alerts, so the SIEM looks quiet because it is blind.
• Licence-gated logs assumed present: a security event is only recorded at a higher licence tier, as the Storm-0558 case showed for mailbox access auditing at the time.
• Unprotected log platform: broad analyst access to all indexes and long-lived pipeline tokens make the logging estate a target. The joint guidance asks that the repository be secured for integrity and confidentiality.

Framework mapping

The ISO/IEC 27001:2022 Annex A equivalents are A.8.15 Logging and A.8.16 Monitoring activities. See also the CIS Control 8 Audit Log Management Guide and the OMB M-21-31 Logging Maturity Guide.

Decision checklist

• Have we written detection use cases that need events from more than one source type?
• Do we have people to build, test and tune detections, and to work the alerts they raise?
• Is our retention set by legal duty and mean time to detect, not by a platform default?
• Does every SIEM source have a named use case, and is everything else in a cheaper tier?
• Can investigators search the system of record within our incident time targets?
• Would managed detection or XDR plus a log store meet our needs at lower cost and staffing?

Practitioner checklist

• Maintain a use case register with required sources and fields for each detection.
• Define retention per source from legal, contractual and detection-time requirements.
• Keep a single system of record for all security-relevant logs, immutable where possible.
• Route sources through a pipeline that parses once and sends each to the cheapest suitable tier.
• Alert on collection gaps for every required source, in both the SIEM and the log store.
• Test new detections silently before alerting, and keep prior versions for rollback.
• Restrict index access by role and protect forwarder and pipeline credentials.
• Review SIEM ingest each quarter and demote sources no rule uses.

Standards and references

• NIST: SP 800-92 Rev. 1 Cybersecurity Log Management Planning Guide (Initial Public Draft)
• ASD: Implementing SIEM and SOAR Platforms, Executive Guidance
• ASD: Implementing SIEM and SOAR Platforms, Practitioner Guidance
• OMB: M-21-31 Improving the Federal Government's Investigative and Remediation Capabilities
• CISA: Best Practices for Event Logging and Threat Detection
• NCSC: Building a Security Operations Centre, Detection practices
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: SIEM Guide · Security Data Lake Guide · NIST SP 800-92 Log Management Guide · SIEM rollout playbook · Detection as Code Guide