Defining the MDR Service Boundary
What is included, where responsibility changes, and what remains outside scope.
TL;DR
An MDR service boundary defines more than which technologies are monitored.
It establishes what the service covers, which activities are performed by the provider, where response authority applies, which dependencies sit with the customer, and where responsibility moves between the MSP, backend SOC, and customer.
For Managed Service Providers (MSPs), defining these boundaries before onboarding reduces ambiguity during delivery and gives commercial and technical teams the same understanding of the service.
A Service Needs a Boundary
An MDR offering may include 24/7 monitoring, investigation, threat hunting, response, escalation, and incident communication.
But each of these capabilities has limits.
Monitoring depends on connected data sources. Investigation depends on available telemetry. Response depends on technical integrations and agreed authority. Escalation depends on defined contacts and procedures.
This means the boundary of an MDR service cannot be described only by a list of capabilities.
It needs to define where those capabilities apply and under what conditions.
Start With Coverage
The first boundary is technical coverage.
An MDR service may have visibility across endpoints, identities, email, cloud infrastructure, network security technologies, Software as a Service (SaaS) applications, and selected logs.
But coverage should be specific.
For example, saying that an MDR service covers “cloud” does not necessarily explain which environments, accounts, workloads, or data sources are connected.
The same applies to endpoints, identities, and network infrastructure.
A useful service definition should make clear:
- which environments and technologies are monitored;
- which data sources are required;
- which integrations are included;
- what remains outside the service scope.
This prevents the service scope from being broader in expectation than it is operationally.
Define the Investigation Boundary
Detection does not automatically mean that every alert receives the same level of investigation.
The service should define what happens after relevant activity is identified.
Does the SOC validate the event?
Does it correlate additional telemetry?
Does the analyst investigate the affected identity, endpoint, or environment?
At what point does the investigation become an escalation to the MSP or customer?
The objective is not to document every analyst procedure in the service description. It is to make clear what level of investigation the service is responsible for delivering.
Define the Response Boundary
Response is where service boundaries become particularly important.
An MDR provider may technically be capable of isolating an endpoint, revoking a session, disabling an account, or blocking an indicator. That does not automatically mean every action is authorised in every customer environment.
The operating model should distinguish between:
- actions that can be taken immediately;
- actions that are pre-authorised under defined conditions;
- actions that require customer approval;
- actions that remain entirely with the customer.
This distinction is especially important where containment could affect business-critical systems or operations.
Response capability describes what is technically possible.
Response authority defines what the service is actually allowed to do.
Make Dependencies Visible
Some parts of MDR delivery depend on conditions outside the provider’s direct control.
Examples may include:
- the availability and quality of telemetry;
- correct deployment of required agents or integrations;
- access to relevant systems;
- current customer contacts;
- timely approval for restricted response actions;
- customer-owned remediation activities.
These dependencies should not remain implicit.
If a response target depends on customer approval, that dependency affects how the target should be understood. If investigation depends on a data source that has not been integrated, that affects the available visibility.
Making dependencies visible creates a more accurate service model.
Define Where Responsibility Changes
Partner-led MDR can involve several parties:
MSP → Backend SOC → Customer → Technology Provider
The customer may see one service, but operational responsibility can move between different teams during an incident.
For example, the backend SOC may investigate and recommend or initiate containment. The MSP may own customer communication. The customer may retain authority over a business-critical action.
The important point is not that every party participates equally.
It is that the transition of responsibility is understood.
When one team’s work ends, the next responsible party should be clear.
Scope Also Means Knowing What Is Not Included
A well-defined service does not need to cover everything.
It does need to make exclusions understandable.
Activities such as full digital forensics, malware reverse engineering, long-term remediation, recovery, regulatory reporting, or on-site incident response may sit outside the standard MDR scope depending on the service model.
Being explicit about exclusions does not weaken the service.
It prevents adjacent security activities from being assumed to be part of MDR when they have not been operationally or commercially defined as such.
The MSP Perspective
For MSPs, the service boundary connects what is sold with what can actually be delivered.
Commercial teams need to understand the same scope, dependencies, and limitations as the teams responsible for operations.
Otherwise, small differences in language can create significant differences in expectation.
A clearly defined boundary provides a common reference for positioning, onboarding, service delivery, escalation, and customer communication.
The DIAMATIX Perspective
At DIAMATIX, we see service boundaries as part of the MDR operating model.
In a partner-led model, the MSP, DIAMATIX SOC, and customer may have different responsibilities, but those responsibilities need to function as one coordinated service.
Clear scope, defined response authority, known dependencies, and agreed escalation paths help make that possible.
With MDR 360° Powered by DIAMATIX SOC, MSP partners can extend their managed security offering with 24/7 SOC operations while retaining the customer relationship and defining the service model that fits their business.
Closing Perspective
The boundary of an MDR service should answer three practical questions:
What does the service cover?
What is the service authorised to do?
Where does responsibility move to someone else?
When these boundaries are defined before onboarding, the service becomes easier to position, operate, and evaluate.
When they remain implicit, the differences usually become visible at the least convenient moment: when an incident requires action.
Explore MDR as a Managed Service
This article is part of our MDR as a Managed Service series, exploring how MDR capabilities translate into operational delivery and customer value.
Explore the previous articles and practical resources in the MSP Insights & Resource Library
Explore MDR 360° for MSPs
Need additional operational capacity behind your managed security service?
MDR 360° Powered by DIAMATIX SOC provides 24/7 monitoring, investigation, threat hunting, response, escalation, and incident communication for MSP partners.
Explore MDR 360° Powered by DIAMATIX SOC →
