The market for outsourced detection and response is crowded, and the vocabulary is deliberately fuzzy. MDR, managed SOC, SOC-as-a-service, and co-managed SIEM are sold as if they are interchangeable, and the differences that matter most (who can take action when something is on fire, and whether you can see how the sausage is made) are exactly the ones glossed over in the sales deck. This guide cuts through the labels so you can buy detection and response with your eyes open.
What the three models actually are
Self-run SIEM or XDR
You license the platform, ingest your logs, write your own detections, and staff your own analysts to triage alerts around the clock. A SIEM (Security Information and Event Management) correlates logs from across your estate. XDR (Extended Detection and Response) is a more integrated stack, usually anchored on endpoint telemetry, that bundles detection content and response actions. Either way, in the self-run model the people, the content, and the response are yours. You own full control and full burden.
Managed SOC / SOC-as-a-service
A provider operates the SIEM or XDR on your behalf and staffs analysts to monitor it. The emphasis is on monitoring, triage, and alerting you to confirmed incidents. Some managed SOCs run on your platform (co-managed), others on their own. The key question is whether they only tell you that something is wrong, or whether they are contracted and authorised to do something about it.
MDR (Managed Detection and Response)
MDR is defined by the second R: response. A genuine MDR provider does not just alert you, it takes or directs containment actions. The good ones bring their own detection engineering, threat hunting, and a defined response mandate. The term is heavily abused, so a service calling itself MDR that can only send you an email at 2am is really a managed SOC with better marketing.
The questions that separate real services from black boxes
The single most useful filter is to ask about transparency and authority. Many providers operate as a black box: alerts go in, occasional emails come out, and you have no visibility into what is detected, what is missed, or why.
Response authority
What, precisely, can the provider do when they confirm a compromise at 3am on a Sunday? Can they isolate an endpoint, disable an account, block an IP, or kill a process, without waiting for you to wake up? Or does their contract stop at notification? A response capability that requires your on-call engineer to execute every action is not response, it is a faster alert. Get the action authority written into the runbook, including the specific systems they can touch and the approval thresholds.
Detection transparency
Can you see the detection rules running against your data? Can you see what MITRE ATT&CK coverage they provide and, just as important, where the gaps are? A provider who refuses to show you their detection logic is asking you to trust an invisible product. You should be able to review detections, request new ones, and understand why an alert fired.
Telemetry coverage
What data sources does the service actually monitor? Endpoint only, or also identity, cloud control plane, network, email, and SaaS? Attackers move across these layers, and a service watching only endpoints will miss an identity-based attack entirely. Map their coverage against where your real risks live.
Lock-in and the exit you hope you never need
Detection and response is a long relationship, so think about leaving before you sign. Several lock-in traps are common:
- Detection content ownership. If the provider builds custom detections for your environment, do you keep them when you leave, or do they walk out the door with the vendor?
- Data portability. Is your historical log data exportable in a usable format, or is it trapped in their platform?
- Platform dependence. A managed service built on your own SIEM or XDR is far easier to transition than one built entirely on the provider's proprietary stack.
- Tuning and context. Months of tuning and environmental context can evaporate at handover unless it is documented and owned by you.
Co-managed models, where the platform and data stay yours and the provider supplies the people and content, generally offer the cleanest exit and the most transparency.
SLAs that mean something
Most SLAs measure the wrong thing. Time-to-acknowledge an alert is easy to hit and nearly worthless. The metrics that matter are time-to-detect and time-to-respond (or contain) for a real incident, and the false-positive rate that determines whether your team trusts the alerts at all. Ask for evidence of these from existing clients, not just the numbers in the contract. Also clarify what counts as an incident, because a generous definition of acknowledgement can hide a slow time to actual containment.
How to choose
- If you have the budget, talent, and appetite to run detection in-house and want maximum control, a self-run SIEM or XDR fits, but staff for genuine round-the-clock coverage.
- If you have a platform and analysts but cannot cover nights and weekends, a co-managed SOC or MDR layered on your stack extends coverage without surrendering control.
- If you lack a SOC entirely and need detection and active response fast, MDR is usually the right call, provided you verify the response authority and transparency above.
The pattern that ages best for most mid-sized organisations is a co-managed arrangement: you keep the platform and data, a partner supplies the detection engineering, hunting, and around-the-clock response. That is the model behind our detection and response services, built to stay transparent and exit-friendly rather than locking you into a black box.
Frequently asked questions
Is XDR a replacement for SIEM?
Not entirely. XDR excels at integrated endpoint, identity, and cloud detection, but SIEM still matters where you need broad log aggregation, compliance retention, and custom correlation across diverse sources. Many estates run both.
Does MDR remove the need for an internal security team?
No. MDR handles detection and response, but governance, risk, vulnerability management, and the decisions about your environment remain yours. Treat MDR as an extension of your team, not a replacement for it.
If you want help comparing proposals or designing a transparent, exit-friendly detection and response model, contact Basalt Cyber.