In tenders and vendor conversations, SIEM, SOC, MDR and XDR usually appear side by side, as if they were four competing products you pick one of. That’s why those selection processes go wrong so often.
The three central terms aren’t even the same kind of thing:
- SIEM is a technology: a system you run, or have run for you.
- SOC is a function: people and processes doing something with what the technology produces.
- MDR is a delivery model: how you buy both instead of building them.
Putting the three head to head compares an engine with a garage and a lease agreement. All three relate to driving. You don’t pick one of them.
SIEM: the machine
A Security Information and Event Management platform collects log data from endpoints, identity systems, network, cloud platforms and applications, normalizes it, and correlates it into alerts.
What a SIEM delivers:
- Centralization: one place where an attack’s trail converges across system boundaries
- Correlation: linking individual events into a chain no single system sees
- Retention: the data basis for investigation and for evidentiary obligations
- Alerting: the handover point to a human
What a SIEM does not deliver: decisions. A SIEM produces alerts. Whether an alert is an incident, whether it escalates, and what happens next are not questions a rule answers.
Hence the sentence we say in projects so often that it made it onto our Managed SIEM / SOC page: a SIEM without analysts is a very expensive alarm nobody answers.
SOC: the people
A Security Operations Center is not software, and not a room with screens. It’s a function: the team and processes that triage, investigate, escalate and answer incoming alerts.
Typically that covers:
- Triage: is this a real finding or a false positive?
- Investigation: what actually happened, how far did it get, what is affected?
- Escalation: who in the organization needs to know, and when?
- Response: contain, isolate, drive remediation
- Threat hunting: proactively looking for what no rule exists for yet
Why an in-house SOC rarely fails on headcount budget, but on arithmetic
A week has 168 hours. At a 40-hour week, it takes 4.2 people on paper to keep a single seat continuously staffed. Add vacation, sickness, training and attrition and you land realistically at five to six full-time staff: for exactly one position covered around the clock.
And one position means: a single person alone on night shift, with no second pair of eyes and no escalation partner. Anyone who wants genuine 24/7 coverage at defensible quality is budgeting a multiple of that.
Then there’s the part you can’t hire: experience. An analyst doesn’t become good through certifications, but by having seen hundreds of alerts and knowing which of them look like an incident and aren’t.
That’s exactly where the market for outsourced models comes from.
MDR: the delivery model
Managed Detection and Response means a provider supplies technology, team and processes and delivers detection and response as a service. The customer buys an outcome instead of a platform.
That’s a sound model, but the term is unregulated, and the range of what gets sold as “MDR” is enormous. Two questions separate the offerings:
1. What telemetry is the detection based on? Many MDR offerings are fundamentally EDR-centric: they see what happens on endpoints extremely well, and little to nothing of identity abuse, cloud configuration changes or the application layer. For an attack that runs through compromised credentials and Microsoft 365 without ever dropping code on an endpoint, that’s a relevant gap.
2. What exactly does “response” mean in the contract? That’s the question hiding the biggest differences.
The one contract question that really matters
“Response” is sold at at least three completely different levels:
| Level | What the provider does | What stays with you |
|---|---|---|
| Notification | Hand over a verified alert with context | Investigation, decision, action |
| Bounded action | Act on agreed systems: isolate a host, kill a session, disable an account | Decisions on anything outside the agreed scope |
| Guided response | Execute containment and drive remediation through to closure | Approvals, business decisions, restoration |
All three levels are legitimate. It’s just that the first is occasionally sold with the vocabulary of the third.
So the practical test question in a vendor conversation isn’t “do you offer response?” but: “At 03:14, a domain admin account is used from an unknown IP. What exactly do you do, without reaching anyone on our side first?” The answer to that question is the actual scope of work.
And XDR?
Extended Detection and Response is a product category, not a service category: a platform that consolidates telemetry from endpoint, identity, cloud and network within one vendor stack and correlates it there.
XDR therefore isn’t the opposite of a SIEM. It partly overlaps one, with a difference in character: XDR is deeply integrated within an ecosystem, a SIEM is broadly integrable across ecosystems. In heterogeneous environments with legacy systems, industry-specific software and several cloud providers, the pure XDR approach regularly hits its limits.
Whether that platform runs in the cloud or in your own data centre is an operations decision, not a security one: see Cloud SIEM vs. On-Premises.
Three confusions that get expensive
“We have a SIEM, so we have detection.” You have the prerequisite for detection. Whether you have detection depends on whether someone maintains the rules and works the alerts.
“MDR replaces our SIEM.” Sometimes yes. But if the provider works exclusively on their own stack, you lose the ability to correlate your own sources and often direct access to the raw data you need for your own investigations and for evidentiary obligations. Settle before signing who owns the data and how you get to it in a dispute.
“EDR is basically a small SIEM.” No. EDR sees endpoints superbly and everything else not at all. Attacks through identities and SaaS services frequently leave no trace on an endpoint whatsoever.
Which model fits
- Own SIEM, own SOC: worthwhile at a size where a team of at least ten analysts is realistically fundable and retainable, and where detection is itself a competitive factor.
- Own SIEM, outsourced handling: when platform and data sovereignty should stay internal but 24/7 staffing isn’t feasible. The most common case in the upper mid-market.
- Fully outsourced (MDR): when there’s no existing platform and time-to-value counts. Watch telemetry breadth and data access.
Our service tiers map exactly onto that line: tier 01 builds the platform in your environment and hands it over. Tier 02 operates it and delivers verified alerts to your team. Tier 03 takes over triage, investigation and guided response around the clock. The boundary sits where your team’s capacity ends, not where a product catalogue draws it.
Bottom line
SIEM, SOC and MDR are not alternatives but three layers of the same job: see, understand, act. The technology provides the sight. The function provides the understanding. The delivery model only decides who sends the invoice and whose name is on the shift roster.
The single question that tests all three layers at once remains: who acts at 03:14 and how far are they allowed to go without asking?