What is the difference between SIEM, SOAR and XDR?

They answer three different questions. A SIEM collects and normalises telemetry from across the estate and applies detection rules to it, so it optimises for breadth of coverage. XDR correlates across a narrower set of telemetry that one vendor's sensors produce, and ships its detection content with it, so it trades breadth for depth and for less tuning work. SOAR takes a case that has already been triaged and executes the response through codified playbooks. Buying one does not remove the need for what the others do.

Do you need XDR if you already have a SIEM and EDR?

Not automatically, and the honest answer depends on which job you are currently doing badly. If your problem is that endpoint, identity and email signals never get connected to each other, XDR addresses exactly that. If your problem is that you cannot see a critical system at all because it sits outside any vendor's sensor coverage, XDR will not help and a SIEM will. If your problem is that triaged cases sit in a queue for hours before anyone acts, neither one is the answer and SOAR is.

Does SOAR replace security analysts?

No, and treating it as a headcount argument tends to produce a disappointing deployment. SOAR removes the repetitive execution work of response, the same five commands typed for the same case type, so that analyst attention goes to investigation and judgement instead. What it genuinely changes is the time between a decision and the containment action that follows it. An organisation that automates a response process it has never written down usually finds it has automated the confusion.

Why do these tools produce so many false positives?

Because detection rules are written to be inclusive on purpose. A rule tuned to catch variants of a technique will fire on benign activity that resembles it, and that is treated as an acceptable cost of not missing the real thing. The burden of separating genuine from spurious is then transferred to the analyst. Volume alone is survivable; volume combined with a poor signal-to-noise ratio is what erodes attention and lets real incidents sit unread.

What should you fix first if the security operations queue is unmanageable?

Establish what your current detection and response times actually are before buying anything, because every one of these categories is sold against those numbers and you cannot evaluate a claim without a baseline. Then find out which telemetry sources you are deliberately not collecting because of ingestion cost. Those two answers usually reveal whether the real problem is coverage, correlation or execution, and that determines which category is worth a shortlist at all.

SIEM vs SOAR vs XDR in Plain English

A security operations team that misses an incident rarely missed the alert. It received the alert, ranked it among thousands of others that looked much the same, and closed it. The platform decision that follows gets made once and lived with for years, and the three categories that turn up on the shortlist answer three different questions.

The alert problem all three are answering

Rule-based detection at scale produces more alerts than any team can read. Detection rules are written to be inclusive by design: a rule tuned narrowly enough to eliminate false positives will also miss the variant you cared about, so false positives are accepted as the price of coverage. The cost of that trade is transferred, whole, to whoever reads the queue.

Volume on its own is survivable. Volume combined with a poor signal-to-noise ratio is not, because it changes behaviour. Analysts develop fast heuristics for dismissing categories of alert that have historically been benign, and those heuristics inevitably catch some true positives too. The people most exposed to this are usually the least experienced and the most likely to leave the role inside eighteen months, so the queue grows faster than the experience available to work it.

What this costs the organisation is dwell time, the interval between an attacker getting in and anyone noticing. NIST SP 800-61 frames incident handling around exactly that interval, and it is the number that turns a contained event into a disclosed one. Every category below is sold as an answer to this problem, from a different end of the pipeline.

What SIEM, XDR and SOAR each actually do

A SIEM is the collection and detection layer. It ingests events from endpoints, network devices, cloud services, applications and identity platforms, normalises them into a common shape, and runs detection rules across the result. Its defining property is that it is neutral about where data comes from, which is why it remains the only one of the three that can see a system nobody else instruments.

XDR is the correlation layer, and it makes the opposite trade. Rather than ingesting anything, it works across a narrower set of telemetry that one vendor’s own sensors produce, typically endpoint, identity, email and network, and ships its detection content already written. Because it controls both the sensors and the logic, it can connect signals that would otherwise sit in separate queues: the password-spray attempt against an account, the successful authentication from an unfamiliar location two hours later, and the unusually large file-share download that follows.

That connection is worth naming precisely, because it is where the categories are most often confused. Aggregation collapses fifty identical alerts from one host into a single record with a count of fifty. It is useful and needs no machine learning. Correlation infers that alerts on different hosts, of different types, are one campaign, and presents them as a single case with a timeline attached. Only the second requires a model of how alerts relate to one another.

SOAR is the response layer, and it starts where the other two finish. It takes a case that has already been triaged and runs codified workflows against it: isolate the host, disable the account, revoke the token, open the ticket, record the trail. Orchestration is the coordination across systems, automation is the execution without a human typing, and response is the containment itself.

The three categories side by side

	SIEM	XDR	SOAR
Question it answers	What happened anywhere in the estate?	Are these separate alerts one campaign?	What do we do about this case?
Ingests	Anything that emits a log	Telemetry from its own sensors	Triaged cases, not raw events
Produces	Normalised events and raw alerts	Scored cases with evidence attached	Executed actions and an audit trail
Detection content	You write and tune it	Ships with the product	Not its job
Typically priced on	Data ingestion volume	Endpoints or identities covered	Playbook or action volume
Blind spot	Signal it was never sent	Anything outside its sensors	A response process nobody wrote down

The row that decides most shortlists is the last one. Each category has a failure that its own dashboard cannot show you.

Where each category disappoints

A SIEM becomes an expensive log archive. Ingestion-based pricing creates a perverse incentive to collect less of exactly the verbose endpoint and cloud telemetry that carries the most useful signal, and the saving is invisible until an investigation needs the data nobody kept. The other half of the problem is human: default detection content is a starting point, and organisations routinely underinvest in the correlation rule development that turns a SIEM into a detection capability rather than a search box.

XDR’s correlation is only as good as the telemetry it owns. A campaign that touches a system outside the vendor’s sensor coverage is a campaign it cannot correlate, and the resulting picture is confident and incomplete, which is worse than obviously partial. You have also swapped tuning effort for vendor dependency: the detection content improves without your effort, and it changes without your approval.

SOAR automates whatever process you already have, including a bad one. Two failure modes matter to a CISO specifically. The first is auto-closure without auditability: if low-confidence cases are closed automatically and there is no record of the input, the score and the rationale, then nobody can reconstruct the decision when a breach is later traced back to a closed alert. The fix is logging the reasoning, not removing the automation. The second is concentration: a team that has delegated triage to one engine has a single point of failure, and needs a manual procedure it actually rehearses rather than one that exists in a document.

Two problems sit underneath all three. An attacker who understands where the thresholds are can shape a campaign so each individual signal stays below them, which is the operational form of the evasion techniques catalogued in MITRE ATT&CK. And any correlation model degrades as the estate, the adversary and the alert catalogue change, so accuracy is a thing you maintain rather than a thing you buy. The same discipline that applies to watching a model in production applies here.

The number you actually own

You do not own the model. Whether the correlation logic is a vendor’s, a managed service’s or your own, its internals are usually not available to you and would not help if they were. What you own is the acceptable false-negative rate that model is permitted to produce, and that is a risk-appetite decision rather than a technical one.

Everything downstream follows from that figure: where the auto-closure threshold sits, which severities require a human before an action executes, how often the model is retrained, what a vendor is contractually obliged to report, and what the team does on the day the engine is unavailable. Accountability for the misses does not transfer with the function, even when the function is outsourced. This is also why explainability matters more here than the marketing suggests: an analyst who cannot see why a case scored the way it did will either accept every output uncritically or ignore the system entirely, and both are expensive.

It follows that alert volume is the wrong metric to report upward. A reduction in alerts produced by an engine quietly closing real incidents is a regression that looks like a win on a slide. Detection time, response time and the age of the oldest open case are defensible; queue length is not.

Questions to ask before you shortlist

What are our current detection and response times, and do we know them or estimate them? Every one of these products is sold against those numbers, and a claim cannot be evaluated without a baseline.
Which telemetry sources are we deliberately not collecting, sampling or truncating because of ingestion cost, and which of them would have carried evidence in our last three incidents?
When the correlation engine closes a case automatically, what is recorded? Ask to see the input, the score and the rationale for a specific closed case, not a description of the feature.
Who owns the auto-closure threshold, when was it last changed, and what evidence supported the change?
What is the documented procedure when the engine is unavailable, and when did the team last rehearse it rather than read it?
For anything outsourced: what false-negative rate are we accepting, how would we find out we had exceeded it, and what is the vendor obliged to tell us?

Before the next vendor conversation, list every telemetry source currently dropped, sampled or truncated to control cost, and mark which of them would have held evidence in your last three incidents. It is an afternoon’s work and it will tell you whether your real problem is coverage, correlation or execution.

A quieter queue is only a win if you can show nothing was lost in making it quiet.