SIEM vs XDR: Data Scope, Detection and When You Need Both

Teams weighing SIEM against XDR are usually comparing two different answers to two different questions, and buying one in place of the other leaves a gap that attackers find. A SIEM is a log platform: it collects, normalises, correlates and retains security data from anything that can produce a record, and it is where detection rules, investigations and audit evidence live. XDR is a detection and response layer built around the vendor's own sensors, usually endpoint first, then email, identity and cloud, with response actions wired in. This guide sets the two side by side as concepts, not products: what data each sees, how each detects, what each can do once something fires, and how to decide whether you need one, the other or both. It is written for SOC leads, detection engineers and security architects planning or rationalising a detection stack.

Key takeaways

• Scope is the real difference. A SIEM ingests any source you can parse, including cloud audit logs, SaaS, network devices, databases and custom applications; XDR correlates the telemetry from its own integrated sensors plus whatever third-party connectors it supports.
• XDR is response-first, SIEM is evidence-first. XDR ships tuned detections and native containment such as host isolation; a SIEM gives you long retention, search across everything and your own detection logic, but response usually runs through SOAR or other tools.
• Many organisations need both. XDR handles high-fidelity endpoint and email detection with fast containment, and the SIEM covers identity, cloud, network and application sources, compliance retention and cross-domain hunting.
• Small teams can start with XDR. Where there is no detection engineering capacity, XDR plus a basic log store gives more protection per analyst hour than a SIEM nobody tunes.
• Cost follows data volume. SIEM spend is usually driven by ingestion, so route low-value logs to cheaper storage and send the SIEM only what supports a detection, an investigation or a retention duty.

The short answer

Choose a SIEM when you must see and keep evidence from many kinds of source, write your own detections, and satisfy logging and retention obligations. Choose XDR when your main need is fast, reliable detection and containment of attacks on endpoints, email and identities, and you have few people to build and tune rules. Run both when you have the staff for it, letting XDR do first-line detection and response on its sensors while the SIEM correlates those alerts with everything else and keeps the record.

The joint guidance Implementing SIEM and SOAR Platforms, published on 27 May 2025 by the Australian Signals Directorate with CISA and partner agencies, describes a SIEM as software that collects, centralises and analyses log data from across a network, applies rules and filters, uses threat intelligence and raises alerts. It also stresses that neither platform is "set and forget": both need skilled staff, tuning and testing. XDR has no equivalent standards definition, so treat each product's scope claims as something to verify against your own source list. See the SIEM Guide and the XDR Guide for depth on each.

Side-by-side comparison

Native versus open XDR: native XDR correlates one vendor's own controls; open XDR ingests several vendors' tools and starts to resemble a SIEM with packaged detections. The closer an XDR gets to "ingest everything", the more its cost and tuning look like a SIEM's, so compare on the sources you actually need.

What each sees: mapping sources to platforms

Most real decisions come down to where each log source should land. The table below uses source groups from the ASD and partners' companion guidance Priority Logs for SIEM Ingestion, with the platform that normally handles each best.

The same guidance recommends keeping administrative and security events for at least one year and informational logs for 90 days as a starting point, adjusted to risk and regulation, and routing logs through a repository or data lake before the SIEM rather than making the SIEM the only copy. Those retention needs alone often decide that XDR cannot be the only store. See the Log Management and Retention Guide.

Each option in depth

For each option below: the threat it is built for, how it fails, the controls that make it work, when to choose it and a worked example.

SIEM

Threat model. A SIEM is designed for an attacker who moves across many data sources: identity providers, cloud control planes, SaaS audit logs, network devices and endpoints. Its value is correlation across sources that no single sensor sees. Its own threat model includes log tampering and an attacker who clears logs (T1685.005) or stops forwarding, plus loss of integrity if logs are processed before they are stored.

Failure modes. The ASD and CISA practitioner guidance warns that licensing is often based on ingestion volume, so unmanaged ingestion becomes very costly, and that failed queries returning no results can be mistaken for an absence of threats. It does not recommend SIEM-first architectures, because processing can compromise log integrity and leave only processed copies for investigation.

Controls. Send logs to a repository first and the SIEM second; secure both, ideally in a segregated monitoring enclave. Reduce ingestion at source, forwarder or SIEM, and parse only the fields needed. Name alerts consistently against ATT&CK, review rules as the threat model changes, and consider Sigma for portable detection content.

Decision criteria. Choose a SIEM as the core when you must correlate identity, cloud and SaaS events, meet retention obligations, or investigate incidents that span many systems.

Worked scenario. A finance team sees an unusual payment approval. The SIEM correlates a sign-in from a new country in the identity logs, a mailbox rule creation in the SaaS audit log and the approval in the finance application, none of which touched a managed endpoint. The investigation runs from the repository copy, so evidence integrity is preserved.

XDR

Threat model. XDR is designed for an attacker on, or moving between, the assets its sensors cover: endpoints first, then email, identity or cloud sources the product integrates natively. Its strength is deep telemetry and built-in response on those assets. Its threat model includes sensor tampering and attackers who operate where no sensor exists.

Failure modes. Coverage gaps outside the native sources; detections treated as complete because the console is quiet; and dependence on one product's data model, which narrows investigation when evidence sits elsewhere.

Controls. Alert when agents stop reporting; treat the console as a privileged system; feed XDR detections into the SIEM or repository so they sit alongside other evidence; test detection regularly against well-known techniques, as the ASD guidance recommends (for example credential dumping and DCSync).

Decision criteria. Choose XDR when endpoint attacks dominate your risk and you need fast containment with limited staff, and keep a log repository for everything XDR does not see.

Worked scenario. Ransomware precursors appear on a laptop. XDR isolates the host within minutes. The SIEM then shows the same user account signing in to a cloud console an hour earlier, which XDR did not cover, and the team revokes that session too.

Where identity fits

Both platforms now market identity detection, but the coverage differs. XDR products typically watch human sign-ins and the directory from their own identity sensors. Non-human identities, such as cloud service principals, managed identities, IAM roles assumed through STS and API tokens used by SaaS integrations, mostly show up only in cloud and SaaS audit logs, which is SIEM territory. The 2023 Microsoft Storm-0558 key breach is the clearest lesson: a customer SOC caught forged-token mailbox access with a custom alert on the MailItemsAccessed audit event, a log that an endpoint-centred stack would not have held. Put cloud identity logs in the SIEM, confirm they are actually enabled, and see the ITDR Guide.

When to use each

• SIEM first: regulated organisations with log retention and audit duties; heavy cloud, SaaS or custom application estates; teams with detection engineers; environments with many security vendors where no single XDR sees most of the attack surface.
• XDR first: small and mid-sized organisations with a mostly Windows and Microsoft 365 or Google Workspace estate; teams of a few analysts without rule-writing capacity; organisations whose main risk is ransomware and phishing on user devices.
• Both: mid-sized and large organisations where XDR handles endpoint and email detection and containment, and the SIEM ingests XDR incidents (not raw telemetry) alongside identity, cloud and network logs.
• Neither alone is enough when: nobody owns tuning and triage. The ASD guidance recommends deciding early whether to run platforms in house or through a provider; see the MDR vs MSSP comparison.

Trade-offs to weigh

Implementing a combined stack

1. Inventory sources and threats. List log sources against the attacks you most need to catch, using ATT&CK techniques, and mark each source as XDR-native, SIEM-only or both.
2. Decide the system of record. Name the platform that holds logs for investigations and audits and set retention per source class.
3. Deploy XDR in audit mode. Roll agents out in pilot rings, run detections without automatic response for two to four weeks, and record false positives per rule.
4. Forward incidents, not everything. Send XDR incidents and alerts to the SIEM; forward raw endpoint telemetry only for named hunting or detection use cases, to control ingestion cost.
5. Build SIEM detections for what XDR cannot see. Prioritise cloud control plane, identity, VPN and firewall rules, and correlation rules that join an XDR alert with sign-in or cloud activity for the same user or host.
6. Enable response in stages. Turn on XDR auto-containment for high-confidence detections first, with an exclusion list for critical servers, and document how to release an isolated host.
7. Test and keep testing. Replay known techniques (LSASS memory access, DCSync, suspicious PowerShell) and confirm each produces the expected alert in the expected platform; the ASD guidance lists these as test areas. See the Detection Validation and Testing Guide.

Rollback: keep the previous detection path running in parallel until the new one has caught the same test cases, and keep response actions in alert-only mode until rollback of each action (unisolate, restore mail, re-enable account) has been rehearsed.

Detection and measurement

• Source coverage: percentage of priority log sources reporting to the system of record, and the count of sources silent for more than 24 hours.
• Technique coverage: ATT&CK techniques in your threat model with at least one tested detection, split by platform.
• Alert quality: true positive rate per rule and per XDR detection category, reviewed monthly.
• Time to contain: median time from first alert to containment, for XDR auto-response versus manual actions.
• Duplicate alerting: share of incidents raised by both platforms and triaged twice.
• Cost per useful source: ingestion spend for each source against the detections and investigations it supported.

Watch the platforms themselves too: alert when agents stop reporting or audit logs are cleared (Security 1102, mapped to T1685.005 Clear Windows Event Logs), and protect both consoles as privileged systems. See Securing the SIEM itself and Securing the EDR and XDR platform itself.

Common failure patterns

• Treating XDR as a SIEM replacement and losing cloud, SaaS and network evidence, then discovering during an incident that sign-in and audit logs were never collected or were kept for only weeks.
• Forwarding all XDR telemetry into the SIEM, doubling cost without new detections and burying analysts in duplicate alerts.
• A SIEM with no detection owner, collecting logs but running only default rules, so alerts are either noisy or absent.
• Trusting empty results. The ASD guidance warns that a failed query can look like "nothing to report"; check parsers and source health before closing a hunt.
• Baselining during an intrusion, so attacker activity becomes "normal"; validate baselines with a hunt before relying on them.
• Turning on auto-isolation everywhere at once and taking production servers offline on a false positive.

Framework mapping

Decision checklist

• Which log sources must you retain for a year or more, and can the candidate platform hold them at acceptable cost?
• What share of your attack surface is covered by one vendor's sensors?
• Do you have people who will write, test and retire detection rules every month?
• Which response actions must happen in minutes, and who approves them?
• Where do cloud and SaaS non-human identity logs land?
• If you change vendors, can you take your rules and data with you?

Practitioner checklist

• Map every priority log source to SIEM, XDR or both, and name the system of record.
• Set retention per source class, starting from one year for security events and 90 days for informational logs.
• Forward XDR incidents to the SIEM and limit raw telemetry forwarding to named use cases.
• Write SIEM detections for cloud, identity, VPN and firewall activity that XDR does not see.
• Pilot XDR auto-response in alert-only mode, then enable it for high-confidence detections with critical-server exclusions.
• Alert on silent sources, stopped agents and cleared logs on both platforms.
• Test detections quarterly against known techniques and record which platform fired.
• Review ingestion cost against detection value every quarter and move low-value logs to cheaper storage.

Standards and references

• ASD's ACSC: Implementing SIEM and SOAR Platforms, Executive Guidance
• ASD's ACSC: Implementing SIEM and SOAR Platforms, Practitioner Guidance
• ASD's ACSC: Priority Logs for SIEM Ingestion, Practitioner Guidance
• CISA: Guidance for SIEM and SOAR Implementation
• NIST: SP 800-92 Rev. 1 (Initial Public Draft), Cybersecurity Log Management Planning Guide
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• MITRE ATT&CK: T1685.005 Clear Windows Event Logs
• OCSF: Open Cybersecurity Schema Framework

Related NHI Mgmt Group resources: SIEM Guide · XDR Guide · SOAR vs SIEM · EDR and XDR Buyer's Guide · SOC Guide