MDR is not the same as alerting. A serious provider takes ownership of assisted containment — isolating endpoints, revoking sessions, blocking command and control — and coordinates with IT until the incident is closed. If they only email you, that is monitoring, not MDR.
What MDR is
MDR (Managed Detection and Response) is a 24×7 managed service that combines extended detection technology —EDR, XDR, SIEM, NDR— with human analysts who monitor, investigate and respond to incidents on the customer's behalf. Unlike a traditional SOC, MDR is contractually focused on operational response through to incident closure, not just alerting.
Why it matters
An organisation that deploys a high-end EDR without a team to operate it ends up either ignoring the alert stream or switching the product off. MDR closes that gap: the provider brings the analysts, the playbooks, the enriched telemetry and the response SLA. For regulated B2B buyers, MDR is typically more economical than standing up an internal SOC with 24×7 shift work, competitive salaries and the inevitable analyst churn. Under NIS2, DORA and ISO 27001:2022, MDR provides the continuous evidence of detection, response and improvement that auditors and supervisors expect to see.
Key points
The technology base is usually an EDR (CrowdStrike, Microsoft Defender for Endpoint, SentinelOne, etc.) extended with XDR signals from identity, M365, network and cloud. Increasingly MDRs operate in BYO-EDR mode: you keep your licence and the provider runs on top.
Typical SLAs measure mean time to detect (MTTD), mean time to contain (MTTC) and customer notification. A capable MDR will commit to MTTD ≤ 15 minutes on critical alerts and notification within an hour of a confirmed incident.
MDR fits modern quantitative frameworks: prioritisation by EPSS and KEV, hunting mapped to MITRE ATT&CK, automation through SOAR. The differentiator from a generic MSSP is how much human analysis the contract guarantees.
Under NIS2 and DORA, evidence of timely detection, response and notification is mandatory. A well-documented MDR generates that evidence as a by-product, which reduces audit effort compared with improvising response each time.
Common confusion: MDR does not replace deep forensic investigation. After a severe incident the MDR contains and hands over evidence; DFIR reconstructs root cause and lateral scope and produces the executive report.
Worked example: how an enterprise MDR lands on a Windows + M365 estate
A mid-market organisation with 600 Windows endpoints and a business-critical Microsoft 365 deployment engages an MDR on top of its existing Microsoft Defender for Endpoint. The provider ingests Defender, Defender for Identity and Defender for Cloud Apps signals into its XDR platform, deploys sector-specific use cases and validates each with controlled false-positive testing before the SLA clock starts.
Three months later, at 03:14, the MDR detects an anomalous chain: explorer.exe spawning mshta.exe with remote arguments against a freshly registered domain. An automated KQL query correlates this with an OAuth abuse attempt against the M365 tenant minutes earlier. The L2 analyst isolates the endpoint in six minutes, revokes all sessions for the affected user in Entra ID, opens an incident with the customer and coordinates the credential rotation. The evidence is captured with traceable timestamps, ready for the next NIS2 audit.
Common mistakes
- Buying MDR and expecting the provider to silence every false positive without context. MDR depends on the customer's environment. An onboarding without dialogue with IT leaves the service generating noise for months.
- Treating MDR as a synonym for MSSP. A capable MSSP may be excellent, but its centre of gravity is usually visibility and reporting. MDR contracts pivot around managed response and containment SLAs.
- Skipping precise SLAs. MTTD and MTTC need to live in the contract with clear definitions and consequences if missed. Without that, MDR is a slogan.
- Outsourcing MDR and stopping internal hunting. The best results come when the customer's team keeps generating hypotheses and the MDR validates or executes them, not when the customer disappears from the operation.
- No exit plan. When the MDR contract ends, what documentation stays with you? Use cases, playbooks, integrations and lessons learned. Negotiate that from day one, not when you are leaving.
Related terms
Related services
This concept may relate to services such as:
Frequently asked questions
How does MDR differ from an in-house SOC?
An in-house SOC requires 24×7 shift coverage, L1-L3 analysts, tooling, use cases and a strategy for analyst rotation. MDR moves that operation to a provider with predictable costs and a contractual SLA. For many mid-market organisations, MDR reaches productive operation in 4-8 weeks, whereas an in-house SOC typically takes 9-18 months to mature and demands a high upfront investment.
What is the difference between MDR and MSSP?
MSSP (Managed Security Service Provider) is the broad umbrella: it can cover SOC, MDR, vulnerability management, CTI and response. MDR is specifically about detection and response with containment SLAs. Most enterprise MSSPs include MDR in their catalogue. The real distinction lives in the contract: does the provider only alert, or are they also responsible for containment?
Do I need EDR before contracting MDR?
Usually yes. Most MDR providers require a base detection technology — EDR, XDR or SIEM — to operate on. Some enterprise MDRs deploy their own EDR as part of the contract. If your organisation lacks EDR today, MDR can bring it and reach productive operation within a few weeks.
What SLAs are reasonable in an MDR contract?
For critical alerts, time to detect ≤ 15 minutes and customer notification of a confirmed incident ≤ 1 hour. For high severity, ≤ 30 minutes to detect and ≤ 2 hours to notify. Containment varies by scope, but a credible MDR will commit to endpoint isolation in ≤ 30 minutes. If the provider declines to sign specific SLAs, treat it as a flag.
Does MDR count as evidence for NIS2 or DORA?
Yes — it is one of its most valuable contributions. NIS2 (article 21.2) and DORA (articles 9-10) require a demonstrable incident management capability and timely notification. A well-documented MDR generates traceable records of detection, containment, communications and lessons learned, which is exactly the kind of continuous evidence an auditor or supervisor expects.