How to choose an MDR, SIEM or XDR without being vendor-led

SIEM, XDR and MDR are three different things, not three flavours of the same thing. A SIEM is a platform that collects, normalises and correlates logs and events from across the entire landscape using rules or analytics, so that a central picture emerges of what is happening. XDR is detection and response that works across multiple domains at once, endpoint, identity, email, cloud, network, with the promise that the telemetry from those domains arrives already pre-processed and linked together so that correlation is faster and more targeted than in a purely log-driven SIEM. MDR is not a platform but a service: an external party that delivers the detection and response function in whole or in part, with human analysts who watch the telemetry 24/7, investigate alerts and, in the event of incidents, intervene or escalate. The difference between the three is therefore not a feature comparison. It is a question of what you want to and can carry yourself, and what you outsource to a platform or to people.

This is how you select without letting the seller's category define what you need. The rest of this piece sharpens the distinction between the three, describes the behavioural test you can apply in every sales conversation, and ends with five criteria on which an independent selection stands or falls.

What is the difference between SIEM, XDR and MDR?

The difference begins with what the thing fundamentally is. A SIEM is a log pipeline with a correlation layer on top. You feed it with log sources from your infrastructure, applications, identity, network and cloud, and it gives you a platform to write rules, build dashboards, tune alerts and look back forensically. What you get out of it is a function of what you put into it, who maintains the rules and how well the telemetry is normalised. It is a tool, not a solution. Without your own detection engineering you fill up with alerts that say nothing.

XDR is by design the next step, with one important nuance. The promise is that the vendor has already normalised, enriched and correlated the telemetry from its domains, and in open variants from third parties too, before you do anything with it. You do not get raw log lines but pre-processed detections that run across endpoint, identity and cloud. That saves a lot of tuning, provided that the domains where you actually have risk are also covered by that vendor's detection content. With a closed XDR that is tightly bound to a single vendor's stack, with the associated lock-in effect. With an open XDR the telemetry integration with third-party sources is the critical point: the detection is only as good as the telemetry that actually comes in.

MDR adds people. An MDR service can run on top of a SIEM, on top of an XDR or on top of an in-house detection platform, and provides analysts who investigate and prioritise the alerts and, in the event of incidents, take an action or escalate to your team. What distinguishes MDR from "someone is watching our alerts" is the way of working: detection engineering that is maintained for your environment, a runbook per type of incident, an agreed response mandate, and an SLA on detection, triage and response time. An MDR that only reports what its platform sees by default is an alerting service, not a detection and response capability.

The three are therefore not interchangeable. A SIEM without people to write and maintain the rules is an expensive log store. An XDR without coverage of the domains that matter to you is a nice dashboard that sees the wrong things. An MDR without a platform that genuinely receives the telemetry from your environment is a SOC that looks at too little. The choice is not about which category wins, but about which combination fits what your organisation does itself and what you outsource.

Why the selection so often becomes vendor-led

The selection rarely goes wrong on the technology. It goes wrong on the order of the conversation. A vendor comes in with its category, not with your requirement. The SIEM seller shows data volume and correlation rules. The XDR seller shows pre-processed detections and cross-domain correlation. The MDR seller shows 24/7 monitoring and a mean time to respond. Three different product demos, three different promises, and none of the three starts from what your landscape, your risk profile and your internal capacity actually need. In this way the selection becomes a choice between three offerings that declare their own category to be the solution, rather than a choice that arises from your requirement.

Here lies a behavioural test that you can apply in every first conversation, and that predicts more than any feature matrix. Does the vendor ask questions before it categorises? An independent provider first asks what your use cases are, which detections you are currently missing, what telemetry you have available, what your SOC or IT team looks like and what you have on your programme for the next eighteen months. Then comes a recommendation, which is sometimes its own category, sometimes not, and sometimes is "start with what you already have and invest in the rules first". A vendor-led provider recognises a keyword in your sentences, "too many alerts" or "we cannot see lateral movement", and links it to its portfolio within three sentences. The difference is immediately audible, and it says something about what happens once the implementation is under way.

In its Threat Landscape, ENISA repeatedly points to the pattern of organisations buying detection capacity that does not align with their specific risk profile: the telemetry is there, but the detections are looking for the wrong things. That is not a tool problem, it is a diagnostic problem that has been solved with a tool. The MITRE ATT&CK framework provides the common language here: a serious vendor can describe in concrete ATT&CK technique terms what it covers and what it does not, for your type of environment and your type of adversary. A vendor that can only talk in product features covers something, but no one knows exactly what.

Five criteria for an independent selection

The selection becomes traceable once you run it along these five axes. Not a weighting formula, but a structured conversation that forces assumptions to be made explicit before the quotation is on the table. NIST CSF, in its Detect and Respond functions, provides the overarching structure: you are not buying a platform, you are filling in a capability.

Use-case fit. First write down which detections you need for your landscape and your threat picture, in ATT&CK technique terms or something comparably concrete. Ask every candidate to cover that same list, with evidence of how and which data conditions apply. A vendor that reformulates the list into its own feature set also reformulates your problem. A vendor that says "we see these three consistently, these two not without additional telemetry" gives you an honest starting point.

Data-volume economics. SIEM and some XDR models charge on data volume, often in gigabytes per day or in events per second. That sounds neutral and it is not: you pay for what you pump into it, regardless of whether you get value out of it. Ask for a three-year projection on your actual log sources, with growth assumptions, and ask what happens when you connect more sources. At the same time: too little telemetry and the detection is blind. The optimum lies not in as little data as possible, but in a careful choice of which sources feed which detections. That is detection engineering, not a procurement rule.

Telemetry integrations. How does the vendor see the telemetry that lies outside its own stack? With a closed XDR this is the painful question, with an open XDR or a SIEM the central one. Ask specifically about the sources you have, your identity provider, your cloud tenant, your network fabric, your OT layer where applicable, and which integration actually exists, which has to be built, and who builds it. An integration that "can be done via a log forwarder" is not an integration, it is a project on which the detection depends.

Response SLA, embedded in a mandate. With MDR services things rarely go wrong on detection time and almost always on what happens after detection. Ask not only about a mean time to detect and a mean time to respond, but about the mandate: which actions may the external party take without your approval, which must it submit for review, and along which escalation paths. A response SLA without an attached mandate is a promise without authority, and in the first real Saturday-night incident you notice the difference.

Exit clauses and data ownership. What remains yours when the relationship ends? Owning the logs, the detection content, the tuning history and the incident timelines is not a detail in the terms and conditions, it is what determines whether you can switch at all. Ask explicitly about export formats, retention after the contract ends, and whether detection content built for your environment is your property or the vendor's. For outsourced services the NCSC consistently recommends that exit conditions are clear before award, not as an afterthought. A vendor that becomes vague here tells you where you will stand in a few years.

The five criteria are connected. Use-case fit without the right telemetry integrations is a paper promise. A response SLA without use-case fit clears the wrong alerts faster. Exit clauses without data ownership make everything around them negotiable the moment you genuinely want to leave. Anyone who weighs the criteria in isolation and ticks a box on each one often ends up with a choice that scores on the matrix and does not work in your environment.

What this means for the choice you make

For the CIO who has to fit this choice into a transformation programme: the usable summary is that selection is not a category choice and not a procurement exercise. It is a diagnostic question that you can ask in two conversations, and that makes the difference between a platform or a service that lands in your landscape and a choice that the vendor has made for you. For the CISO the message is that without in-house detection engineering capacity even MDR remains a partial solution. For the CFO the message is more commercial: data-volume economics and exit clauses determine the multi-year cost curve more strongly than the licence price in year one.

The logical next step is not to send out an RFP with a feature list per category, because every vendor ticks its own category. First put the use-case list on paper, in concrete technical terms. Then apply the behavioural test in every first conversation: does the vendor ask questions before it categorises. After that, run through the five criteria on the remaining candidates. Place your own situation alongside this framework, and if a vendor dodges one of the criteria, you know that its category mattered more to it than the outcome you need.