Managed Detection and Response (MDR): Explained
Managed Detection and Response (MDR) is the service category where an external provider runs continuous, 24x7 threat detection, triage, investigation, and response across an organisation's telemetry sources, with named analysts, named runbooks, and named response actions on top of either the customer's own tooling or a stack the provider operates. For internal security teams, AppSec leads, vulnerability management functions, GRC owners, security architects, and the CISOs who sign the contract, MDR is the discipline that turns a noisy alert stack and a thinly staffed off-hours rotation into a validated, contextualised stream of incidents with named response actions and an audit-grade evidence record. This guide covers what MDR is and is not, the five capability layers (Telemetry Ingest, Detection Engineering, Triage and Investigation, Active Response, Evidence and Reporting), how MDR differs from SIEM, XDR, EDR, MSSP, and an in-house SOC, the cadence and operating shape that makes MDR a programme rather than a stream of alerts, the recurring adoption pitfalls, the onboarding shape that bounds MTTD and MTTR, the procurement criteria that separate a programme-grade provider from a vendor dashboard, and how the finding side of the MDR record connects to prioritisation, remediation tracking, and CTEM so the detection work does not live in a parallel backlog.
What MDR Actually Is
Managed Detection and Response is an operating model, not a single tool. A provider supplies analyst capacity (typically 24x7 across shifts), a curated detection library tuned to the customer's environment, a runbook set for triage and response, and the active response actions the customer has authorised the provider to execute on its behalf. The provider sits above the customer's telemetry sources (EDR, SIEM, cloud audit logs, identity provider logs, email gateway logs, and sometimes network and application telemetry) and produces a triaged, contextualised, and prioritised stream of validated incidents rather than the raw alert volume an unmonitored SIEM or EDR produces.
The category emerged in the late 2010s as a packaging of MSSP-style outsourced monitoring with the detection engineering, threat hunting, and active response disciplines that mature internal SOCs run. The defining properties are continuous coverage (24x7, including weekends and public holidays), named active response (the provider can execute response actions on the customer's behalf rather than only forwarding alerts), and named outcome metrics (mean time to detect, mean time to respond, mean time to contain). Mature programmes treat MDR as the operating layer between the telemetry stack and the wider security organisation, with the internal SOC manager or security operations lead retaining the runbook quality, the escalation criteria, and the institutional context that does not transfer to an external provider.
The motivation is staffing and throughput. A pure in-house 24x7 SOC needs roughly eight to twelve analysts across shifts plus tier-3 investigators and a SOC manager, in a competitive labour market where retention is difficult. MDR offsets that staffing problem by amortising analyst capacity across many customers. The trade is institutional knowledge and direct control versus capacity and continuity. Mid-sized and enterprise organisations increasingly run a co-managed model where MDR covers tier-1 and tier-2 with named active response and the internal SOC manager covers tier-3 depth, runbook quality, and the wider security operating relationship.
The Five Capability Layers of an MDR Provider
A mature MDR provider has five capability layers. The layers depend on each other: a gap in any of them weakens the service the provider produces. Buyers evaluating MDR vendors should benchmark each layer against the named telemetry sources, the named response actions, and the named outcome metrics the customer needs, rather than treating the MDR category label as a capability claim.
Layer 1: Telemetry Ingest
Telemetry Ingest covers what the provider can collect and reason across. The minimum viable footprint is EDR telemetry plus identity provider logs. A stronger provider also ingests SIEM forwarding, native cloud audit logs (CloudTrail, Azure Activity Log, GCP audit logs), Kubernetes audit logs, email gateway telemetry, and network telemetry (NetFlow, full packet capture, or sensor-derived). Application-layer telemetry (WAF logs, API gateway logs, custom application logs) is the boundary the strongest providers reach. Buyers should benchmark coverage against the surfaces the organisation actually owns. A provider that only ingests EDR produces detection coverage with structural blind spots on cloud, identity, email, and application surfaces.
Layer 2: Detection Engineering
Detection Engineering covers the rule, analytics, and behavioural model library the provider maintains, tunes against the customer's environment, and updates as new attacker techniques and emerging-threat advisories appear. Mature providers map detections against the MITRE ATT&CK tactics and techniques so the coverage matrix is reviewable as a discipline rather than as a one-off configuration. Detection Engineering is also where the provider distinguishes between a library shipped from the head office and a library tuned to the customer's baseline. A library that fires on every legitimate administrator action produces alert fatigue; a library tuned to the customer's normal operating shape produces high-confidence signal.
Layer 3: Triage and Investigation
Triage and Investigation covers the analyst capacity, the runbook library, and the depth of investigation per validated incident. Tier-1 triage decides whether a raw alert is real or benign. Tier-2 investigation correlates the validated alert against adjacent telemetry (was the same actor seen on identity, cloud, or email surfaces in the same window), reconstructs the attack chain, and names the affected assets and accounts. Tier-3 investigation runs deeper threat hunting against the broader telemetry to ask whether the incident is isolated or part of a wider campaign. The strongest MDR providers ship named analyst staffing per customer at named seniority levels and publish per-tier mean time to triage. The weakest ship pooled triage that produces variable depth across shifts.
Layer 4: Active Response
Active Response covers the named response actions the provider is authorised to execute on the customer's behalf. The minimum is EDR-side actions: host isolation, process kill, file quarantine, script execution. Stronger providers also execute identity-side actions (account disable, session revocation, MFA reset trigger), email-side actions (message quarantine, sender block), and cloud-side actions (instance isolation, security group change, role disable). The active response set is documented in the customer's runbook with named carve-outs for systems and accounts the provider cannot touch without explicit approval. Providers that only forward alerts and require the customer to execute every response are MSSP-style operating, not MDR. The active response authority is the defining differentiator of the category.
Layer 5: Evidence and Reporting
Evidence and Reporting covers the per-incident record, the executive cadence read, and the audit-grade output the customer reads at framework audit and at cyber insurance renewal. The per-incident record names the alert source, the triage outcome, the investigation finding, the response action, the asset and account touched, and the closure rationale. The executive cadence read covers MTTD, MTTR, MTTC, false positive rate, and coverage drift cycle-on-cycle. The audit-grade output maps incident-level evidence against ISO 27001 Annex A 8.16, SOC 2 CC7.2 and CC7.3, PCI DSS Requirement 10.4, NIST 800-53 SI-4, and NIST CSF 2.0 DE.AE so the MDR service produces directly defensible audit material rather than only a vendor dashboard.
MDR vs SIEM, XDR, EDR, MSSP, and In-house SOC
MDR overlaps with five adjacent categories. The boundaries are operational rather than strict, and mature security organisations run more than one in parallel. The table below lays out the differences so security leaders can decide what each category actually buys them and where MDR sits relative to the existing security stack.
| Category | Anchor | Relationship to MDR |
|---|---|---|
| SIEM | Technology that ingests, normalises, correlates, and searches security telemetry. | SIEM is a tool. MDR is the service that puts a 24x7 analyst pair in front of the SIEM. Many MDR providers operate above the customer's SIEM (SIEM-led MDR). |
| XDR | Technology that cross-correlates endpoint, network, cloud, identity, and email telemetry into a single platform. | XDR supplies cross-source correlation. MDR supplies analyst capacity. Pairing pattern: XDR or SIEM telemetry plus MDR analyst capacity above it. |
| EDR | Endpoint-side technology that runs an agent on hosts for detection, containment, and response on the endpoint. | EDR is the endpoint slice. EDR-led MDR wraps EDR plus adjacent telemetry into 24x7 analyst-staffed service with EDR-side active response. |
| MSSP | Outsourced device management and alert forwarding model that emerged in the late 1990s and 2000s. | MSSPs typically forward triaged alerts to the customer. MDR providers typically respond on the customer's behalf. Many MSSPs now also offer MDR; the response scope is the practical distinguisher. |
| In-house SOC | Security operations function staffed by the customer's own analysts, running the customer's own tooling and runbooks. | Full in-house SOC needs 24x7 staffing, tooling, and retention discipline. MDR offsets that. Co-managed model is the mature pattern: MDR for tier-1 and tier-2, internal SOC manager for tier-3 depth and operating ownership. |
| SOAR | Security Orchestration, Automation, and Response platform that scripts response actions and ticket flows. | SOAR automates response. MDR supplies the analyst and the active response authority. MDR providers often operate SOAR on the customer's behalf for repeatable runbook execution. |
MDR is not a replacement for any of these. A programme that operates SOAR, an identity threat detection and response layer, and a CAASM record without an MDR provider has the technology stack but lacks the 24x7 analyst capacity and the named active response. A programme that ships MDR without an underlying telemetry stack has the analyst capacity but lacks the visibility the analysts need. The mature pattern is to operate each layer on a single record and let MDR provide the staffing and the response actions above the telemetry.
The label distinction also matters at procurement. Some vendors marketing themselves as MDR providers ship MSSP-style alert forwarding with the MDR label; others ship full active response across multiple surfaces. Buyers evaluating MDR vendors should benchmark the five capability layers, the named telemetry sources, the named response actions, and the named outcome metrics, rather than treating the MDR category label as a capability claim. A coverage matrix that names the in-scope surfaces and the response authority per surface is the procurement artefact that separates a programme-grade provider from a vendor dashboard.
Cadence and Operating Shape
MDR is continuous rather than periodic. The cadence is what makes MDR a programme rather than a stream of unresolved alerts. Most enterprise programmes run a layered cadence: tier-1 triage runs continuously across shifts, tier-2 investigation runs on demand against validated incidents, tier-3 hunting runs on a weekly or fortnightly cycle, executive cadence runs monthly, and a deeper service review runs quarterly with the SOC manager and the MDR account team.
Continuous tier-1 triage
Tier-1 analysts run continuously across shifts. The volume is governed by the detection library tuning and the customer's baseline. Tier-1 decides whether a raw alert is real or benign, suppresses false positives, and escalates validated alerts to tier-2. The output is a high-confidence validated alert stream rather than the raw alert volume the telemetry stack produces.
On-demand tier-2 investigation
Tier-2 investigators reconstruct the attack chain for each validated alert, correlate against adjacent telemetry, name the affected assets and accounts, and decide the response action. Tier-2 also drives the named active response actions the customer has authorised: host isolation, account disable, EDR script execution, conditional access trigger, email quarantine. Tier-2 is where the named MTTR and MTTC outcomes are produced.
Weekly or fortnightly tier-3 hunting
Tier-3 hunting runs against the broader telemetry to find activity that the detection library did not catch. Hunting hypotheses come from threat intelligence, from incidents at adjacent customers, from public emerging-threat advisories, and from the customer's own asset and identity inventory. Hunting outcomes feed the detection engineering layer; tunings and new rules are deployed into the live library on a fast iteration cycle.
Monthly executive cadence
The monthly executive cadence reads MTTD, MTTR, MTTC, false positive rate, coverage drift, and the validated incident count. The cadence is what leadership reads to understand whether the programme is improving over time or staying flat. Programmes that only read the executive cadence and not the per-incident evidence pack produce leadership trust without operating proof.
Quarterly service review
The quarterly service review covers runbook drift, scope changes, detection library updates, response authority changes, and the next cycle's improvement plan. The review is also where contractual SLA performance is reviewed against the named commitments. The cross-cycle record carried on the customer's side, including detection coverage drift and remediation closure rate, is the spine of the quarterly review. Continuous control monitoring cadence research covers the cadence economics in adjacent control work.
MDR Onboarding: The Five Stages
A defensible MDR onboarding has five stages and runs typically four to twelve weeks depending on environment complexity. Onboardings that skip stages produce high-friction service relationships in months two and three; the discipline is to invest in the calibration up front so the steady-state operating model bounds MTTD and MTTR rather than only promising it.
Stage 1: Telemetry connection
Wire the named telemetry sources into the provider's analytics platform. Confirm log retention, parsing fidelity, and integration health per source. Document the provider-side ingestion model (push vs pull, agent vs collector, native vs forwarded) and the customer-side log ownership. Telemetry that does not arrive at the provider produces silent detection gaps; the connection step is where those gaps are caught.
Stage 2: Scope definition
Document what is in scope, what is out of scope, the asset criticality tiers, and the named contacts per surface. Scope covers subsidiaries, environments (production, staging, lab), data classes (regulated, customer, internal), and named systems that need special handling. The scope record is what the provider reads on every incident to decide the escalation path.
Stage 3: Runbook calibration
Walk the customer's preferred response actions per incident type, the named approval thresholds (auto vs notify-then-act vs customer-approval-required), the escalation tree, the off-hours contact list, and the carve-outs (named accounts that cannot be auto-isolated, named systems that cannot be auto-rebooted, named business hours where automated containment requires customer approval). Runbook drift is the most common reason MDR programmes stall; the calibration step is where the baseline runbook is signed off.
Stage 4: Detection tuning
Run the first detection cycle against the customer's baseline, identify and suppress the noisy and known-benign signals, tune the detection library to the customer's environment, and document the suppressed signal classes. The tuning step is what converts a noisy library into a high-confidence alert stream. Programmes that skip the tuning step produce alert fatigue in month two and a service that the customer stops reading.
Stage 5: Go-live with named SLAs
Transition from baseline period to full 24x7 service with named MTTD and MTTR commitments. The go-live document names the SLA targets, the measurement methodology, the escalation contacts, the executive cadence read, and the post-incident review schedule. Go-live without named SLAs produces a service that cannot be measured or improved cycle-on-cycle.
The MDR Scoreboard: Six Metrics
A defensible MDR programme tracks six metrics cycle-on-cycle. The scoreboard is what makes the programme reviewable, what feeds the renewal decision, and what bounds the SLA conversation when the contract is up for renegotiation.
MTTD and MTTR are the headline SLA commitments many MDR contracts now include. Coverage and closed-loop verification are the leading indicators: a service that catches more across surfaces and closes the loop on remediation is improving regardless of headline MTTD; a service that holds MTTD steady but never improves coverage is plateauing. The scoreboard is what separates renewal as a strategic improvement vector from renewal as a fixed-cost subscription. Mean time to detect vs remediate research covers the asymmetry between detection time and remediation time that governs the cross-side scoreboard.
The MDR Evidence Pack
A defensible MDR programme keeps five artefact classes that read three ways: leadership for the security story over time, auditors for the framework evidence, and the internal SOC manager for the operating improvement queue. The evidence pack is what converts MDR from a vendor dashboard subscription into a reviewable security operating discipline.
Per-incident record
The alert source, the triage outcome (real vs benign), the investigation finding (attack chain reconstruction, named assets and accounts), the response action (named action and named executor), the containment outcome, and the closure rationale. The per-incident record is what an auditor reads to verify that a named control was operating as intended.
Detection coverage record
The MITRE ATT&CK heat map per surface, the coverage drift cycle-on-cycle, the new rules added, the rules retired or tuned, and the named gaps the programme is working to close. Detection coverage is the leading indicator the executive cadence and the audit narrative both anchor against.
Response authority record
The named active response actions the provider is authorised to execute, the named carve-outs (systems and accounts the provider cannot touch without explicit approval), the approval thresholds, and the change history per cycle. The response authority record is what an internal incident response review reads when a real incident produces an active response action that needs to be justified.
Post-incident remediation record
For each validated incident: the named root cause finding, the named remediation action against an asset or control, the named owner, the verification step, and the closure date. The post-incident remediation record is the closed loop that separates an alert that fired from a real change in the environment. The fix verification workflow covers the verification discipline.
Audit-grade compliance read
Incident-level evidence mapped against ISO 27001 Annex A 5.7 (threat intelligence) and 8.16 (monitoring activities), SOC 2 CC7.2 (monitoring of system components) and CC7.3 (security event evaluation), PCI DSS Requirement 10.4 (review of audit logs) and 12.10 (incident response), NIST 800-53 SI-4 (system monitoring) and IR-4 (incident handling), and NIST CSF 2.0 DE.AE (event analysis) and RS.AN (incident analysis). The framework alignment is what makes the MDR service produce directly defensible audit material rather than only a vendor dashboard.
Seven Common MDR Adoption Pitfalls
MDR rollouts stall on a small number of repeated failure modes. The seven below appear across most stalled programmes; the disciplined approach is to anticipate them in the procurement decision and the onboarding plan, rather than to discover them in month four.
Pitfall 1: Treating MDR as a replacement for the internal SOC manager
MDR offsets analyst capacity. It does not offset the institutional context, the runbook quality, the escalation criteria, or the relationship between the security function and the wider business. Programmes that fire the internal SOC manager when they buy MDR find that the provider has nobody on the customer side to call when a runbook ambiguity surfaces, no named owner of the detection-tuning backlog, and no named decision-maker on the response authority changes.
Pitfall 2: Buying without a telemetry strategy
MDR detection coverage is bounded by the telemetry the provider receives. Programmes that buy MDR without a clear telemetry plan (which EDR, which SIEM, which cloud audit logs, which identity source) produce structural blind spots that no analyst capacity can close. The discipline is to settle the telemetry strategy before the procurement decision, not after.
Pitfall 3: Granting response authority without carve-outs
Active response is the defining MDR capability. It is also where operational incidents happen when a provider isolates a critical workload during business hours without approval. The runbook must name the carve-outs: critical production systems that require approval, named user accounts that cannot be auto-disabled, named business windows where automated containment defaults to notify-then-act. Carve-outs are how response authority and operational continuity coexist.
Pitfall 4: Holding MDR alerts in a parallel backlog
MDR-validated incidents are findings. They have severity, a named root cause, a named remediation action, and a verification step. Programmes that hold MDR output in the vendor portal and the wider vulnerability backlog in the security operating record produce two parallel ticket pipelines that do not collapse into a single audit-read view. The mature pattern is to ingest MDR-validated incidents into the same finding record as scanner output, pentest findings, and bug bounty submissions. The bulk finding import workflow covers the operating shape for that ingestion.
Pitfall 5: Skipping the remediation loop
An MDR alert that fires, gets contained, and gets closed without a remediation action against the named root cause leaves the same vulnerability in the environment. The same condition produces the same alert at the next cycle, and the programme pays for repeated tier-2 investigation rather than for durable improvement. The discipline is to close the loop: validated incident produces named remediation, remediation gets verified, verification feeds the cycle scoreboard.
Pitfall 6: Reading only the executive cadence
The executive cadence read covers MTTD, MTTR, MTTC, and coverage. The per-incident evidence pack covers the operating proof. Programmes that read only the cadence and never sample the per-incident record produce leadership trust without operating verification. The discipline is to sample three to five per-incident records per cycle, read them end-to-end, and confirm that the headline metrics map to defensible per-incident evidence.
Pitfall 7: Renewing without benchmarking
MDR contracts renew. The renewal decision should benchmark MTTD, MTTR, MTTC, coverage, and closed-loop verification against the prior cycle and against named peer benchmarks. Programmes that renew on relationship continuity rather than on measured improvement produce fixed-cost subscriptions that do not improve year-on-year. The disciplined renewal is conditional on measurable improvement against the named scoreboard.
A Phased MDR Rollout
MDR adoption does not need to be a big-bang programme. The phased approach below takes a security organisation from a periodic incident response model to a continuous, 24x7 detection-and-response programme over three to six quarters, with operating value at the end of each phase rather than only at the end of the project.
Phase 1: Telemetry strategy and provider shortlist
Document the named telemetry sources the organisation owns and the surfaces with structural blind spots. Decide between EDR-led, SIEM-led, or hybrid MDR. Shortlist three to five providers and benchmark each against the five capability layers, the named response actions, the named SLA structure, and the named onboarding model. The output of Phase 1 is a provider decision and a named programme owner on the customer side.
Phase 2: Onboarding and tuning
Run the five-stage onboarding (telemetry connection, scope definition, runbook calibration, detection tuning, go-live). The discipline is to invest in the calibration up front so the steady-state operating model bounds MTTD and MTTR rather than only promising it. Phase 2 closes with the first cycle of tuned, 24x7 service running against named SLAs.
Phase 3: First validated incident cycle
Run the first full cycle of validated incidents through the operating record. Confirm the per-incident evidence pack is being captured, confirm the executive cadence read maps to the per-incident detail, and confirm the post-incident remediation loop is closing. The first cycle is where the operating model stops being a vendor demo and starts being a security operating discipline.
Phase 4: Closed-loop remediation
Wire the MDR-validated incidents into the same finding record as scanner output, pentest findings, and bug bounty submissions so prioritisation and remediation run on one queue. Confirm the closed-loop verification rate is improving cycle-on-cycle. Use retesting workflows to capture the verification step on the operating record rather than as an out-of-band ticket. Phase 4 is where MDR stops being a parallel workstream and starts feeding the wider exposure programme.
Phase 5: Coverage expansion
Expand the programme to additional telemetry sources and surfaces (cloud, identity, email, application) in subsequent cycles. The expansion produces a broader MITRE ATT&CK coverage matrix, a wider validated incident stream, and stronger assurance across more of the surfaces the organisation owns. Coverage expansion is where the MDR programme stops being one workstream and starts being the operating model for detection-and-response across the security organisation.
Phase 6: MDR inside the CTEM cycle
Integrate MDR output into the CTEM Validation and Mobilisation stages so the MDR-validated incidents drive the same prioritisation and remediation backlog as the rest of the exposure record. MDR contributes detection-side validation and response-side execution; CTEM contributes the cycle and the programme story. The pair is the operating model that mature programmes converge on. The CTEM cycle workflow covers the operating shape that MDR plugs into.
Where MDR Sits Inside the Wider Operating Model
MDR is one discipline inside a wider security organisation. It sits next to vulnerability management running on the asset side, attack surface management discovering external exposures, the periodic penetration testing cadence covering creative human-led testing, the breach and attack simulation layer validating that the detection stack catches what we already know about, and the AppSec triage function feeding application findings into the discipline. Each function feeds the wider programme on its own beat.
For the find-track-fix-verify operator function, the natural pairing is SecPortal for vulnerability management teams. For the security operations leader sponsoring the MDR contract, SecPortal for security operations leaders covers the leadership reading path. For the SOC analysts who run the customer-side relationship with the provider, SecPortal for SOC analysts covers the operating record for the incident-to-remediation handoff. For the detection engineering function owning the rule-tuning backlog on the customer side, SecPortal for detection engineering teams covers the operating record for the validation loop. For the CISO signing the contract, SecPortal for CISOs covers how the MDR cycle output rolls up into leadership and board reporting.
Pair the programme with adjacent operating reading. The MITRE ATT&CK framework page covers the taxonomy the MDR coverage matrix is anchored against. The SOAR explainer covers the automation layer MDR providers often operate alongside. The identity threat detection and response explainer covers the identity-surface discipline that strong MDR providers include. The enterprise incident response at scale guide covers the customer-side incident management discipline that the MDR provider feeds into. The scanner result triage workflow covers the ingestion discipline that pulls MDR-validated incidents and other source signals onto the same finding record.
Run MDR Output on a Single Operating Record
MDR programmes succeed or fail on the recordkeeping. The validated incident, the named response action, the post-incident remediation, the verification step, and the cross-cycle coverage summary all need to live on the same record as the wider vulnerability and finding queue so the SOC manager view, the detection engineering backlog, the leadership report, and the audit read all collapse into one query rather than into a multi-tool reconciliation.
SecPortal is built around a single engagement and finding record: findings management with CVSS calibration and lifecycle tracking, bulk finding import for ingesting MDR-validated incidents, scanner output, and pentest findings into the same record, engagement management for the per-cycle service review and the longer-running MDR programme, retesting workflows for the verification step after remediation, the activity log for the timestamped chain of state changes across cycles, compliance tracking for the framework alignment of the evidence pack, and AI report generation for the leadership read of the monthly cadence and the quarterly service review.
SecPortal is explicitly not an MDR provider, a SIEM, an XDR, an EDR, or an in-house SOC tooling platform. The platform does not run a 24x7 SOC, does not staff analysts, does not maintain a detection library, does not ingest live security telemetry, does not execute host isolation or account disable on the customer's behalf, and does not ship integrations into Jira, ServiceNow, Slack, PagerDuty, Opsgenie, Splunk, Microsoft Sentinel, Google Chronicle, IBM QRadar, Sumo Logic, or any other SIEM or ticketing system. The role is downstream: SecPortal is the operating record that holds MDR-validated incidents alongside scanner and pentest findings so the prioritisation, remediation, verification, and audit-evidence layers all run on one defensible record rather than across an MDR portal, a SIEM console, a pentest report folder, and an audit spreadsheet. Programmes evaluating MDR providers should pair the provider decision with the operating record decision and benchmark both against the named telemetry sources, the named response actions, the named SLA structure, and the named compliance framework.
Key Takeaways for MDR Adoption
- MDR is an operating model, not a single tool. The provider supplies analyst capacity, a detection library, a runbook set, and named active response actions on top of the customer's telemetry. The five capability layers (Telemetry Ingest, Detection Engineering, Triage and Investigation, Active Response, Evidence and Reporting) are the operational benchmark.
- Pair MDR with a clear telemetry strategy. MDR detection coverage is bounded by the telemetry the provider receives. EDR-led, SIEM-led, or hybrid MDR are valid; choose based on the surfaces the organisation actually owns and the named source quality per surface.
- Retain the internal SOC manager. MDR offsets analyst capacity, not institutional context. The internal SOC manager owns runbook quality, escalation criteria, and the relationship between the security function and the business.
- Grant active response authority with carve-outs. Named active response is the defining MDR capability. Carve-outs for critical systems, named accounts, and named business windows are how response authority and operational continuity coexist.
- Track six metrics: MTTD, MTTR, MTTC, false positive rate, coverage, closed-loop verification. MTTD and MTTR are the headline SLA. Coverage and closed-loop verification are the leading indicators of programme improvement.
- Close the loop on remediation. A validated incident produces a named remediation action against a named root cause, verified by a named owner. Programmes that skip the loop pay for repeated tier-2 investigation rather than for durable improvement.
- Hold MDR output on the wider finding record. MDR-validated incidents are findings. They have severity, ownership, remediation, and verification evidence. Holding them on the same record as scanner and pentest findings collapses the audit read and the prioritisation backlog into one source.
- Benchmark renewal on measured improvement. MDR contracts renew. The renewal decision should benchmark MTTD, MTTR, MTTC, coverage, and closed-loop verification against the prior cycle. Renewal on relationship continuity without measurable improvement is a subscription, not a programme.
- MDR belongs inside the CTEM cycle. MDR contributes detection-side validation and response-side execution. The mature pattern operates MDR as a continuous discipline and reads its output into the wider exposure cycle.
Frequently Asked Questions
What is Managed Detection and Response (MDR)?
MDR is the service category in which a provider runs continuous, 24x7 threat detection, triage, investigation, and response across the customer's telemetry sources, with named analysts, named runbooks, and named response actions. The output is a triaged, contextualised, and prioritised stream of validated incidents rather than raw alert volume.
How is MDR different from SIEM?
SIEM is a technology that collects, normalises, correlates, and searches telemetry. MDR is a service that runs analyst capacity and named response actions above the telemetry (often above the customer's SIEM). SIEM is a tool; MDR is the operating model that puts a 24x7 analyst pair in front of the tool.
How is MDR different from XDR?
XDR is a technology that cross-correlates telemetry across endpoint, network, cloud, identity, and email. MDR is a service that runs analyst capacity above a telemetry stack (which may or may not be XDR). XDR answers what the technology platform is; MDR answers who is staffing the seat in front of it.
How is MDR different from EDR?
EDR is an endpoint-side technology that runs an agent on hosts for detection, containment, and response on the endpoint. MDR is a service category that runs analyst capacity across multiple telemetry sources, often including EDR. EDR-led MDR wraps EDR plus adjacent telemetry into a 24x7 analyst-staffed service with EDR-side active response.
How is MDR different from MSSP?
Classic MSSPs forward triaged alerts to the customer. MDR providers respond on the customer's behalf with named runbooks and named response actions. The practical distinguisher is the response scope, not the category label; many MSSPs now also offer MDR-style service.
How is MDR different from an in-house SOC?
In-house SOC is staffed by the customer's own analysts. MDR outsources or co-manages that function. The mature pattern for mid-sized and enterprise organisations is a co-managed model: MDR for tier-1 and tier-2 with named active response, internal SOC manager for tier-3 depth and operating ownership.
What capability layers should an MDR provider have?
Telemetry Ingest (what the provider collects), Detection Engineering (the rule and analytics library), Triage and Investigation (analyst capacity and runbook library), Active Response (named response actions executed on the customer's behalf), and Evidence and Reporting (per-incident record, executive cadence, audit-grade output).
What does an MDR onboarding look like?
Five stages: telemetry connection, scope definition, runbook calibration, detection tuning, go-live with named SLAs. Onboardings typically run four to twelve weeks. The discipline is to invest in the calibration up front so steady-state MTTD and MTTR are bounded rather than only promised.
What metrics should an MDR programme track?
Six metrics: MTTD, MTTR, MTTC, false positive rate, coverage, and closed-loop verification. MTTD and MTTR are the headline SLA commitments. Coverage and closed-loop verification are the leading indicators of programme improvement.
What are the common MDR adoption pitfalls?
Treating MDR as a replacement for the internal SOC manager, buying without a telemetry strategy, granting response authority without carve-outs, holding MDR alerts in a parallel backlog, skipping the remediation loop, reading only the executive cadence, and renewing without benchmarking are the seven recurring failure modes.
Where does MDR fit inside a CTEM cycle?
MDR contributes to two CTEM stages. In Validation, MDR confirms whether a prioritised exposure is producing real attacker activity. In Mobilisation, MDR-validated incidents drive remediation work on the same backlog as other findings. MDR does not replace the wider CTEM cycle.
How does MDR connect to vulnerability and audit-evidence?
MDR produces validated incidents (which become findings), detection coverage records (which become framework evidence), and post-incident remediation records (which close the loop between alert and environment change). Ingesting MDR output into the wider finding record collapses the audit read and the prioritisation backlog into one source.
Scope and Limitations
This guide describes the operating shape of Managed Detection and Response as it is consumed in mainstream enterprise programmes. The vendor landscape evolves rapidly: native integrations into specific SIEM, EDR, and identity stacks, packaged detection libraries, the depth of cloud and identity active response, the precision-versus- recall properties of named providers, and the SLA structure that specific contracts ship with all shift between releases and renewals. Specific feature claims, supported integrations, named response actions, and the latency and reliability characteristics of named providers should be verified against current vendor documentation and against benchmark exercises on the organisation's own scope.
MDR is a detection-and-response layer, not a remediation layer. Programmes that adopt MDR without an underlying telemetry strategy lose the visibility the provider depends on; programmes that adopt MDR as the staffing layer above a deliberately chosen telemetry stack, with a calibrated runbook, named active response carve-outs, and the post-incident remediation loop wired into the wider finding queue, are the ones that see durable detection-and-response improvement over time.
Run MDR output on SecPortal
Stand up the operating record that holds MDR-validated incidents alongside scanner and pentest findings in under two minutes. Free plan available, no credit card required.