Managed detection and response, or MDR, is a cybersecurity service that combines security technology with an external team responsible for monitoring agreed data, validating suspicious activity, investigating threats, and supporting or carrying out response actions within a defined scope.
MDR is a service category rather than a single product. An MDR provider may operate endpoint detection and response, extended detection and response, security information and event management, cloud, identity, email, and network tools. The service comes from the people, processes, coverage, authority, and accountability wrapped around those technologies.
The contract sets the practical boundary. Two providers can both offer "24/7 MDR" while accepting very different responsibilities for human review, threat hunting, containment, incident coordination, evidence, and after-hours action.
Free guide
Understand what changes MDR cost and scope
The Q-Sec MDR pricing guide explains European pricing models, response-ownership differences, investigation scope, hidden fees, and the questions buyers should ask before comparing proposals.
Get the MDR pricing guideThis table gives the shortest useful description of the service. The exact technology and response boundary will differ by contract.
| Question | Short answer |
| What is MDR? | A managed cybersecurity service for continuous detection, human-led investigation, threat hunting, and agreed response work |
| What does it monitor? | Contracted telemetry from endpoints, identities, cloud services, email, networks, applications, and security platforms |
| Who operates it? | Provider analysts and engineers, often working with an internal security or IT team |
| What does it produce? | Validated incidents, investigation records, response actions or guidance, service reports, and detection improvements |
| What determines response? | Scope, access, playbooks, service hours, severity rules, approvals, and pre-authorized actions |
| What stays with the customer? | Business risk, executive decisions, recovery priorities, legal duties, communications, and provider oversight |
Gartner's public summary for the 2025 Market Guide for Managed Detection and Response describes MDR as a remotely delivered, human-led modern security operations function intended to disrupt and contain attacks. That definition contains three useful boundaries.
First, MDR is remotely delivered. The provider connects to agreed sources and action channels without becoming the owner of the customer's whole environment. Second, the service is human-led. Analytics and automation can collect evidence or run approved steps, but analysts still judge conflicting evidence and business risk. Third, disruption and containment require authority. A provider cannot isolate a host, disable an account, or change a control simply because an alert exists.
The FIRST CSIRT Services Framework offers a consistent vocabulary for incident-management services. An MDR contract should be just as exact. Terms that sound interchangeable in a proposal can describe different work.
Use the terms below as contract questions, not as decoration around a product list.
| Term | Plain-language meaning | What must be defined |
| Telemetry | Security data collected from systems, users, services, and controls | Sources, fields, health checks, retention, time synchronization, and exclusions |
| Detection | Logic or analysis that identifies activity worth examining | Covered use cases, testing, ownership, tuning, and evidence of operation |
| Alert | A signal produced by a tool or rule | Which alerts receive human review and within which service hours |
| Triage and validation | Initial examination to decide whether activity is harmless, suspicious, or an incident | Severity rules, evidence checks, closure criteria, and escalation clock |
| Investigation | Reconstruction of what happened, what is affected, and what the attacker may do next | Depth, data access, handoff point, case record, and limits |
| Threat hunting | Hypothesis-led search for activity that existing alerts did not surface | Frequency, telemetry, method, outputs, and follow-up work |
| Containment | Action intended to stop spread or reduce immediate harm | Permitted actions, approval route, exceptions, rollback, and evidence |
| Remediation and recovery | Removal of the cause and restoration of trusted business operation | Whether the provider performs, guides, or excludes the work |
| Playbook or runbook | Agreed sequence for investigation, decision, action, and escalation | Trigger, owner, approvals, service hours, evidence, and testing schedule |
| Service-level agreement | Contracted timer and service condition | Start event, finish event, severity, pause rules, exclusions, and proof |
MDR works as a managed operating cycle. The provider and customer connect data, establish context, detect and validate activity, investigate credible threats, act within agreed authority, and use the case record to improve future coverage.
The provider and customer identify the systems, identities, cloud services, locations, business owners, data sources, and response channels covered by the service. Typical connections include endpoint tools, SIEM, identity platforms, cloud audit sources, email controls, network telemetry, firewalls, case systems, and ticketing tools.
Connection is more than sending events. The onboarding work must settle data retention, source health, remote access, time synchronization, field quality, permissions, escalation contacts, and the systems where automatic action could interrupt a critical process.
Analysts need to know which assets support critical services, which identities hold elevated privileges, which systems face the internet, and which changes are expected. Context helps separate an unusual but legitimate event from an incident that requires immediate attention.
The environment will change after onboarding. New cloud accounts, acquisitions, remote-access changes, and software deployments alter the evidence and attack paths available to analysts. Context and source coverage require scheduled review.
Detection logic examines endpoint behavior, authentication records, cloud control-plane events, email signals, network activity, and other contracted telemetry. A detection can come from a rule, behavior model, indicator match, threat-intelligence input, or correlation across several systems.
Many teams map coverage to MITRE ATT&CK, a knowledge base of adversary tactics and techniques based on observed activity. ATT&CK's current Detection Strategies can help teams connect adversary behavior with analytics and data requirements. The map is useful when it leads to collection, testing, and ownership decisions.
An analyst checks the alert, the affected asset or identity, related activity, available evidence, and business context. The immediate decision is whether to close harmless activity, continue investigation, or escalate a credible incident.
Automation can collect supporting records, enrich an indicator, open a case, or execute a repeatable check. Human judgment remains important when evidence conflicts, several systems are involved, or a response action could disrupt operations.
For suspicious or confirmed activity, the analyst reconstructs the sequence of events, searches for related behavior, and tests possible explanations. The investigation may reveal lateral movement, persistence, credential misuse, data access, or additional affected systems.
Threat hunting begins with a question rather than a tool alert. Analysts form a hypothesis from threat intelligence, observed attacker behavior, or a known weakness, then search the available telemetry for supporting or contradictory evidence. Hunting depth depends on data quality and the time assigned to the work.
Possible containment actions include isolating an endpoint, disabling an account, revoking a session, blocking an indicator, quarantining email, or changing a firewall rule. The provider's authority must be agreed before the incident. Access, safety checks, approval paths, exceptions, and rollback steps must also work in practice.
Some MDR contracts stop at notification and advice. Others permit guided, approval-based, or pre-authorized action. That distinction is examined in Q-Sec's expert article on what response means after detection.
The case record should contain the evidence, timeline, severity, decisions, actions, approvals, owners, and outcome. Detection logic, response playbooks, allow lists, collection rules, and escalation paths should change when an investigation exposes a gap.
Service reviews should inspect source health, detection changes, case quality, response performance, open coverage gaps, and actions assigned to each party. A monthly report is useful only when its figures can be traced to defined scope and evidence.
When an MDR service says "response," what does that actually mean? Read Q-Sec's expert view of the decisions that begin after a threat is detected, including response models, containment ownership, and the questions buyers should settle before signing.
An MDR service can operate a provider platform, the customer's existing technology, or a combined stack. The data and action channels should follow the risks and systems in scope. A long connector list has little value when the fields needed for an investigation are missing, delayed, or poorly parsed.
Common sources and controls include:
For the detailed technology map, read Q-Sec's SOC Tools Stack guide. It explains the jobs performed by SIEM, EDR, XDR, network, cloud, case management, intelligence, and specialist tools. MDR is the operating service that puts selected technologies, people, and response processes to work.
The cleanest distinction is whether the term describes a product, a team or function, or a managed service. Vendor packaging can blur the edges, so the contract still needs to state the actual work.
| Term | Category | Main job | Relationship to MDR |
| EDR | Product | Collect endpoint evidence, detect suspicious behavior, support investigation, and provide endpoint actions | A common MDR data source and containment channel |
| XDR | Product or platform | Correlate signals and actions across an integrated set of endpoint, identity, email, cloud, and network controls | An MDR provider may operate XDR as part of the service |
| SIEM | Platform | Collect, search, correlate, and retain events from many sources | MDR analysts may use the customer's SIEM or a provider platform |
| Security orchestration | Platform | Coordinate repeatable enrichment, case, notification, and response steps | Supports MDR workflows when playbooks, permissions, and failure handling are sound |
| SOC | Team or operating function | Monitor, investigate, respond, measure, and improve security operations | MDR supplies an agreed portion of SOC work through an external service |
| SOCaaS | Managed service | Provide a broader outsourced SOC operating model, often including SIEM operations, reporting, and service management | Can overlap with MDR; scope and operating ownership decide the difference |
| MSSP | Provider or broad service model | Manage security devices, platforms, and recurring security tasks | MDR is normally more focused on investigation and response outcomes |
MDR does not automatically replace any of these technologies or operating models. A service can depend on EDR, use SIEM for evidence, coordinate through orchestration, and work alongside an internal SOC at the same time.
There is no universal MDR package. A buyer should expect each capability to be stated in the proposal, statement of work, runbook, and service-level agreement.
| Capability | Common MDR work | Scope that often varies |
| Monitoring | Review contracted telemetry and surface activity that requires attention | Service hours, data sources, source-health monitoring, and human-review coverage |
| Detection engineering | Maintain rules, analytics, tuning, testing, and coverage records | Custom-content ownership, testing frequency, and change approval |
| Alert validation | Prioritize, enrich, validate, and close activity with a documented reason | Which alerts receive analyst review and how quickly |
| Investigation | Reconstruct timelines, scope affected systems, assess cause, and collect evidence | Investigation depth, cross-tenant work, and handoff point |
| Threat hunting | Search for activity that existing detections did not surface | Frequency, telemetry, method, deliverables, and follow-up work |
| Containment | Carry out or guide approved actions against hosts, identities, sessions, email, network controls, or cloud resources | Pre-authorization, approval route, exclusions, and service hours |
| Threat intelligence | Add regional, sector, campaign, technique, and indicator context | Sources, confidence, expiry, and how intelligence changes action |
| Reporting | Provide case records, service measures, coverage status, and management summaries | Audience, evidence detail, frequency, retention, and export rights |
| Service management | Maintain contacts, test escalation, review source health, and track service changes | Named owner, review schedule, backlog, and exit support |
Full digital forensics, malware reverse engineering, system rebuilding, backup restoration, broad vulnerability remediation, legal advice, regulatory notification, public communication, on-site response, and long-term recovery often sit outside the base service. Some providers include selected parts of that work or sell them through another service. The agreement should state the boundary directly.
MDR changes who performs agreed detection and response work. It does not remove the organization's responsibility for the business, its systems, or its legal duties.
The customer normally retains responsibility for:
NIST SP 800-61 Revision 3 places incident response within wider cybersecurity risk management and connects detection, response, and recovery with governance and preparation. MDR can perform part of that work. The organization still owns the wider risk and business decisions.
MDR is often a good fit when an organization owns security technology but lacks one or more operating capabilities:
MDR can also supplement an established internal SOC. A co-managed arrangement can assign selected hours, technologies, threat classes, or escalation levels to the provider while internal staff retain business context and strategic control.
The service will struggle when the environment has no dependable asset and identity context, critical data cannot be connected, response access is blocked, contacts are unreachable, or neither party owns remediation. Those conditions should become onboarding work with named owners rather than assumptions hidden in the contract.
The following decisions turn a service description into an operating agreement:
These decisions should be tested with a realistic scenario. A compromised administrator account at 2 a.m., an unreachable primary contact, and an attacker moving toward a critical system will reveal more than a slide that says "rapid response."
Managed detection and response works when connected data, human investigation, response authority, and customer responsibility agree with one another. The service label cannot repair a missing data source, an untested action path, or an approval chain that stops after business hours.
A provider's MDR label matters less than whether both teams can explain who sees the evidence, who makes the decision, who can act, which record proves it, and what happens when the incident exceeds the contracted boundary.
Put detection, investigation, and response into one operating service
Q-Sec Advanced Detection & Response connects to existing EDR, SIEM, cloud, and identity sources and adds analyst-led monitoring, investigation, threat hunting, and agreed containment.
MDR is a managed service delivered through analysts, processes, and security technology. The provider may operate EDR, XDR, SIEM, cloud, identity, network, and case-management tools as part of the service.
No. EDR supplies endpoint data, detections, investigation evidence, and response actions. MDR supplies a managed operating team and service process. Many MDR services depend on EDR as a core source.
MDR can operate with a customer SIEM, a provider analytics platform, or both. The organization still needs to decide where logs, cases, detections, and evidence are stored and retained.
No. Hunting frequency, telemetry, method, and deliverables vary. The contract should state whether hunting is continuous, scheduled, incident-triggered, or limited to selected data sources.
Most MDR services include some response support. Full forensics, eradication, recovery, legal coordination, or on-site work may require another service. The agreement should define the handoff point.
The label is incomplete by itself. Confirm which activities run continuously: data collection, alerting, human triage, investigation, containment, and customer notification. Each can have a different service condition.
The provider needs telemetry and context that support agreed use cases. Common sources include endpoints, identity, cloud, email, networks, applications, SIEM, and security controls, with enough retention for investigation.
Timing depends on scope, access, integrations, data quality, use cases and response approvals. Instead of one deployment date, use phased acceptance criteria for each source and workflow.