Threat Detection & ResponseMay 26, 2026 · 12 min read

Managed detection and response (MDR): what it is and when you need it

MDR is a team that watches your environment, decides what is real, and acts when it matters. See how it differs from SIEM, MSSP, and EDR, and when to buy it.
A security analyst monitoring threat detection alerts on multiple screens.

Managed detection and response (MDR) is a service that watches your environment for attacks around the clock, investigates the alerts that matter, and takes action to contain a threat before it spreads. You buy outcomes, not a tool. A provider operates the detection technology, staffs analysts to triage what the technology surfaces, and either responds on your behalf or hands you a clear set of steps with the evidence to act fast. The point of MDR is to shorten the time between the first sign of an intrusion and the moment that intrusion stops mattering.

You need MDR when you have systems worth attacking and no team that can credibly watch them at 3 a.m. on a Sunday. That describes most regulated mid-market and enterprise companies. You have already bought security tools. You have logs nobody reads. You have a small team that cannot work three shifts. Attackers do not keep office hours, and regulations such as the NIS2 Directive and DORA now expect you to detect, contain, and report incidents on tight clocks. MDR exists to close that gap, and this post explains what it covers, how it works, what to watch for, and when it is the right call.

What MDR actually is

MDR combines technology, telemetry, and human analysts into a single service that detects and responds to threats. The technology is usually an endpoint detection and response (EDR) agent, often paired with network sensors, identity signals, and cloud logs. The service layer is the part you are really paying for. Skilled analysts review detections, separate real attacks from noise, run an investigation, and contain the threat. Without the human layer you have a pile of alerts. With it you have answers and action.

It helps to define MDR against its neighbors. A SIEM (security information and event management) collects and correlates logs, but it does not investigate for you. An MSSP (managed security services provider) often forwards alerts to your inbox and stops there. A SOC (security operations center) is the function MDR delivers as a service. MDR is the packaged version of running a SOC, staffed by people who do detection and response for a living, priced so you do not have to hire and retain a night shift yourself.

We treat MDR as the operational counterpart to the testing work we do on the offensive side. Offensive engagements find the ways in. MDR catches the adversary who finds a way in regardless. The two reinforce each other, and our threat detection and response service is built to use what testing teaches about your real attack paths.

The core components of an MDR service

A complete MDR offering is more than an EDR console with a phone number attached. The parts below work together, and a gap in any one of them weakens the whole. When you evaluate providers, check that each component is present and that the provider, not you, owns the operational burden for it.

  • Telemetry collection across endpoints, identity providers, network traffic, and cloud control planes, because attackers move between these layers and single-source detection misses lateral movement.
  • A detection engine tuned with behavioral analytics and threat intelligence, mapped to a framework such as MITRE ATT&CK so coverage and gaps can be described in concrete attacker techniques.
  • Human triage and investigation by analysts who validate alerts, gather context, and decide whether an event is benign, suspicious, or a confirmed incident.
  • Response actions, ranging from isolating a host and disabling an account to guided remediation steps your team executes, with the level of autonomy agreed in advance.
  • Threat hunting that proactively searches for attacker behavior that slipped past automated detection, because mature adversaries are designed to evade signatures.
  • Reporting and metrics that show what was detected, how fast it was handled, and where your environment remains exposed, which is also what auditors and regulators will ask to see.

How MDR works, step by step

The value of MDR lives in the sequence between an attacker acting and the threat being contained. A good provider runs this loop continuously and measures every stage. The faster and cleaner the loop, the less damage an intrusion can do.

  • Collect. Agents and sensors stream telemetry from endpoints, identities, networks, and cloud services into the detection platform in near real time.
  • Detect. The platform applies behavioral rules, machine learning, and threat intelligence to flag activity that matches known and suspected attacker techniques.
  • Triage. An analyst reviews the detection, removes false positives, enriches the alert with context, and assigns severity so the team works the right things first.
  • Investigate. The analyst reconstructs what happened, determines scope, identifies affected assets, and confirms whether an incident is in progress.
  • Respond. The provider contains the threat by isolating hosts, killing processes, revoking sessions, or directing your team through precise remediation steps.
  • Report and improve. The provider documents the incident, feeds lessons back into detection rules, and adjusts coverage so the same technique does not work twice.
An alert nobody reads is not detection. It is a record, created after the fact, that the signal was available and was not acted on.

What you actually get as a buyer

It is easy to lose the deliverables behind the acronym. When you sign an MDR contract you should know exactly what arrives, what runs continuously, and what you can hold the provider to. The list below is what a serious engagement puts on the table. If a provider cannot describe these in plain terms, that is a signal worth noting.

  • Continuous monitoring with defined coverage hours, which for regulated firms should mean 24 hours a day, every day, including holidays.
  • Documented service levels for time to acknowledge, time to investigate, and time to respond, expressed in minutes and hours rather than vague promises.
  • A named escalation path so that during an incident you know who is acting, who is deciding, and how you reach them.
  • Incident reports with timelines, affected assets, root cause, and the actions taken, written so both engineers and executives can use them.
  • Regular coverage reviews that show which attacker techniques you can detect and which you cannot, so investment decisions are based on evidence.
  • Onboarding that tunes detections to your environment, because rules shipped out of the box generate noise until someone adapts them to how your business actually operates.

MDR compared to building your own SOC

The real decision for most leaders is not MDR versus nothing. It is MDR versus building and staffing detection in house. Running a 24 by 7 SOC means hiring at least eight to ten analysts to cover three shifts with vacation and turnover, plus engineers to maintain the tooling and a manager to run it. Skilled detection analysts are scarce and expensive, and night shift roles are the hardest to keep filled. The first year of an in house SOC is mostly spent hiring, tuning, and writing playbooks rather than catching attackers.

MDR shifts that burden to a provider who already has the people, the platform, and the playbooks. You trade some control and some customization for speed, coverage, and predictable cost. The trade is usually worth it for mid-market firms and for enterprises that want to focus internal talent on engineering and risk rather than on staffing a night desk. The honest counterpoint is that MDR works best when you keep an internal owner who manages the relationship, approves response actions, and connects detection to your wider governance and risk program.

When you need MDR, and when you might not

MDR is not mandatory for every organization, and pretending otherwise wastes money. The signals below indicate that you have crossed the line where MDR becomes the rational choice. Most regulated companies cross several of them at once.

  • You hold sensitive data such as financial records, health information, or large volumes of personal data that make you a deliberate target rather than an opportunistic one.
  • You fall under regulations like the NIS2 Directive or DORA that require you to detect and report incidents within fixed windows you cannot meet manually.
  • Your team cannot realistically provide 24 by 7 coverage, which is true for almost any security team under twenty people.
  • You have bought detection tools that generate more alerts than anyone reviews, so you are paying for telemetry you do not act on.
  • You have suffered an incident or a near miss and discovered that detection and response were slower than the attack.
  • Your customers or insurers now ask for evidence of continuous monitoring and tested incident response as a condition of doing business.

You may not need full MDR yet if you are a small company with no regulated data, a flat attack surface, and few endpoints. In that case a well configured EDR with alerting and a documented response plan can be a reasonable interim step. Be honest about which situation you are in. Many firms convince themselves they are in the simple case right up to the day they are not. If you are unsure, an external attack surface assessment is a low cost way to see how exposed you actually are before committing to a monitoring contract.

How MDR connects to compliance frameworks

Regulators have stopped accepting prevention alone. The frameworks that govern regulated firms now expect detection, response, and evidence that both work. MDR maps directly onto these expectations, which is why it has moved from a nice to have to a near requirement in finance, healthcare, and critical infrastructure.

  • The NIS2 Directive (EU) 2022/2555 requires in scope entities to handle incidents and report significant ones quickly, with an early warning expected within 24 hours, which is only feasible with continuous detection in place. Our NIS2 guidance breaks down who is in scope.
  • DORA Regulation (EU) 2022/2554, in force since January 2025, obliges financial entities to detect, manage, and report ICT incidents and to test their resilience, and MDR provides the operational detection layer that the DORA framework assumes you have.
  • ISO/IEC 27001:2022, with its 93 Annex A controls across four themes, includes controls for logging, monitoring, and incident management that MDR helps you operate rather than merely document, as covered in our ISO 27001 work.
  • SOC 2 Trust Services Criteria expect monitoring of systems and a defined incident response capability, and an auditor will look for the evidence that MDR naturally produces.
  • MITRE ATT&CK gives a shared language for describing detection coverage, so you can show an assessor which adversary techniques you can see and which you cannot, in concrete terms.

A point worth stressing for buyers chasing a certificate. Passing an audit and being defensible are not the same thing, a theme we return to in why a SOC 2 report is not a security program. MDR is one of the controls that closes the gap between a clean report and an environment that actually resists an attacker.

Common mistakes and red flags

We see the same failures repeatedly when companies adopt MDR badly or buy from a weak provider. Most of these are avoidable if you know what to look for before you sign. Treat the following as a checklist during evaluation and during the first ninety days of service.

  • Alert forwarding dressed up as MDR, where the provider emails you detections and expects your team to investigate, which leaves you doing the hard part you paid to outsource.
  • No agreed response authority, so during a real incident the provider waits for approvals while the attacker keeps moving through your network.
  • Coverage gaps in identity and cloud, where the service watches endpoints but ignores the login and control plane activity that modern attacks rely on, a risk we explore in the quiet danger of cloud IAM.
  • Detections left at default settings, producing so much noise that real signals are buried, which is the exact problem we examine in separating signal from noise in MDR.
  • No measurable service levels, so you cannot tell whether response is fast or slow until an incident proves it slow.
  • Treating MDR as a substitute for fixing the underlying weaknesses, when monitoring detects exploitation but does not remove the vulnerabilities that let exploitation happen in the first place.

What MDR costs and what drives the price

MDR is usually priced per endpoint, per user, or per volume of data ingested, with a monthly or annual subscription. The right way to judge cost is against the alternative of building the same capability yourself. A 24 by 7 internal SOC for a mid-market firm runs well into seven figures a year once you count salaries, tooling, and turnover. MDR typically lands at a fraction of that because the provider spreads its people and platform across many clients. The variables that move your price include the number of assets monitored, how many data sources you connect, the response autonomy you want, and whether you need dedicated analysts or a shared pool. The cheapest quote is rarely the best value, and the same discipline we apply to judging penetration testing cost applies here. Pay for the human layer, because that is what turns telemetry into protection.

Where to start

If you have data worth stealing and a team that cannot watch it every hour, MDR is the rational way to close the gap between an attack starting and an attack stopping. Start by mapping what you can detect today against where your real exposure is, then decide whether to build, buy, or combine the two. Our threat detection and response service pairs continuous monitoring with the offensive testing that tells us where attackers will actually go. When you are ready to scope it against your environment and your regulatory obligations, book a scoping call and we will walk through your coverage, your gaps, and a realistic plan to close them.

Frequently asked questions

Is MDR the same as EDR?
No. EDR is a technology that detects and lets you respond to threats on endpoints. MDR is a service that operates EDR and other tools for you, adds human analysts who investigate, and takes or directs response action. EDR is a component MDR uses. Buying EDR without the people to run it leaves you with alerts and no one watching them.
Does MDR replace penetration testing?
No, and treating one as a substitute for the other is a common error. Penetration testing finds the weaknesses an attacker could exploit, while MDR detects and responds when an attacker tries to exploit weaknesses in production. You need both. We explain the difference between proactive testing and reactive monitoring further in [why a scan is not a pentest](/blog/pentest-vs-scan), and the same logic separates testing from detection.
How fast should an MDR provider respond?
Look for committed service levels measured in minutes for acknowledgment and investigation of high severity detections, not hours or days. The exact numbers depend on your risk tolerance and your regulatory clocks, but a provider who will not commit to specific response times in the contract is asking you to trust a promise you cannot enforce.
Can MDR help us meet NIS2 or DORA?
It helps significantly but does not make you compliant on its own. MDR supplies the continuous detection and incident handling that both regimes assume, which makes their reporting deadlines achievable. You still need governance, risk management, documented processes, and testing around it. The relationship between the two regimes is covered in our comparison of [NIS2 and DORA](/blog/nis2-vs-dora).
What do we need to provide to onboard MDR?
You provide access to telemetry sources such as endpoints, identity systems, and cloud accounts, plus a point of contact who can approve response actions and answer questions about your environment. Good onboarding also includes a tuning period where the provider adapts detections to how your business operates, so expect the first few weeks to involve collaboration rather than silence.

Sources

  1. 1NIST. Cybersecurity Framework (CSF) 2.0 — Detect & Respond. National Institute of Standards and Technology, 2024. Link
  2. 2ENISA. ENISA Threat Landscape. European Union Agency for Cybersecurity, 2024. Link
Related service
Threat Detection & Response
Want this tested on your own systems?
Our team will scope it with you on a 30-minute call.
Book a scoping call