What Clients Need to Understand About MDR
TL;DR
Managed Detection and Response (MDR) should give customers a clear understanding of what is covered, how incidents are investigated, which response actions are available, when customer approval is required, and how responsibilities are divided.
For Managed Service Providers (MSPs), these elements should be explicit before onboarding. Clear service definitions make MDR easier to evaluate, explain, and deliver consistently.
Understanding the Service Before an Incident
MDR is often presented through technologies and capabilities: endpoint detection, telemetry, 24/7 monitoring, threat hunting, investigation, and response.
For the customer, the more important question is how these capabilities operate as a service.
A clear MDR offering should explain:
- what is covered;
- what happens after detection;
- who investigates;
- who can take action;
- when approval is required;
- how incidents are communicated;
- what remains the customer’s responsibility.
These points should be defined before an incident creates pressure around them.
What the Service Actually Covers
Coverage is one of the first areas that should be clear.
Depending on the service model and integrated technologies, MDR visibility may include:
- endpoints and servers;
- identity systems;
- email environments;
- cloud infrastructure;
- network security technologies;
- Software as a Service (SaaS) applications;
- selected security and infrastructure logs.
24/7 monitoring does not automatically mean that every system, identity, application, or data source in the customer environment is covered.
The service definition should identify which environments and data sources are included, which require additional integrations, and which remain outside scope.
This gives the customer a realistic view of where the MDR service has visibility and where additional controls may still be required.
What Happens After Detection
The service definition should state what happens after detection, which investigation steps are included, and at what point response or customer escalation begins.
For example:
- Is the alert validated by an analyst?
- Is additional context collected from the affected asset or identity?
- Is severity assigned before escalation?
- Is investigation included in the service or does the customer receive the alert for further analysis?
- What triggers movement from investigation into response?
These details distinguish a managed detection and response service from security monitoring that primarily generates and forwards alerts.
Who Can Take Action
Response authority should also be defined in advance.
Depending on the service model, response actions may include:
- isolating an endpoint;
- terminating malicious processes;
- disabling or restricting an account;
- revoking active sessions;
- blocking indicators;
- coordinating additional containment actions.
Some actions may be pre-authorised. Others may require customer approval because they could affect business operations.
The customer should know which actions the provider can initiate directly, which require approval, and what happens if an authorised customer contact cannot be reached.
This is especially important when response depends on coordination between the MSP, a backend Security Operations Center (SOC), and the customer.
What Service Targets Apply
“24/7 MDR” describes availability. It does not explain how quickly individual operational steps should occur.
Customers should understand the service targets that apply to:
- alert acknowledgement;
- investigation;
- escalation;
- customer notification;
- containment or response.
Depending on the service, these may be defined through Service Level Agreements (SLAs), severity-based procedures, or internal operational targets.
Metrics such as Mean Time to Acknowledge (MTTA), Mean Time to Detect (MTTD), and Mean Time to Respond (MTTR) can provide useful context when their definitions and measurement methods are clear.
The useful question is not simply whether a metric exists. It is what operational commitment sits behind it.
How Responsibilities Are Divided
MDR frequently involves more than one operational party.
An MSP may manage the customer relationship while a backend SOC provides 24/7 investigation and response capabilities. Technology vendors may provide additional detection or response functions. The customer’s internal team may retain authority over selected systems or business-critical decisions.
The service model should make these boundaries visible.
Customers should understand:
- what the MSP owns;
- what the backend SOC owns;
- what remains the customer’s responsibility;
- who makes decisions during an incident;
- who communicates with whom;
- where responsibility transfers between the parties.
This becomes particularly important in partner-led and white-label MDR models, where the operational work and the customer relationship may sit with different teams.
How Incidents Are Communicated
Incident communication should give the customer enough context to understand the situation and act where necessary.
Depending on severity and service scope, communication should make clear:
- what was detected;
- what the investigation established;
- which assets or identities are affected;
- how the incident is classified;
- what actions have already been taken;
- what action is required from the customer;
- what happens next.
The communication model should also define contacts and escalation paths for different severity levels and for incidents outside normal business hours.
What Happens After the Incident
Containment does not always mark the end of the service process.
Depending on scope, post-incident activities may include:
- incident documentation;
- evidence preservation;
- post-incident review;
- updates to detection logic;
- changes to response procedures;
- recommendations for reducing future exposure.
Customers should understand which of these activities are included in the MDR service and which require separate support.
For organisations subject to regulatory requirements, documented incident processes and clearly assigned responsibilities can also support broader compliance activities. MDR itself does not establish regulatory compliance.
The MSP Perspective
For MSPs, customer clarity is part of service design.
If scope, authority, responsibilities, and response expectations remain implicit, the service becomes harder to evaluate and harder to deliver consistently.
Defining these elements creates a common reference across sales, onboarding, technical teams, and incident response.
It also reduces the risk that the customer’s expectation of MDR differs from the service that has actually been agreed.
The DIAMATIX Perspective
At DIAMATIX, we believe the MDR operating model should be visible to both the MSP and the customer.
Technology provides telemetry and detection capabilities. The service model determines how that information becomes investigation, response, escalation, and communication.
For MSP partners, this requires clear boundaries between the MSP, the DIAMATIX SOC, and the customer, including agreed response authority and escalation paths.
This structure allows the MSP to retain the customer relationship while relying on specialist 24/7 SOC operations behind the service.
Closing Perspective
Customers can evaluate MDR more accurately when the service definition makes coverage, investigation, response authority, service targets, communication, and responsibility boundaries explicit.
For MSPs, this clarity reduces ambiguity before onboarding and during real incidents. It also creates a more consistent basis for positioning and delivering the service.
In the next part of this series, we will turn these elements into a practical framework for mapping MDR capabilities to operational actions and customer value.
Explore the MSP Insights & Resource Library
This article is part of the broader DIAMATIX MSP content covering managed security operations, incident response, service delivery, and operational maturity.
Use the MSP Insights & Resource Library guide to navigate the existing articles, frameworks, checklists, matrices, and assessments based on your current operational priorities.
Explore the MSP Insights & Resource Library
MDR 360° Powered by DIAMATIX SOC
DIAMATIX MDR 360° gives MSPs access to expert-led 24/7 SOC operations behind their managed security offering.
Monitoring, investigation, threat hunting, response, escalation, and incident communication are delivered through the DIAMATIX SOC, helping MSPs extend their security capabilities without building the entire operational structure internally.
