Why this matters

Vendors love to compare SOC, MDR, and XDR on the same slide. The reason is not clarity. The reason is that those slides usually end with whichever product the vendor sells.

Looked at honestly, the three categories do not compete. They sit at different layers. Treating SOC vs XDR as a like-for-like choice is how SMBs end up buying overlapping tools, paying twice for the same capability, and still missing the gap that actually got them breached.

This article cuts through the conflation. It defines each one in plain English, shows where they overlap, and gives you a way to decide what your business actually needs next.

The category problem: why SOC, MDR, and XDR get conflated

The root cause of the confusion is that vendors mix categories on purpose. The three terms describe three different things:

  • SOC is a function. It is people and process. The output is decisions made about security alerts.
  • XDR is a platform. It is software. The output is correlated, prioritised alerts.
  • MDR is a service. It is people and process bundled with a platform, sold as a single contract. The output is detection and a defined response.

Once you see them as function, platform, and service, the rest of this comparison falls into place. A vendor that frames SOC vs XDR as a coin flip is selling you confusion.

What a SOC actually is

A SOC is a team of security analysts using monitoring tools to watch your environment for signs of attack. It runs continuously if it is staffed 24/7, or in business hours with after-hours on-call cover.

A mature SOC has three tiers of analyst. Tier 1 triages alerts. Tier 2 investigates suspicious ones. Tier 3 hunts for threats the tools missed and leads containment when something serious lands.

A SOC produces decisions. The team decides whether an alert is real, whether to escalate, and (within their authority) whether to act. Tools alone do not make a SOC. The analyst layer is what turns raw signals into action.

You can run a SOC in-house, buy it as a managed service, or run a hybrid where in-house staff cover business hours and a managed provider covers nights and weekends. For most SMBs, fully in-house is not realistic. Annual cost typically exceeds £500,000 before you have full coverage.

What XDR actually is

XDR stands for Extended Detection and Response. It is a software platform that pulls telemetry from across your environment and correlates it.

A typical XDR pulls from at least four sources:

  • Endpoint signals from EDR (Endpoint Detection and Response) tools.
  • Identity signals from Microsoft Entra ID, Okta, or Google Workspace.
  • Email signals from Microsoft Defender for Office 365 or similar.
  • Cloud signals from Azure, AWS, or Google Cloud control planes.

A SIEM (Security Information and Event Management) platform like Microsoft Sentinel, Splunk, or Elastic does something similar by collecting logs from anywhere. The difference is that XDR is opinionated about which signals it ingests and how it correlates them, while a SIEM is general-purpose log storage and analytics. In practice, many mature setups use both.

XDR does not come with analysts. Buying XDR gives you better alerts, not someone watching them. That is the most common misunderstanding in this space.

What MDR actually is

MDR stands for Managed Detection and Response. It is a service: a vendor's analysts running detection and response on your behalf, usually using an XDR or SIEM platform underneath.

The scope varies sharply between providers. At minimum, an MDR contract includes 24/7 monitoring, alert triage, and a contractual response capability such as isolating endpoints, revoking sessions, or blocking accounts. Some MDR providers run their own proprietary platform. Others run on top of yours, for example managing your Microsoft Defender XDR or your Sentinel instance.

The thing that distinguishes MDR from "managed SOC" is the response authority. A pure managed SOC may detect and tell you. An MDR provider detects and acts. In practice the labels overlap, and the contract is the only thing that tells you what is really being bought.

Where they overlap

Here is how the same capability maps across all three:

  • What it is: SOC is a function (people and process). XDR is a platform (software). MDR is a service (people and platform bundled).
  • Detects threats: All three do, but differently. XDR automates correlation. SOC and MDR add analysts who interpret the output.
  • Investigates alerts: SOC (tier 2 and 3) and MDR both investigate. XDR produces alerts but does not investigate them.
  • Contains threats: MDR yes (contractual). SOC sometimes (depends on remit). XDR no.
  • Includes analysts: SOC yes. MDR yes. XDR no.
  • You buy it as: SOC: build, managed, or hybrid. XDR: software licence. MDR: service contract.
  • Typical SMB cost: SOC £18k to £500k+ per year. XDR £15 to £40 per endpoint per month. MDR £25k to £100k per year.

The rows where SOC and MDR look identical are not a coincidence. A managed SOC and an MDR service are increasingly the same product sold under different labels. The only reliable way to tell them apart is to read what each is contractually allowed to do at 3am.

How to choose: a decision framework

Skip the vendor comparison sheet. Work the four questions below in order.

  1. Do you have continuous detection across endpoint, identity, email, and cloud? If no, you need a platform layer first. That is XDR (or a SIEM with EDR), not MDR or SOC.
  2. Does someone watch the alerts those tools produce, around the clock, with permission to act? If no, you need a service layer. That is MDR or a managed SOC. Buying more tools first will not help.
  3. Do you have a defined response scope for confirmed incidents? If no, you need to fix the contract before adding more tooling. The most common SMB failure mode is owning detection without owning response.
  4. Do you need to investigate, hunt, or report beyond what your service covers? If yes, you need either an in-house lead, a senior consultant, or a tier-3 capability inside your provider. This is where the SOC function genuinely sits separately from the MDR service.

Most SMBs find their gap is at step 2: they have decent platforms but nobody watching at the weekend.

Realistic combinations for SMBs

There is no single right stack. There are sensible combinations at different sizes.

Small (25 to 100 endpoints, no regulated data)

  • EDR on every device.
  • Business-hours IT response.
  • Out-of-hours: managed SOC alerting only, or a small MDR retainer.

Mid (100 to 250 endpoints, some sensitive data)

  • XDR platform (often Microsoft Defender XDR if M365-native).
  • 24/7 MDR or managed SOC with response authority.
  • An incident response retainer separate from the MDR contract.

Mid-large (250 to 750 endpoints, regulated data or active compliance pressure)

  • SIEM plus XDR for full coverage.
  • 24/7 MDR with broad response scope.
  • In-house security lead to own strategy and direct the MDR provider.
  • Periodic threat hunting, either inside the MDR contract or via a separate engagement.

For SMBs running on Microsoft 365, three options worth comparing at the mid-tier are Microsoft Defender XDR (the platform on its own), Sophos MDR (a service running on Sophos's stack), and CyberQuell's managed XDR services, which run on top of your Microsoft tenant. Compare them on response scope and what each is contractually allowed to do without your authorisation, not feature counts.

Our take

The "SOC vs XDR" framing is a vendor convenience, not a buyer's question. We think the better question for any SMB is far less catchy: which of the three layers, function, platform, and service, is missing from my stack, and which one closes the gap that costs me most if it stays open another year?

Most SMBs we see do not have an XDR problem. They have an "alerts going to nobody at 2am" problem. The fix is a service layer with real response authority, not another platform sitting next to the ones already producing alerts. Buy the layer that closes the actual gap, not the one with the cleanest demo.

Where to go from here

Map your current stack against the three layers. Write down which platforms you have (your XDR or SIEM and the tools feeding them), which service covers them (or none), and which function owns the decisions when something fires. Anywhere a layer is missing or unclear, you have a gap.

If you are evaluating providers, build a shortlist of three across the categories you actually need: maybe one MDR provider, one platform-only XDR option, and one bundled service. Score them on response scope and contractual response authority, not feature counts. The right answer is usually the one that closes your biggest open gap, not the one with the most checkboxes ticked.