Twice in the last three years a CFO has pointed at my budget and asked why we pay for managed detection and response (MDR) and security information and event management (SIEM). It's a fair question: both contracts promise detection, both can be expensive, and vendor decks often blur the line between a managed service and a security-data platform.
My answer starts with the operating model. MDR buys people and process for continuous monitoring, investigation, and response. A SIEM provides the data layer: log collection, search, retention, correlation, and custom detection infrastructure.
You can sometimes consolidate part of that footprint, but only after you know who owns the logs, who owns the detections, who works the alerts at 2 a.m., and what survives when the provider leaves.
In brief:
- MDR is a managed security service; SIEM is a platform for collecting, retaining, searching, and detecting against security telemetry. They overlap, but they aren't automatic substitutes.
- Your MDR may work inside your SIEM, overlay your existing tools through APIs, ingest selected telemetry into its own platform, or bundle a SIEM or extended detection and response (XDR) capability. The architecture, not the MDR label, decides cost, coverage, retention, and lock-in.
- Retention is often the deciding constraint. PCI DSS requires at least 12 months of audit-log history, with the most recent three months immediately available; a provider's default window may not meet it.
- Before retiring a SIEM, confirm source coverage, searchable retention, raw-log export, detection-rule ownership, investigation-data export, and who runs detection engineering after the contract ends.
- The real cost question isn't "MDR or SIEM?" It's whether two contracts pay separately for the same ingestion, retention, detection logic, and analyst workflow.
Why MDR versus SIEM is almost the wrong question
In the environments I've managed, the two haven't competed for the same function, and treating them as substitutes has produced bad renewals.
One is a service, the other is a platform
MDR and SIEM overlap, but they solve different operational problems. A SIEM is a platform that requires operational ownership, whether that sits with an internal SOC, a co-managed service, or an MDR provider; MDR supplies the people and process as a service and may or may not run on a SIEM at all.
Framing the choice as MDR or SIEM is like asking whether to buy pipes or hire a plumber.
The more direct platform-consolidation question is usually XDR, or a vendor's next-generation SIEM, versus a conventional SIEM, not MDR versus SIEM. Even then the answer depends on data-source coverage, retention, query needs, integrations, compliance evidence, and portability. The MDR question is a layering question.
What each one does, and where they touch
The labels often blur together in vendor messaging, but they describe distinct layers of a security operation—and the gaps between them are where technology alone stops being enough. Each layer has a narrower job than the marketing implies.
SIEM: data collection, search, retention, and detection infrastructure
A SIEM aggregates and normalizes telemetry, retains it for search and investigation, and can run correlation rules and other detection analytics. What it doesn't automatically supply is the analysts, tuning discipline, and incident-response ownership that turn those capabilities into a 24/7 operating function.
A SIEM's retention is customer-controlled, which a service does not necessarily replace.
PCI DSS is the concrete case: audit logs must be retained for at least 12 months, with the most recent three months immediately available for analysis. Even when an MDR handles monitoring, meeting that floor can preserve the need for a SIEM, a log-management platform, or another durable customer-controlled archive.
HIPAA is different: it requires audit controls and activity review for systems containing electronic protected health information (ePHI). An organization's actual retention period is shaped instead by its risk analysis, policies, contracts, state law, and litigation holds.
Cyber-insurance underwriting can influence logging expectations too, but requirements vary by carrier and policy, so treat your insurer's questionnaire as the governing source, not a generic market assumption.
MDR platform retention does not always satisfy that floor. I've encountered providers that reduce retained log volume or keep only a short investigation window, while incident responders routinely need older logs to find what detection missed.
When I scoped an incident response retainer two companies ago, log availability was the firm's first question, before headcount and before tooling.
MDR: people detecting and responding, sometimes on your SIEM
An MDR service means analysts watching telemetry around the clock, handling alert triage and investigation before escalation. MDR quality shows up in the escalation: a good provider sends a defensible verdict, an evidence chain, scope, and a recommended next action, while a weak one forwards an alert and leaves you to reconstruct the incident.
That second kind isn't meaningful MDR; it's alert forwarding with a service wrapper. In every evaluation I run now, I ask to see three anonymized escalations from an existing customer before I ask about price.
That evidence-chain test is where the AI-native MDRs pitch themselves. Daylight, for one, makes the evidence-chain case that publishing a full record with every verdict is what separates managed detection from alert forwarding. Hold that claim to the same three-escalation test you'd hold any provider to.
Where they overlap, and where neither one owns the context
SIEM correlation rules and MDR analysts both work on detection, but neither side owns your business context by default.
The detection layer both touch
The SIEM's detections sit on the data as correlation rules, and those rules are never fire-and-forget. As Anton Chuvakin has argued, detection quality depends heavily on local context, and vendor-provided content is a starting point, not a finished program.
The 2025 SANS Detection Engineering Survey bears that out: 64% of respondents cited high false-positive rates from vendor-provided detection tools, and 61% cited accuracy issues—the two most commonly cited technology challenges.
An MDR team can compensate for noisy content through analyst review, but that review doesn't necessarily improve the underlying rule set or the false-positive burden in your environment.
Custom detection content needs clear ownership. Detection engineers tend to keep the detections they write in their own SIEM rather than route them to an MDR, and I've seen contracts where ownership of provider-written content was unclear.
The detections, their enrichment pipelines, and insider-risk integrations may not transfer cleanly at offboarding, particularly when they depend on proprietary query languages, provider-managed workflows, or ambiguous ownership terms. Require exportability and ownership language in the contract before signing.
The practical decision: who owns the platform, data, and detections
The decision that matters is who owns and tunes the platform, who owns the detection content, and what happens to your data when the contract ends. The providers I've evaluated answer those differently, so treat the architecture as the thing to diligence, not the label.
Your SIEM, their platform, or both, and when you can drop one
MDR providers may operate in your SIEM, overlay your existing tools through APIs, ingest selected telemetry into their own platform, or sell a combined MDR-and-SIEM service. A few current examples show the range:
- Expel: its Managed SIEM offer is bring-your-own-SIEM for supported environments, including Microsoft Sentinel and Splunk Enterprise Security, and Expel says customers retain the detection logic developed there. Confirm which integrations and retention terms apply if you don't operate a SIEM.
- Arctic Wolf: centralizes and analyzes customer telemetry in its own platform, with published material citing 90-day raw-log retention by default and longer retention available. Confirm searchable-retention periods, raw-log export rights, and post-termination access.
- ReliaQuest GreyMatter: an overlay across existing SIEM, EDR, identity, cloud, and network tools; whether it lets you retire a conventional SIEM depends on the source coverage, retention, and compliance evidence it contractually supplies.
- CrowdStrike Falcon Complete: operates through the Falcon platform, and third-party telemetry can be brought into Falcon Next-Gen SIEM for correlation and analysis. Confirm which sources are included, how much third-party data is licensed, and whether the MDR scope covers them.
Before you cut either line item, run the same diligence on both. On the data: who owns the raw logs and normalized events, how long they stay searchable, the post-termination access period, and the cost, format, and fidelity of exports. On detection: who owns the custom rules and playbooks, and whether the provider can supply data lineage for an audit request.
Whether you can drop the SIEM usually comes down to the compliance and retention gate: without strict requirements you may be able to. But when PCI, a HIPAA risk analysis, or insurance conditions drive retention, it's unlikely unless another customer-controlled system satisfies the same requirement.
Frequently asked questions about MDR vs SIEM
What is the difference between MDR and SIEM?
A SIEM is the platform that collects, retains, and searches security telemetry and can run detection analytics on it; it needs operational ownership, internal or outsourced. MDR is the 24/7 service in which analysts investigate detections and carry out response, sometimes inside your SIEM and sometimes on the provider's platform.
The distinction is platform versus managed service.
Can MDR replace a SIEM?
Sometimes, but only if the provider's retention, source coverage, query access, and exports meet your operational and compliance needs. An MDR platform may retain enough for incident investigation, but when PCI DSS or a HIPAA risk analysis drives historical, centralized log storage, replacement is harder.
I've encountered MDR platforms that retain only a limited investigation window, which fails the moment an IR team asks for older history.
Does MDR include a SIEM?
It depends on the architecture. Some services work in your SIEM, some overlay your tools through APIs, some ingest selected telemetry into their own platform, and some bundle a SIEM or next-gen SIEM capability. A bundled platform is convenient until offboarding, when the portability of detection logic and historical telemetry depends on the contract.
Do you need both MDR and SIEM?
Keep both when you need customer-controlled long-term data plus external 24/7 operations, and consolidate when one contract demonstrably supplies both without creating unacceptable retention or lock-in risk.
If you carry compliance retention obligations and don't run a 24/7 internal security operations center (SOC), you usually keep both; the way to avoid paying twice for the same layer is to pick an MDR that operates on your SIEM, or to negotiate portability before signing.