What Is MDR? An Evaluation Guide for Managed Detection and Response

Cybersecurity

Updated July 12, 2026

By Jerame Trunnell Owner of Cloud Core MSP

Managed detection and response is a service in which a provider monitors agreed telemetry, investigates suspicious activity, and performs or coordinates defined response actions. The label alone does not establish scope. Buyers need to verify which assets and identities are visible, who decides an alert is an incident, what the provider can contain, and what the customer must do next.

MDR should strengthen the Detect and Respond parts of a broader cybersecurity program, not replace governance, prevention, recovery, or business ownership. NIST Cybersecurity Framework 2.0 organizes outcomes across Govern, Identify, Protect, Detect, Respond, and Recover. That is a useful reminder that even a capable detection provider operates inside a larger risk-management system.

MDR is a service, not a synonym for every security acronym

EDR is endpoint detection and response technology. It can collect endpoint telemetry and support investigation or containment, but a tool license does not prove that qualified people are watching or responding.
SIEM centralizes and analyzes logs. It may support detections and investigations, but someone still has to design use cases, maintain data quality, triage signals, and act.
SOC is the people, process, and technology function performing security operations. It may be internal, external, or hybrid.
MSSP commonly describes a broader managed security provider that may administer firewalls, vulnerability tools, email security, compliance reporting, or monitoring. Its contract may or may not include deep investigation and active response.
MDR combines managed detection, investigation, and an agreed response service. Providers define that bundle differently, so the statement of work and operating runbook matter more than the label.

A provider may use EDR and SIEM platforms inside an MDR service or deliver MDR from a SOC. The distinction is not about which acronym is superior. It is about whether the complete service closes the path from useful telemetry to a timely, authorized, documented action.

Start with the environment the provider can actually see

Build a coverage register for endpoints, servers, cloud workloads, identity providers, email, firewalls, key SaaS applications, remote-access services, and other critical log sources. For each source, record whether it is connected, healthy, parsed, retained, and used by a detection. CISA's logging guidance for small and medium businesses recommends enabling useful logs, centralizing them, and monitoring high-risk activity. MDR cannot investigate evidence it never receives.

Ask how the provider detects a silent sensor, expired credential, disabled audit setting, unsupported operating system, or log-source outage. A deployment count can look complete while high-value evidence is absent. Require an exception report that names the asset, missing capability, risk owner, interim control, and due date.

Evaluate detections against relevant behavior

Product counts and alert volumes do not show whether detections cover the attack paths that matter to your organization. Define scenarios such as stolen cloud credentials, privilege escalation, remote-management abuse, malicious inbox rules, endpoint ransomware behavior, or data staging. MITRE ATT&CK is a knowledge base of observed adversary behavior, and its Navigator and machine-readable ATT&CK data can help teams map and discuss defensive coverage. A mapping is evidence of design intent, not proof that a detection works in your environment.

Ask for controlled validation: what safe test, simulation, historical example, or detection-engineering evidence demonstrates that the provider receives the signal and routes it correctly? Record exclusions. Never authorize disruptive testing in production without an approved plan.

MDR evaluation matrix

Give each provider the same matrix and require evidence beside every answer. "Included" is not evidence; request a sample deliverable, contract reference, runbook section, portal demonstration, or controlled test result.

Capability	Questions to answer	Evidence to request	Customer decision
Coverage	Which assets, identities, log sources, locations, and operating systems are in scope?	Coverage register, health view, exclusions, and onboarding acceptance criteria	Accept gaps, add sources, or change scope
Detection	Which relevant behaviors are detected, and how are rules maintained and validated?	Scenario mapping, sanitized detection example, and test method	Approve priority scenarios and residual gaps
Investigation	What enrichment, correlation, threat context, and human analysis occur before escalation?	Sanitized incident narrative with evidence and confidence statement	Define the minimum useful escalation record
Response authority	Can the provider isolate devices, disable accounts, block indicators, or only recommend?	Action matrix, preauthorization rules, rollback path, and audit trail	Authorize each action by scenario and asset class
Communications	Which channel, contacts, severity definitions, and fallback method are used?	Escalation runbook and communication exercise result	Name primary and backup decision makers
Evidence and handoff	What timeline, affected assets, actions, artifacts, and next steps are retained?	Sample case record, export method, retention statement, and closure review	Confirm internal, insurer, counsel, or regulator workflows as applicable
Service resilience	How does monitoring continue through provider, platform, or customer outages?	Continuity plan, degraded-mode process, and status communication method	Accept the fallback and remaining risk

Write response authority before an incident

Containment can interrupt critical work, so define authority by action and asset class. The provider might be preauthorized to isolate a standard workstation but required to contact a named owner before disabling a clinical system, production server, executive account, or network segment. Record who can approve action, how long the provider waits, what happens when contacts do not answer, and how a containment action is reversed.

NIST SP 800-61 Revision 3 integrates incident response throughout cybersecurity risk management rather than treating it as an isolated technical phase. CISA's federal Incident and Vulnerability Response Playbooks are specifically written for federal civilian agencies, but their broader practices around coordinated analysis, remediation, recovery, and tracking provide useful questions for private operating runbooks. They do not make federal procedures mandatory for private buyers.

Test the operating relationship before trusting it

Run an onboarding acceptance test and then recurring exercises appropriate to risk. Use a safe scenario in which a priority signal appears, the provider investigates it, the correct contacts receive the escalation through primary and fallback channels, an authorized action is discussed or performed safely, and the final record is exported. Measure the handoffs you control rather than adopting a universal speed claim.

Track sensor and log-source health, coverage exceptions, investigated cases, false-positive learning, actions awaiting customer approval, repeat incident patterns, exercise findings, and overdue remediation. Do not treat high alert volume as proof of protection or low alert volume as proof of safety. The useful question is whether relevant activity becomes a supported decision.

Check provider access as part of the risk

An MDR or other managed provider may hold powerful access into customer systems. CISA and international partners recommend that MSPs and customers clearly understand shared responsibilities, manage privileged access, improve logging, and plan incident response in their managed service provider advisory. Ask how provider identities are protected, separated, reviewed, logged, and removed; how subcontractors are governed; and how the provider notifies customers about an incident affecting its service.

Related guidance

Use the MSSP engagement model when the scope extends beyond MDR. Reduce a major source of identity signals with the password risk guide. Validate escalation and leadership decisions with an incident response tabletop playbook.

Primary sources

Suggested next step

Contact Cloud Core MSP if you want to compare an MDR proposal against the telemetry, authority, evidence, and handoffs your organization actually needs.