There are dozens of providers who will tell you that they offer 24/7/365 managed detection and response (MDR).
If we define MDR as remotely delivered, human-led, machine-assisted, turnkey SOC functions aimed at active threat disruption and containment, then a good number of these providers fall out of the category. They are monitoring tools that forward alerts; without the analysis and incident response leadership the definition calls for.
If you are evaluating providers using the same three letters to describe fundamentally different offerings, a scoring matrix will not help you. You will compare price, because price is the only line that means the same thing on both proposals.
The organizations that find the right solution do not start by comparing vendors. They start by defining what they need the service to do in their environment, with their team, against the things they are trying to protect, in the context in which they operate.
What follows are our recommendations to evaluate MDR providers, drawn from interactions with business, IT and cybersecurity leaders and, more usefully, from what we see during real-life engagements with our clients.
Endpoint-centric MDR still dominates the market because it is easily understood (we’re all familiar with antivirus), it covers a good part of the perimeter, its deployment is fast and low friction, and it is relatively inexpensive. Install an agent, forward the telemetry, monitor the console. For a professional services firm where every asset is a managed laptop and everything else lives in the cloud, that is a defensible answer.
It is a much weaker one for a manufacturer running three plants, or for an organization with legacy servers, industrial controllers, building systems, IOT devices, cameras and printers on the same network as the workstations. Those devices cannot host an agent and are also where an attacker can establish a foothold to move laterally, precisely because nothing is watching them.
Ask the MDR providers you are considering what percentage of your environment they can see, and what their coverage is for the part that cannot run an agent. A provider whose entire detection capability is agent-based will have blind spots the moment an attacker pivots to unmanaged infrastructure or to identity. That may be an acceptable trade, but it should be one you get to make.
This is the single most consequential difference between services that share the MDR label, and it is almost never obvious from sales and marketing materials.
Some providers detect a security event, triage it and send you an alert. Some investigate it and send you a recommendation. In both cases your team executes. Others take containment action directly in your environment (isolating an endpoint, terminating a process, disabling a compromised account, revoking sessions). The distinction is contractual as much as technical. Active containment generally requires a signed authorization defining which actions the provider may take without asking permission first, and in what scope.
At two in the afternoon on a Wednesday, the difference may be a matter of preference, but at two in the morning on a long weekend, it is the entire value of the service. A recommendation sitting in an inbox is not a response.
Ask which actions are pre-authorized, what is the approval path for anything outside that list, and what happens when they cannot reach anyone on your side.
Response time commitments are the most compared and least understood part of an MDR proposal. Before you can compare two numbers, you need to know what each one is counting.
Every MDR service moves through the same chain of events during an incident:
Providers quote timings against different points on that chain, using terms that sound interchangeable and are not.
Mean Time to Detect (MTTD) usually measures step one to step two. It is a measure of the tooling, not the service. Aggressive figures, anything measured in seconds, are common and almost always describe an automated detection firing, with no human involvement yet.
Time to acknowledge or time to notify measures when a person on your side first hears from the provider. This is closer to what most buyers picture when they read "response time."
Mean time to respond or mean time to resolve (MTTR) is the most ambiguous term in the category, because the same acronym covers both. Depending on the provider, it may refer to the moment an analyst opens the investigation, the moment the threat is contained, or the moment the incident ticket closes, and those three points can sit an hour apart or a week apart in the same incident.
Time to contain measures when the threat stopped spreading. It is the number that correlates most closely with damage avoided, and it is the one least often committed to in writing.
When a provider promises a fifteen-minute response and another promises sixty minutes, you may be comparing an automated alert against a human phone call. Ask each provider, in writing:
A number without a clear definition is not a commitment.
There are two questions here, and both matter: who does the work, and whose rules govern it.
Ask who employs the analysts monitoring your environment. Some providers staff their own operations around the clock. Others cover business hours in-house and hand overnight, weekend and holiday coverage to third-party or offshore tiers. Handoff is where continuity of context tends to break down, because the analyst who takes your call at three in the morning may have little to no history with your environment and no relationship with your team, not to mention potential language barriers.
Also ask where your security telemetry is stored, which legal system governs it, and which regulator the provider answers to. Sovereignty is not only a compliance argument. Where your telemetry is stored and which law governs it is increasingly a deliberate choice rather than an afterthought. Canada's privacy landscape is a genuine patchwork, and the complexity it brings is a reason to want a partner who lives inside the same system you do, rather than one who will need it explained to them during a breach.
Beyond the statutes, there is a simpler reality. Many buyers are more comfortable entrusting their most sensitive operational data to an organization based in their own jurisdiction, subject to the same courts and the same oversight. That is a legitimate evaluation criterion, and it should be weighed openly rather than treated as a soft preference.
Ask a dozen providers to describe their detection capability and you will get a dozen similar answers: behavioural analytics, threat intelligence, correlation across sources, human validation before escalation. The differences are real, but they are marginal, and they are particularly difficult to evaluate and verify from the outside.
Response is where providers separate, and it is where most buyers spend the least time.
Containment stops the bleeding, but it does not tell you how threat actors got in, how long they were there, what they reached, whether they still have a way back in, or whether it is safe to bring systems back online. Those questions are answered by incident response and answering them requires forensic work by people who have worked a real intrusion before.
A significant number of providers do not do that work. They will isolate the affected hosts, write up what they observed, potentially make recommendations, and hand off to a third-party firm who shows up with no knowledge of your environment, no existing access, no relationship with your IT staff, and a statement of work to negotiate while an intruder may still be resident on your network. That delay costs more than the calendar days it consumes, because an intruder who is still resident uses the time to re-establish access and persistence while the evidence you would need to reconstruct the incident degrades on its own schedule.
This is the argument for treating response capability as a selection criterion. Ask:
There is also a second-order effect worth raising: Teams that respond to real intrusions build better detections, because their detection engineering is informed by what attackers did in the environments they cleaned up rather than by what a vendor feed says attackers do. Incident response experience is a reasonable proxy for detection quality, not just an add-on service.
A provider that has never led an incident is not necessarily a bad option, but it is selling managed detection rather than MDR, and it should be evaluated and priced on that basis.
Most organizations do not start an MDR evaluation from a blank page. They start with a set of tools already in place, and providers tend to approach that reality from one of two positions.
Platform-native services monitor their own product and can deliver tighter correlation and faster automated action because every component speaks the same language, which can be a real advantage if you are genuinely consolidated. Their recommendation will generally be to replace your current systems with their own.
Vendor-agnostic services work with whatever you are running, which is what most organizations need after years of acquisitions, departmental purchases and partial cloud migrations. A technology-agnostic SOC can begin with the tools already deployed, prove out where coverage is adequate and where it is not, and then recommend targeted replacement as licences come up for renewal, as the environment changes, or as a new contractual or regulatory obligation makes a current tool untenable. That sequencing matters commercially, because it lets you spread change across budget cycles instead of funding a full replacement in year one, and it matters technically, because the recommendation to replace something is grounded in months of observed behaviour in your environment rather than in a scoping call.
A provider worth hiring should be willing to inventory what you have, use what works, tell you what does not, and recommend and/or charge you for the gap rather than for the whole surface.
We recently took over from a global leader in endpoint security at a client who was, by any technical measure, well protected. The product was not the problem, and that vendor remains one of the strongest in the market. What changed was fit, in three respects that had nothing to do with the quality of the tooling. Coverage extended to parts of the environment where an agent could not be installed, which is where a meaningful share of their operational risk sat. Communication moved from a ticket queue to a named advisor who understood how the business ran and could tell them which alerts mattered on a production morning. And rather than receiving a continuous stream of validated alerts with no bigger picture behind them, they got a sequenced plan for maturing their posture.
What they replaced was not a bad tool, but a service scoped against a different challenge than the one in front of them.
The worst outcome in an MDR evaluation is not choosing the wrong provider. It is signing a contract and assuming you are covered when you are not.
Lab evaluations and analyst placement tell you what a provider can do under ideal conditions with an expert operator. They tell you very little about what it will do in your environment, with your team, at three in the morning. The right answer is not the vendor with the best score or the most polished pitch. It is the one that fits what you have and what you are trying to protect.
Contact our team to discuss your cybersecurity challenge and discover how we can support you.
