I've signed managed detection and response (MDR) contracts. I know what the deck says in the demo, and I know what the escalation log shows twelve months later. The demo deck and escalation log tell different stories, and that disconnect is where every disappointed MDR buyer I know got stuck.
Vendor pages give buyers an accurate MDR definition with no operational value. The language is familiar: 24/7 monitoring, vague claims about machine-learning-backed detection, and expert analysts on call. Every one of those phrases survives a demo and fails a renewal.
The working definition that matters answers the questions the deck avoids: who owns detection logic for the customer environment, what the provider can do at 2 AM when something real fires, and whether the contract buys response or notification. That version of the definition exists after contract review, which is when you actually need it.
In Brief:
- Vendor pages give an accurate MDR definition with no operational value. The working definition turns on detection ownership and response authority, and it tests whether investigations produce auditable evidence.
- The label no longer tells you what you bought. Too many offerings use the MDR name for tool-led alert forwarding, while stronger services put human analysts on investigation and response.
- Alert triage scope is one of the most under-specified terms in MDR contracts. Contract scope can limit triage to severe alerts, and that limit may stay buried during the sale.
- Compressed attacker timelines make advisory-only MDR a risk decision when your team executes containment after notification.
What vendor pages say MDR is
Vendor pages usually define MDR through features. Continuous monitoring across your security telemetry. Threat detection backed by machine learning. A team of analysts watching your environment around the clock so you don't have to. It's all technically true, and it tells buyers nothing about what the contract actually delivers.
MDR should include rapid detection and analysis that lead to threat disruption and containment, with a provider analyst team handling threat hunting and incident management. The MDR label now covers both tool-first offerings and services that deliver human-driven investigation and response. A working evaluation has to separate category language from operational ownership.
What a working definition actually requires
The textbook says MDR is a remotely delivered security operations center (SOC) function managed by someone else so your team doesn't carry the load alone. It names the delivery model without proving the service depth. That sentence is true and still useless, because some traditional managed security service providers (MSSPs) have learned to rename existing services as MDR and claim the same sentence.
MDR has to own detection logic tuned to your environment. It should produce an investigation you can audit. The service needs authority to contain a real threat before your team wakes up. Otherwise, you usually have alert forwarding with a better dashboard.
Real MDR is built on capabilities most vendor definitions blur together
Real MDR depends on operational ownership behind vendor claims. Vendor pages mention each capability and define none of the work behind it.
Detection engineering: someone owns the rule library for your environment
The vendor page implies the provider writes and maintains detections for you, but the working definition asks whether those detections are tuned to your environment or shared rules applied across hundreds of customers. Some MDR providers rely heavily on third-party tooling and treat tuning as an onboarding step.
The economics push hard toward standardization, because common rules applied across many customers are how the model stays profitable. That works for commodity threats and breaks down the moment you need logic tuned to your business apps and identity model, with your risk tolerance driving the tradeoffs.
The pattern worth watching is that vendor-provided rules can become a major source of false-positive pressure. There's a difference between rule writing and detection engineering, and the practitioner version of the test is simple: if a provider cannot describe coverage in measurable terms, they're guessing more than engineering.
The custom detections that matter most, the ones catching abuse of your internal applications, are also hardest to adjudicate, because judging them requires knowing why the rule exists. That context sits with the engineer who wrote it, and in most contracts that engineer is on your team.
Investigation: the evidence chain matters more than the disposition label
The vendor page promises investigation. Too often, the buyer gets a severity label and a forwarded ticket. The working definition demands an evidence chain: the queries and pivots that surfaced the artifacts behind the verdict. Alert-forwarding services operate at the alert level and pass along what fired. MDR analysts dig into context, correlate events across data sources, compare behavior against baselines, determine scope, and then escalate.
When I was evaluating MDR providers, the question that separated the real ones was simple: when you escalate to me, can I open the case and see what you saw? Good providers let your team see the evidence artifacts that produced the conclusion. That removes the most common friction in any MDR relationship, which is guessing whether the escalation was handled the way you'd have handled it.
Watch the alert triage scope carefully: thorough providers triage every alert, while thinner services may triage only criticals and highs and never surface that limit during the sale.
Response: what containment actually looks like at 2 AM
This is the capability vendor pages obscure most, because escalation volume is easy to report and containment authority is expensive to grant. The vendor page implies the provider handles threats; the working definition asks what the provider can do at 2 AM without waiting for you to authorize it.
The divide is response authority: notification-only services observe and hand off, while active-response services isolate, terminate processes, and act before your team wakes up. Active response means direct containment without waiting for client authorization, governed by a playbook agreed during onboarding.
The provider differences are real and worth pricing into the decision, but the contract matters more than the response slide. Verify whether containment is included by default and which actions are pre-authorized, and confirm what happens when containment fails. Notification latency plus your team's response time can exceed the attacker's movement window. Advisory-only MDR assumes nothing fast will fire while the on-call is asleep, and I've stopped making that bet.
What MDR takes off the buyer's plate and what stays with the customer
MDR should remove the tier-1 and tier-2 load from your team: alert monitoring and initial triage, first-response containment, and 24/7 coverage you'd otherwise have to hire for. That matters more than it sounds for most security programs, because the bulk of real incident activity doesn't fall during business hours, and routine pre-authorized containment comes with that coverage. A well-selected MDR contract delivers on this side of the equation.
Context ownership, high-stakes remediation, and detection tuning stay with your team regardless of what MDR handles. External analysts learn your environment over time but never reach the depth your team carries.
High-stakes remediation, such as taking a production system offline or disabling an executive account, should require customer sign-off because those decisions carry organizational weight no automation can assess. Detection tuning, response playbook definition, compliance audit trails, and custom detections all stay close to the internal team. MDR delivers SOC capability through an outsourced model, but the internal judgment driving those retained decisions stays yours.
Where most MDR contracts disappoint the definition they sold
MDR disappointments cluster because scale comes from standardization, and standardization limits exactly the things buyers assume are included. Buyers most often report alert regurgitation: too many escalations with too little triage, driven by analyst quality that varies by shift.
Providers rarely say out loud that complex findings still often come back to your team, especially after hours. The 2 AM coverage you're paying a premium for can be the weakest shift in the building.
Service level agreement (SLA) fine print is where the next disappointment usually lives. A clause that commits only to reasonable efforts within a broad response window gives the provider little motivation to hit sub-hour response, and most buyers don't read that language until renewal.
Get mean time to detect (MTTD) and mean time to respond or resolve (MTTR) commitments in writing by severity, because verbal promises don't appear on invoices. Read the renewal terms too; the contract mechanics that feel routine during procurement become very expensive when you're trying to leave.
Three questions that test whether a provider fits the working definition
I've sat through enough demos to know the slide deck answers all the wrong questions confidently. Use these to expose operational ownership before you sign.
- What actions can your team take without calling me first? Response authority is the primary differentiator. The green-flag answer is specific: we isolate endpoints and terminate processes immediately, governed by the pre-authorized playbook we build during onboarding.
- Do you create your own detections, or rely on out-of-the-box vendor rules, and how do you map coverage to MITRE ATT&CK in measurable terms? Detection questions separate detection engineering from rule rebranding. If they can't talk coverage in specific terms, you're buying a shared rule library with a custom logo.
- Walk me through what happens when you detect ransomware at 3 AM, then show me your documented MTTR for the past 12 months by severity. Ask for historical delivery numbers and compare them with the SLA promise. The SLA records the commitment; the operational metric shows delivery, and where they diverge is exactly where your risk sits.
Run a proof of concept before signing; a refusal to participate is a red flag in itself. I almost signed a renewal once on the strength of a good deck, and the escalation log from the prior year told a different story; it was the document I should have read first.
When you're deciding which provider fits, the MDR renewal conversation and the MDR provider comparison are where this working definition does its real work. Daylight Security is one example worth a look: senior analysts on follow-the-sun rather than junior staff on night shifts, full business context loaded into every investigation, and an evidence chain published with each verdict rather than a black-box score.
Frequently asked questions about managed detection and response
Contract and operating boundaries usually decide whether MDR works in production. Useful answers focus on ownership, evidence, and response authority.
What is managed detection and response?
Managed detection and response is an outsourced service that owns environment-specific detection logic and investigates threats to an auditable verdict. Real MDR also has authority to contain threats without waiting for your team. It takes tier-1 and tier-2 work off your plate, along with 24/7 coverage and pre-authorized containment. It leaves internal context, high-stakes response authority, and detection tuning with your team.
What is the difference between MDR and MSSP?
The separation between MDR and MSSP comes down to response ownership. An MSSP monitors tools and forwards alerts; its SLA usually covers notification timeliness more than resolution. MDR investigates to scope and contains threats directly, with the provider's analysts handling work an MSSP would hand back to you. Because an MSSP can rebrand monitoring as MDR, verify the three capabilities in the contract before signing.
What does MDR actually do during an incident?
With active-response authority and the required integrations, an MDR service can isolate compromised hosts, terminate malicious processes, disable or suspend accounts, and revoke sessions or tokens under pre-approved response procedures, then notify you. With advisory-only scope, the provider sends a recommendation and your team executes containment. The exact actions vary by provider, so confirm in writing what they can do without your per-action approval.
How do I evaluate whether an MDR provider does real detection work?
Ask whether they build their own detections, how much of the library comes from out-of-the-box vendor rules, and how they map coverage to MITRE ATT&CK in measurable terms. A detection engineering program should discuss coverage, gaps, tuning decisions, and assumptions clearly, while a rule-rebranding function usually can't.
Confirm that analyst triage decisions feed back into detection tuning, because broken rules that never get fixed mean the loop is broken.
Does MDR replace an internal SOC team?
In my experience, it depends on your maturity. MDR can stand in where you have no SOC, and it can augment a small or growing team effectively. Context ownership, detection tuning, compliance audit trails, and high-stakes remediation authority stay internal regardless of which model you use. MDR delivers SOC capability through an outsourced model; your team's judgment and ownership still matter.