What Makes an MDR Service Easier to Evaluate?

TL;DR

Evaluating a Managed Detection and Response (MDR) service requires more than comparing technologies, coverage claims, or service availability. For Managed Service Providers (MSPs), the challenge is to make the operational model understandable and verifiable without overwhelming the customer with technical documentation.

A well-structured MDR offering helps customers distinguish between what the service promises, what the provider commits to deliver, and what can be demonstrated through operational evidence.

The Evaluation Problem

Two MDR services may both advertise 24/7 monitoring, expert investigation, threat hunting, and incident response. On paper, they may appear similar. In practice, their delivery models can differ considerably.

One service may include analyst-led investigation and authorised containment. Another may depend on the customer's internal team to investigate escalated alerts or approve most response actions. These differences influence how the service operates, even when the capability lists look almost identical. For MSPs, the objective is to make those differences visible before the customer makes a decision.

1. Separate Capabilities From Service Commitments

A capability describes what the provider can perform. A service commitment defines what the provider agrees to deliver under specified conditions.

For example, 24/7 monitoring describes continuous service availability. It does not automatically establish how quickly a critical alert will be acknowledged, investigated, or escalated. Response targets may depend on incident severity, available telemetry, integrated technologies, or previously agreed customer authorisation.

An MDR proposal becomes easier to evaluate when it clearly distinguishes between the service's technical possibilities and its actual delivery obligations. The service description should therefore identify:

• Capabilities available through the service.
• Activities included in the contracted scope.
• Defined service targets and commitments.
• Conditions, dependencies, and exclusions that affect delivery.

2. Make Operational Evidence Available

Customers should be able to evaluate more than descriptions of how the service is expected to work. Operational evidence helps demonstrate how investigations are documented, how incidents are communicated, and how response activities are managed.

For example, a sample incident report can show whether the customer receives a list of alerts or a documented investigation with findings, actions taken, and recommended next steps. That difference is often more informative than a long list of supported technologies. Providing this evidence does not require exposing sensitive customer information, proprietary detection logic, or internal security procedures. Appropriate anonymisation and carefully selected examples can demonstrate the structure and quality of service delivery.

Useful evaluation materials may include:

• Anonymised incident report examples.
• Sample investigation findings.
• Incident communication formats.
• Documented escalation procedures.
• Definitions and measurement methods for service metrics.
• Examples of post-incident reporting.

3. Explain What Service Metrics Actually Measure

Metrics can support MDR evaluation, but only when their definitions and measurement methods are clear. Mean Time to Detect (MTTD), Mean Time to Acknowledge (MTTA), and Mean Time to Respond (MTTR) are frequently used to describe operational performance. However, these metrics are not always calculated in the same way across providers.

For example, an investigation target and a containment target measure different operational stages. Treating them as interchangeable can create unrealistic expectations. Similarly, response time may depend on whether the provider has pre-authorised containment authority or must wait for customer approval.

A useful metric helps the customer understand how the service performs and which operational conditions affect the result. MSPs should therefore be prepared to explain:

• When measurement begins and ends.
• Which incidents or severity levels are included.
• Whether the metric represents an average, median, percentile, or another measure.
• Whether customer approval time affects the result.
• Whether the figure is a contractual commitment or a historical performance indicator.

4. Show How the Service Fits the Customer's Environment

MDR evaluation should consider the customer's actual operating environment. A service may support a wide range of technologies, but its practical value depends on which systems are deployed, which integrations are available, and where response actions can be performed. For MSPs, this means connecting the service proposal to the customer's environment rather than relying entirely on a standard capability catalogue. A service that can technically isolate an endpoint, for example, may still require the appropriate integration, permissions, and customer authorisation before that action can be performed. Identifying these requirements during evaluation helps establish realistic implementation expectations and reduces the gap between the proposed service and its operational deployment.

A practical evaluation should consider:

• Existing security technologies and available telemetry.
• Critical systems and operational dependencies.
• Required integrations and technical prerequisites.
• Internal IT and security responsibilities.
• Approval requirements for business-sensitive response actions.

5. Make the Delivery Model Understandable

In partner-led MDR, the customer may work primarily with the MSP while a backend Security Operations Center (SOC) performs investigation and response activities. The customer does not necessarily need to understand every internal workflow between the providers. However, customer-facing responsibilities must remain clear. The commercial explanation should match the operational delivery model. This means that proposals, onboarding documents, and service descriptions should consistently reflect who communicates with the customer, who performs the investigation, and who coordinates response.

This becomes particularly important when the MSP retains the customer relationship while specialist SOC operations are delivered through an external partner.

A clear delivery model should explain:

• Who communicates with the customer during an incident.
• Who requests approval for response actions.
• Who provides investigation findings and incident reports.
• Who coordinates containment and follow-up activities.
• Where responsibility transfers between the MSP, backend SOC, and customer.

The MSP Perspective: Make Evaluation Repeatable

An MDR evaluation should not depend entirely on how an individual salesperson explains the service. MSPs benefit from a consistent set of evaluation materials that can be reused across customer conversations. The objective is to provide enough information for customers to make an informed decision without exposing unnecessary internal operational detail. A consistent evaluation approach also helps align sales, technical delivery, and onboarding teams around the same service commitments.

This reduces the risk of customers purchasing a service based on expectations that differ from its actual operational scope.

A practical evaluation package may include:

• A concise MDR service description.
• A summary of coverage and exclusions.
• Sample incident reporting.
• Clearly defined service targets.
• An explanation of the delivery model and responsibilities.

The MSP Perspective: Make Evaluation Repeatable

An MDR evaluation should not depend entirely on how an individual salesperson explains the service. MSPs benefit from a consistent set of evaluation materials that can be reused across customer conversations.

The objective is to provide enough information for customers to make an informed decision without exposing unnecessary internal operational detail. A consistent evaluation approach also helps align sales, technical delivery, and onboarding teams around the same service commitments.

This reduces the risk of customers purchasing a service based on expectations that differ from its actual operational scope. A practical evaluation package may include:

• A concise MDR service description.
• A summary of coverage and exclusions.
• Sample incident reporting.
• Clearly defined service targets.
• An explanation of the delivery model and responsibilities.

Continue the MDR as a Managed Service Series

This article is part of the MDR as a Managed Service series, exploring how MSPs define, position, evaluate, and deliver managed security services.

Explore more articles and practical resources in the DIAMATIX MSP Insights.