What Should an MDR Provider Actually Do for Your Business?

Managed Detection and Response has become one of the most common outsourced cybersecurity services.

It is also one of the most misunderstood.

Some organizations buy MDR expecting a fully managed security operations capability. Others discover that what they purchased is little more than alert forwarding: a provider receives security notifications, applies basic filtering, and emails the customer when something looks suspicious.

Those are very different services.

A strong MDR provider should not simply tell you that an alert occurred.

It should help answer the questions that matter during a real security event:

What happened?

Is this malicious?

What systems or users are affected?

How serious is it?

What should we do now?

Can the provider take action on our behalf?

And after the incident:

What should change so this does not happen again?

That is the difference between monitoring alerts and operating a managed detection and response capability.

MDR Should Start With Continuous Monitoring

The first responsibility of an MDR provider is obvious but fundamental: continuously monitor relevant security telemetry.

Depending on the organization, that may include:

• endpoint detection and response;
• identity security;
• email security;
• cloud workloads;
• Microsoft 365;
• firewalls and network security;
• VPN and remote access;
• SIEM telemetry;
• cloud infrastructure;
• selected application logs;
• operational technology monitoring where appropriate.

The goal is not to collect every possible log.

It is to collect enough relevant telemetry to identify suspicious behavior and investigate meaningful incidents.

Microsoft describes MDR as an expert-led service where analysts manage incident queues around the clock, triage and investigate incidents, and either take action or guide the customer’s team through response. [1]

That distinction matters.

Monitoring without investigation leaves the customer doing the hardest part.

Alert Triage Should Remove Noise

Security platforms can generate large numbers of alerts.

Not every alert represents a real attack.

An MDR provider should help distinguish:

• benign activity;
• expected administrative behavior;
• false positives;
• suspicious activity requiring investigation;
• confirmed malicious activity;
• incidents requiring immediate action.

This is where human analysis becomes important.

Automation can enrich alerts, correlate signals, and perform initial classification, but complex incidents often require context that automated systems do not fully understand.

For example, an endpoint alert may look suspicious because PowerShell executed an encoded command.

The MDR analyst should not simply forward the alert.

The analyst should determine:

• which user initiated the activity;
• whether the execution was expected;
• what process launched PowerShell;
• what the command attempted to do;
• whether the host contacted suspicious infrastructure;
• whether similar activity occurred elsewhere;
• whether credentials may have been compromised;
• whether the activity represents part of a broader attack.

The customer should receive an investigated incident, not merely a copy of the original detection.

MDR Should Investigate Across Multiple Signals

Modern attacks rarely stay within one security product.

A compromised account might begin with phishing, move through identity abuse, establish persistence on an endpoint, access cloud applications, and attempt lateral movement.

An MDR provider should be able to correlate those signals.

That may mean connecting:

• email events;
• endpoint behavior;
• authentication events;
• identity changes;
• cloud activity;
• network connections;
• threat intelligence;
• vulnerability context.

This broader investigation allows analysts to understand the scope of the incident, not just the first alert that appeared.

NIST’s incident-response guidance emphasizes the importance of detection, analysis, response, recovery, and continuous improvement as part of effective cybersecurity risk management. [2]

The same principle applies to MDR.

Detection is only the beginning.

MDR Should Provide 24/7 Coverage Where It Matters

Threat actors do not operate on business hours.

If an organization chooses MDR because it cannot staff a full internal SOC around the clock, the service should provide meaningful after-hours monitoring and escalation.

That does not necessarily mean every organization needs the same operating model.

But the agreement should clearly define:

• what is monitored 24/7;
• which alerts receive immediate investigation;
• what qualifies as a critical incident;
• how the customer is contacted;
• who is authorized to make response decisions;
• what happens if the primary contact does not respond.

A service that monitors around the clock but waits until Monday morning to escalate a confirmed ransomware event is not providing effective MDR.

MDR Should Be Able to Respond, Not Just Detect

The word Response is in MDR for a reason.

A mature provider should have a clearly defined response model.

Depending on the customer’s authorization and technology stack, response actions may include:

• isolating an endpoint;
• disabling a compromised account;
• blocking malicious indicators;
• terminating malicious processes;
• quarantining files;
• removing malicious email;
• revoking sessions or tokens;
• restricting application execution;
• guiding firewall or access-control changes.

Microsoft’s managed-response model, for example, allows experts to investigate incidents and perform actions such as device isolation, file quarantine, application restriction, user disablement, and malicious-email removal when those actions are within the customer’s approved scope. [3]

This highlights an important question organizations should ask prospective MDR providers:

What are you actually authorized and technically able to do during an incident?

Some providers only recommend actions.

Others can perform specific containment steps.

Both models can work, but the customer needs to know which one they are buying.

Response Authority Should Be Defined Before an Incident

One of the worst times to negotiate response authority is during an active breach.

Organizations should decide in advance:

• which systems the MDR provider can isolate automatically;
• which users it can disable;
• whether executives or critical accounts require approval;
• which production systems cannot be interrupted;
• how emergency authorization works;
• what communication channels should be used;
• who owns business-impact decisions.

This is especially important in manufacturing and operational environments.

Isolating an employee laptop may be straightforward.

Taking action against a system connected to production operations may require coordination with plant operations, engineering, or safety teams.

The MDR operating model should reflect the business environment.

MDR Should Include Threat Hunting

Detection rules are designed to identify known suspicious patterns.

Attackers do not always cooperate with those rules.

Threat hunting adds a proactive layer.

Instead of waiting for a specific alert, analysts search across available telemetry for indicators of attacker behavior, unusual patterns, or signs of compromise that automated detection may have missed.

Good threat hunting should be informed by:

• current threat intelligence;
• observed attacker techniques;
• the customer’s industry;
• the customer’s technology stack;
• known exposure;
• recently disclosed vulnerabilities;
• previous incidents.

Microsoft includes proactive threat hunting as a core component of its MDR service model. [1]

The important point is not that every provider must use the same methodology.

It is that MDR should not be entirely reactive.

MDR Should Improve Detection Over Time

A mature MDR relationship should become more effective as the provider learns the customer’s environment.

Over time, analysts should understand:

• normal user behavior;
• common administrative activity;
• high-value systems;
• privileged accounts;
• business-critical applications;
• recurring false positives;
• important network relationships;
• organizational risk tolerance.

That understanding should improve:

• alert fidelity;
• investigation quality;
• escalation accuracy;
• response recommendations;
• detection engineering.

If the same harmless alert generates the same unnecessary escalation every week, the service is not learning.

MDR Should Communicate Clearly During Incidents

During a significant incident, communication becomes part of the security response.

A useful MDR notification should explain:

• what was detected;
• why it matters;
• affected users or systems;
• evidence supporting the conclusion;
• actions already taken;
• actions still required;
• urgency;
• recommended next steps.

The customer should not need to decode raw security telemetry during a crisis.

Escalation paths should also be documented and tested.

Critical incidents may require phone calls, SMS, secure messaging, ticketing integrations, or other agreed channels rather than relying solely on email.

MDR Should Support Incident Response—But Not Pretend Every MDR Incident Is a Full IR Engagement

MDR and Incident Response overlap, but they are not identical.

MDR usually focuses on continuous detection, investigation, containment, and operational response.

A major incident may require deeper capabilities such as:

• forensic acquisition;
• malware analysis;
• legal coordination;
• regulatory reporting;
• breach counsel;
• insurance coordination;
• large-scale recovery;
• evidence preservation;
• root-cause analysis across multiple environments.

NIST’s current incident-response guidance emphasizes integrating response into broader cybersecurity risk management so organizations can reduce both the number and impact of incidents while improving detection, response, and recovery. [2]

Organizations should therefore understand when the MDR provider handles an incident directly and when a formal Incident Response process or separate retainer is triggered.

MDR Should Provide Visibility Into What the Provider Is Doing

Managed security should not become a black box.

Customers should be able to understand:

• incidents investigated;
• incidents escalated;
• response actions performed;
• detection improvements;
• recurring attack patterns;
• unresolved risks;
• data-source health;
• service performance.

Useful reporting might include:

• incident trends;
• mean investigation or response times;
• most common attack techniques;
• high-risk users or assets;
• recurring security-control gaps;
• telemetry coverage issues;
• recommended improvements.

The objective is not to create attractive monthly PDFs.

The objective is to help the organization understand whether its security posture is improving.

An MDR Provider Should Monitor Its Own Visibility

A detection service is only as effective as the telemetry it receives.

If an endpoint agent stops reporting, a SIEM connector fails, a firewall feed disappears, or identity telemetry is misconfigured, detection capability may degrade silently.

A mature provider should monitor the health of the security data sources it depends on.

Microsoft’s MDR offering, for example, includes monitoring of selected Sentinel connectors and deployed content because broken telemetry directly affects detection capability. [1]

This is an often-overlooked MDR requirement.

The provider should not only monitor threats.

It should monitor whether the monitoring itself is working.

What an MDR Provider Should Not Be

MDR should not be:

A ticket-forwarding service.

It should not simply copy alerts from one platform into another.

It should not overwhelm the customer with every detection.

It should not hide behind vague statements such as “24/7 monitoring” without defining what that actually means.

It should not require the customer to perform every investigation from scratch.

And it should not leave response responsibilities undefined until an incident occurs.

Questions to Ask an MDR Provider

Before selecting or renewing an MDR service, ask:

• Is monitoring truly 24/7?
• Which security platforms and telemetry sources are covered?
• Who investigates alerts?
• What percentage of detections are investigated before reaching us?
• Do you perform proactive threat hunting?
• Can you take containment actions?
• Which actions can you take without approval?
• Which actions require authorization?
• How do you handle high-value or sensitive assets?
• How are critical incidents escalated?
• Do you monitor data-source health?
• Can you integrate with our existing SIEM, EDR, cloud, and identity tools?
• How do you improve detections over time?
• What reporting do we receive?
• What happens when an incident exceeds normal MDR scope?
• How do you coordinate with our incident-response team or retainer?

The answers reveal whether the service is truly MDR or simply outsourced alert monitoring.

The Right MDR Provider Should Extend Your Team

MDR does not necessarily replace an internal security team.

For many organizations, its greatest value is extending that team.

Internal staff understand:

• the business;
• critical operations;
• internal politics;
• acceptable business risk;
• system dependencies.

The MDR provider contributes:

• continuous monitoring;
• security analysts;
• investigation capacity;
• threat hunting;
• specialized detection expertise;
• structured escalation;
• response capability.

Microsoft explicitly describes its MDR model as augmenting the customer’s SOC rather than replacing it. [1]

That is a useful way to think about the relationship.

The strongest MDR model combines external security expertise with internal business context.

Measure MDR by Outcomes, Not Alert Volume

A successful MDR service should not be judged by how many alerts it sends.

More alerts do not necessarily mean better security.

Better questions are:

• Were meaningful incidents identified quickly?
• Were false positives filtered before reaching the internal team?
• Was the incident scoped accurately?
• Were containment actions timely?
• Did analysts provide useful evidence and recommendations?
• Did the service identify weaknesses that should be corrected?
• Did the organization’s ability to detect and respond improve over time?

Ultimately, MDR should reduce the gap between security detection and decisive action.

A provider that only tells you something suspicious happened has solved only part of the problem.

A strong MDR provider helps determine what happened, how serious it is, what to do about it, and how to reduce the chance that the same attack succeeds again.

---

How CYBLU Can Help

CYBLU helps organizations strengthen security operations with managed monitoring, investigation, threat detection, response coordination, and practical security guidance.

Whether you need to extend an existing security team or build a more structured detection-and-response capability, the focus should be on outcomes: identifying meaningful threats, reducing response time, and turning security telemetry into action.

---

References

[1] Microsoft — Defender Experts MDR overview and service capabilities
[2] NIST SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations for Cybersecurity Risk Management
[3] Microsoft — Defender Experts Managed Response documentation
[4] CISA — Cybersecurity Incident and Vulnerability Response Playbooks