MDR Is Not a Tool Purchase

Seven decisions that help turn managed detection into coordinated action.

The most important question when buying Managed Detection and Response is not only what your organisation needs to detect, but what the provider and your team will do when a relevant threat is identified.

The security platform matters. Its capabilities, configuration and integrations influence what can be detected and which actions are possible. But the platform is only one part of the service.

Effective MDR connects technology, analysts, business context and agreed responsibilities. Together, these form an operating model: a practical arrangement for investigating signals, making decisions and taking action.

That model needs to reflect your organisation. Which systems keep operations running? Who operates them? Which actions can the provider take directly, and when must other people be involved?

Answering these questions together gives the customer and provider a stronger foundation for reducing the impact of an incident.

Seven decisions that shape the service

1. Scope: agree what is covered

Define which assets, identities, environments and locations are included, and how each is monitored. Give particular attention to operational technology, supplier-managed systems and environments added through acquisitions.

Being listed in scope does not by itself establish effective detection coverage. Both parties need to understand what visibility is available, where limitations remain and how changes will be brought into the service.

2. Telemetry: keep the signals flowing

Agree which data sources the service needs, how they are connected and who checks that they continue to work.

A source may stop reporting because a certificate expires, a token changes or an update breaks an integration. Monitoring the health of those connections helps distinguish missing data from an environment with little activity.

The provider should make agreed telemetry gaps visible. The customer and relevant system operators should know who is responsible for resolving them.

3. Detection coverage: connect signals to relevant threats

Identify the attack scenarios that matter to the organisation and assess whether the available signals can reveal them.

Standard detection content provides a starting point. Its relevance depends on the systems, configurations and activities in your environment. Agree which scenarios are covered, which need additional data or tailored detection, and how coverage will be validated.

4. Investigation context: help analysts understand the business

An administrative action at two in the morning may be planned maintenance or an attacker using a compromised account.

Asset ownership, system criticality, normal operating patterns and planned changes help analysts interpret what they see. Agree how this context is shared and kept current, so investigations can move forward with fewer avoidable delays.

5. Decision rights: define authority before it is needed

Specify which actions the provider may take without further approval, under what conditions and on which systems.

Isolating an endpoint, disabling an account and interrupting a business-critical server have different consequences. Pre-agreed authority should reflect those differences, including operational and safety requirements.

Where customer approval is required, name the decision-maker, their deputy and the arrangement outside working hours.

6. Response and escalation: build and test the chain

Define what the provider performs directly, what the customer decides and when specialist incident response or other suppliers become involved.

Then exercise that arrangement. Test whether the right people can be reached, whether they have the necessary authority and whether the agreed actions can actually be performed.

An exercise can reveal a missing contact, an access limitation or a dependency while there is still time to address it calmly.

7. Improvement and reporting: use findings to make decisions

Agree how detection, coverage and response procedures will evolve as the environment and threat landscape change.

Reporting should help both parties decide what to improve. That includes recurring telemetry gaps, investigation findings, exercise results and actions with named owners.

The purpose is to make the service more effective over time and give the customer a clear view of progress and remaining limitations.

Monitoring hours are not response hours

Twenty-four-seven monitoring tells you when someone is watching. The response agreement should explain what happens next.

Detection, investigation and timely escalation all contribute to handling an incident. Their value increases when they connect to a clear route for taking action.

Consider a fictional transport operator. Its MDR provider identifies suspicious activity on a server used by a terminal application. The provider can investigate the alert, but another IT supplier operates the server. Containment may interrupt terminal operations.

An effective response depends on several people knowing their roles: who assesses the threat, who explains the operational consequences, who authorises action and who performs it.

This is where advance preparation pays off. Defined scenarios, agreed procedures and reachable decision-makers help the parties act with speed and control. In operational environments, the appropriate response may require coordination with people responsible for availability and safety.

The useful question is therefore: if a threat is confirmed outside working hours, is there a clear, workable path from investigation to action?

Keep coverage aligned with the real environment

Onboarding establishes the initial view of the organisation. Maintaining that view is part of operating the service.

New servers appear. Cloud workloads are created. Systems change owners or roles. Agents may be removed during troubleshooting, and data connections may fail.

Some changes can be discovered automatically through integrations and monitoring. Others require information from the customer or another supplier. The operating model should bring those mechanisms together.

For the transport operator, that could mean checking the provider’s monitored assets against infrastructure inventories, cloud accounts and supplier records. Differences become actions: connect a new system, restore a data source, update its criticality or document an agreed exclusion.

The customer contributes knowledge of the business and its systems. The provider contributes visibility into the service and the data it receives. Together, they can maintain a clearer picture of what is covered.

Useful measures include:

• The proportion of agreed in-scope assets with the required telemetry.
• The time between identifying a new in-scope asset and establishing coverage.
• The number of data sources silent beyond an agreed threshold.

Those thresholds should reflect the source’s expected activity and importance. Coverage measures should also be considered alongside response measures and exercise results.

What good MDR looks like in practice

A well-run MDR service makes its capabilities, responsibilities and limitations understandable.

The provider knows which systems matter most and has access to the context needed to investigate relevant threats. Both parties can see where coverage is incomplete and who is addressing it.

Response authority is documented for defined situations. When the provider needs a customer decision or another supplier’s involvement, the escalation route is clear and has been tested.

Detection is reviewed as systems and threats change. Reports lead to prioritised improvements, and lessons from investigations and exercises feed back into the service.

This does not require every organisation to buy the broadest possible service. It requires a deliberate match between business risk, service scope, provider capabilities and the customer’s own resources.

For some organisations, the immediate priority will be stronger operational support around existing security tools. Others will need additional data sources, tailored detection, threat hunting or closer integration with incident response.

The important thing is that these choices are explicit and reviewed together.

Six questions to answer together

Whether you are selecting an MDR service or reviewing an existing one, answer these questions in writing:

1. Which outcomes should the service support, and how will we assess progress?
   Connect the service to relevant business risks and agree measures within each party’s control.
2. Which threats and systems must it cover, and where are the visibility gaps?
   Distinguish agreed scope from the coverage currently operating.
3. What may the provider do directly, and where does that authority stop?
   Document the conditions, exceptions and operational considerations.
4. Who is involved when the provider cannot act alone?
   Include customer decision-makers, deputies, system operators and specialist responders.
5. How will coverage and detection be maintained as the environment changes?
   Agree ownership, review intervals and how changes enter the service.
6. How will we test the response model and follow through on improvements?
   Exercise the chain from detection and investigation through to decisions and agreed action.

From detection to coordinated action

MDR creates value through a working connection between signals, understanding, decisions and response.

Building that connection is a shared task. The provider brings operational security expertise and the capabilities agreed in the service. The customer brings business priorities, organisational authority and knowledge of its environment. Other suppliers may be essential to carrying out the response.

A clear operating model helps those contributions work together when time matters.

For organisations already using MDR, a practical starting point is to review one critical system together: what the provider can see, which threats it can detect and what would happen if a threat were confirmed tonight.

The transport operator in this article is a fictional example used to illustrate operational considerations. It does not describe a real organisation.

Author