Human-Led MDR vs Automated MDR: Why the Analyst Difference Matters
Your MDR provider says it monitors your environment 24/7. Fine. Now test that claim. At 2 AM on a Tuesday, when an attacker abuses legitimate admin tools and slips past the initial rule set, who actually investigates? A trained analyst, or a scripted runbook that already missed the compromise on the way in? We work with SMBs across the Nordics and Europe at Falconer Security, and the single factor that most reliably separates “threat caught” from “threat missed for three weeks” is the gap between real human-led MDR and automation-only MDR with a human answering machine attached.
The 2025 Gartner Market Guide for Managed Detection and Response defines MDR as “remotely delivered, human-led, turnkey, modern SOC functions.” That phrasing is deliberate, and Gartner put “human-led” in there because too many vendors had stopped doing it. The rest of this post is about why the distinction matters, what fully automated MDR actually misses, and how to evaluate providers on the analyst layer they actually deliver rather than the one they claim.
- Gartner’s definition is deliberate. The 2025 Market Guide defines MDR as “human-led, turnkey, modern SOC functions” because too many vendors had stopped putting analysts in the loop.
- Layer the two, don’t choose. Automation filters commodity threats at machine scale; analysts own living-off-the-land activity, business email compromise, and any containment call that could break something important.
- The window is 29 minutes. CrowdStrike’s 2026 report puts average breakout time at 29 minutes with AI-enabled attacks up 89% year over year, too fast for ticket queues and too consequential for scripts.
- AI alone does not cut breach costs. IBM’s $4.44 million average drops with security AI plus analysts; automation with nobody directing it creates blind spots that look like coverage.
- Test providers on the analyst layer. Ask for analyst-to-customer ratios, real investigation narratives, last quarter’s threat hunts, and custom detection rules, not automated alert summaries.
The short answer
Human-led MDR puts trained analysts inside the detection and response loop: they triage escalated alerts, run hypothesis-driven threat hunts, and make containment decisions with business context. Automated MDR runs on detection rules and playbooks, with humans involved only at escalation, if at all. Automation wins on speed, scale, and commodity threats. Analysts win on novel techniques, living-off-the-land activity, and any response decision that could break something important. In a working MDR service the two are layered: automation does the filtering, analysts make the calls.
What human-led MDR actually means
In a human-led MDR service, trained security analysts actively triage, investigate, and respond to threats in your environment. Automation handles the grinding work, which means data collection, correlation, and the first pass of filtering. Analysts make the judgement calls. Is this suspicious activity a real attack? What is the attacker trying to do? How should we respond, and what are we willing to break to do it?
This is not the same thing as “we have analysts on staff.” Plenty of vendors have analysts somewhere in the building without having them anywhere near the detection workflow. Human-led MDR means analysts sit inside the detection and response loop. They review escalated alerts, run proactive hunts for threats that automated rules missed, and make decisions based on context machines cannot read off a log.
Key distinction: Human-led MDR does not mean analysts do everything manually. It means automation accelerates analysts, and analysts make the decisions that matter. The best MDR services combine both, using AI for speed and human judgement for accuracy.
Microsoft’s own Defender Experts for XDR service illustrates what this looks like when implemented properly. Per Microsoft Learn documentation, the service uses “a combination of automation and human expertise” to triage incidents, with experts running detailed investigations and giving actionable managed response recommendations to SOC teams.
What automated MDR looks like in practice
Automated MDR leans primarily on detection rules, machine learning models, and predefined playbooks to identify and respond to threats. When an alert triggers, the system follows a scripted workflow. It enriches the alert with threat intel, scores it, and either auto-remediates or opens a ticket.
For known, predictable threats that model works fine. Commodity malware gets contained quickly. Brute-force attempts get blocked. Known-bad IP addresses get rejected at the edge. The problem is everything else, which is to say most of what actually matters.
Where automation breaks down
- Living-off-the-land attacks: Attackers using PowerShell, PsExec, or legitimate admin tools to move laterally look identical to normal IT operations. Automated rules either miss them entirely or generate so many false positives that real attacks get buried.
- Business email compromise (BEC): Small changes in email forwarding rules or OAuth app consent do not trigger automated alerts because the individual actions are technically legitimate. Analysts recognise the pattern because they understand the business context.
- Novel attack techniques: The CrowdStrike 2026 Global Threat Report found that AI-enabled attacks surged 89% year-over-year, with average breakout times down to 29 minutes. Automated rules built for yesterday’s techniques miss tomorrow’s variations. Analysts adapt in real time.
- Alert fatigue and noise: Automation generates alerts. Without analysts filtering signal from noise, security teams drown. We routinely find that default Sentinel detection rules generate far more noise than actionable intelligence.
Human-led MDR vs automated MDR: side-by-side comparison
| Capability | Human-Led MDR | Automated MDR |
|---|---|---|
| Alert triage | Analyst reviews context, determines real vs. false positive | Rule-based scoring, auto-classification |
| Threat hunting | Proactive hypothesis-driven searches for hidden threats | Scheduled queries only, limited to known patterns |
| Novel attack detection | Analysts recognise unusual behaviour even without matching rules | Misses attacks that don’t match predefined signatures |
| Response decisions | Context-aware: analyst weighs business impact before acting | Follows playbook: may over-isolate or under-respond |
| False positive rate | Lower: analysts filter noise before escalation | Higher: automated scoring has limited context |
| Detection tuning | Continuous: analysts adjust rules based on real-world findings | Periodic: tuning depends on vendor update cycles |
| Business context | Analysts learn your environment, users, and normal operations | Limited to metadata and predefined asset classifications |
| Scalability | Constrained by analyst capacity, but expertise improves accuracy | Scales easily across large environments |
Which SOC tasks to automate and which need an analyst
The comparison above describes capabilities. Day to day, the question is more concrete: for each task in the detection and response workflow, who should own it? This is how we split the work in our own SOC, and it maps closely to how Gartner describes the division of labour in modern MDR.
| SOC task | Who should own it | Why |
|---|---|---|
| Log collection and normalisation | Fully automated | High volume, zero judgement required |
| Alert enrichment (threat intel, asset context) | Fully automated | Lookup work; machines do it faster and never skip a step |
| First-pass alert filtering | Automated, with analyst-tuned thresholds | The volume is machine-scale, but the thresholds encode analyst judgement |
| Triage of escalated alerts | Analyst, with automated scoring as input | Separating real attacks from legitimate-but-odd activity needs context |
| Incident investigation | Analyst-led, automation assists | Automation builds timelines and pulls evidence; analysts interpret it |
| Proactive threat hunting | Analyst-led | Hypothesis-driven by definition; scheduled queries are not hunting |
| Containing commodity malware | Automated | Known-bad hash on an endpoint: isolate first, review after |
| Containment with business impact | Analyst decision | Isolating a domain controller or an executive laptop is a judgement call |
| Detection rule tuning | Analyst-led, informed by automation metrics | False-positive data is automated; deciding what a rule should catch is not |
| Incident reporting (including NIS2 timelines) | Analyst-written, automation collects evidence | Regulators read narratives, not log exports |
Why Gartner emphasises the human element
The 2025 Gartner Market Guide for MDR services makes the position clear: MDR must stay human-led. AI supports analysts. AI does not replace them. Gartner projects that by 2028, 50% of MDR findings will include threat exposures (up from around 20% today), and that kind of contextual analysis is not something automated systems can deliver on their own.
Rapid7 put it more bluntly in their analysis of the Gartner Guide: “AI equals assistance, not autonomy.” The emphasis is on agentic AI models that enrich alerts, draft response paths, and filter noise. Analysts still make the final call.
Why is the analyst layer so load-bearing? Because attackers adapt faster than automated rules, and they know it. The CrowdStrike 2026 Global Threat Report puts breakout times at 29 minutes. The investigation and response window is too narrow for ticket-based workflows but still too consequential to hand to scripts that might isolate your CFO’s laptop during a board meeting over what turns out to be a false positive.
The real cost of the analyst gap
Pick an MDR provider with weak analyst coverage and the consequences show up on a spreadsheet. The IBM Cost of a Data Breach Report 2025 pegged the global average breach cost at $4.44 million, and organisations using security AI and automation reduced that cost significantly. The catch: that reduction came from AI plus analysts, not AI alone. Automation on its own, with nobody directing it, creates blind spots that look exactly like coverage until they don’t.
The ISC2 2025 Cybersecurity Workforce Study confirms a persistent global shortage, with 33% of organisations citing budget constraints as the primary driver. Building an in-house SOC with experienced analysts is rarely on the table for SMBs. That is exactly why the quality of analysts inside your MDR provider’s SOC matters more than any single feature on their platform.
What Falconer Security sees in practice: When we inherit environments from automation-heavy MDR providers, we consistently find untuned detection rules, unreviewed alert backlogs, and threats that persisted for weeks because automated systems classified them as low-severity. The technology was running. Nobody was watching.
What to look for in a human-led MDR provider
Not every provider claiming “24/7 analyst coverage” delivers the same thing. Five questions that separate real human-led MDR from marketing copy, the same ones we walk through in our MDR vendor evaluation checklist.
1. Ask about analyst-to-customer ratios
One analyst covering 200 customers is automation with human oversight bolted onto escalations. Genuine human-led MDR needs ratios where analysts can actually learn your environment. The question to ask, verbatim: how many customers does each analyst support, and can you prove it?
2. Demand transparency on response actions
A real human-led provider can show you what analysts did during an investigation. The queries they ran, the evidence they reviewed, and why they reached the response decisions they did. If the output you get is automated alert summaries and nothing else, the human layer is cosmetic.
3. Check for proactive threat hunting
Scheduled queries are automation. Hypothesis-driven hunts based on emerging intelligence are the human-led part. Ask how many threat hunts they ran in the last quarter and what they found. Vague answers mean the hunting is not actually happening, whatever the service description says.
4. Evaluate detection engineering capabilities
Does the provider write custom detection rules for your environment, or do you get the same generic rule set as every other customer? Custom detection engineering is one of the clearest indicators of genuine human-led MDR. Generic rules catch generic threats and miss the specific attack patterns targeting your industry and infrastructure.
5. Verify NIS2 and compliance alignment
For EU organisations, NIS2 Article 21 mandates specific incident handling and reporting capabilities. Your MDR provider should walk you through how their analyst workflows map to those requirements, not just point at an audit trail from automated logging. The directive text is on EUR-Lex for reference.
How human-led MDR works with Microsoft Sentinel
If you run Microsoft environments, pairing Microsoft Sentinel (cloud-native SIEM) with human-led MDR is the strongest security operations model available. What follows is how that actually plays out on an engagement.
Sentinel collects and correlates security data from across your Microsoft 365, Azure, and Entra ID environment. Automated rules handle the first layer of detection. Then human analysts take over. They review escalated incidents, hunt for threats the rules missed, tune detection logic to reduce noise, and respond to confirmed attacks with actions that factor in business impact.
That combination also answers the fundamental limitation of Sentinel on its own. I have written about it before. A SIEM without analysts is a data collection tool, not a security solution. The platform generates alerts. Analysts decide which alerts are real threats and take action.
Our managed Sentinel offering is built around dedicated analysts who learn each client’s environment, write custom KQL detection rules, and run regular threat hunts. That is the practical implementation of human-led MDR in a Microsoft-native environment. If you’re comparing where that sits against a broader outsourced monitoring function, read managed SOC services and virtual SOC alongside it.
When automated MDR makes sense
There are cases where fully automated MDR is the right answer. For an organisation with very limited budget and no existing security monitoring, automated MDR is meaningfully better than nothing. It gives you baseline coverage against commodity threats like known malware, brute-force attacks, and basic phishing. That is real protection.
But if you handle sensitive data, operate under regulatory requirements like NIS2, or face anything resembling targeted threats, automated MDR on its own leaves gaps that show up in breach reports. The question is not “can we afford human-led MDR?” The question is whether you can afford the consequences of the gaps automation-only leaves behind.
Frequently asked questions
What is the difference between human-led MDR and automated MDR?
Human-led MDR places trained security analysts at the centre of threat detection and response. Analysts actively triage alerts, investigate suspicious activity, hunt for hidden threats, and make response decisions based on business context. Automated MDR relies primarily on detection rules, machine learning, and predefined playbooks to handle alerts without consistent human review.
Why does Gartner recommend human-led MDR?
The 2025 Gartner Market Guide for MDR explicitly defines MDR as “human-led, turnkey, modern SOC functions.” Gartner emphasises that AI should support analysts rather than replace them, because advanced threats require contextual judgement that automated systems cannot reliably provide.
How do I know if my MDR provider is truly human-led?
Ask about analyst-to-customer ratios, request examples of actual investigation reports (not automated summaries), and verify that the provider runs proactive threat hunting. Genuine human-led MDR providers can point to specific threat hunts conducted, custom detection rules written, and investigation narratives showing analyst decision-making.
Can automated MDR detect living-off-the-land attacks?
Automated MDR struggles with living-off-the-land attacks because these techniques use legitimate system tools like PowerShell and PsExec. The individual actions look normal to automated rules. Human analysts catch these attacks by recognising patterns of behaviour that are technically legitimate but operationally suspicious in context.
Which SOC tasks can be fully automated?
Log collection, alert enrichment, first-pass filtering, and containment of known commodity threats run well fully automated. Everything that needs business context stays with analysts: triage of escalated alerts, incident investigation, hypothesis-driven threat hunting, containment decisions with operational impact, and regulatory incident reporting. Automation carries the volume; analysts carry the judgement.
Is human-led MDR relevant for NIS2 compliance?
Yes. NIS2 Article 21 requires organisations in essential and important sectors to implement cybersecurity risk management measures, including incident handling capabilities. Human-led MDR provides the investigation, analysis, and reporting capabilities NIS2 demands, while automated MDR may fall short of the incident response depth the directive requires.
