MDR in 2026: why 24/7 detection costs what it costs, and when to buy it instead of building it.

Managed Detection and Response is a service that puts a provider's 24/7 security operations team behind your detection tooling, to find threats, investigate them, and respond, increasingly by containing the threat directly rather than only telling you about it. It exists because the alternative, a staffed in-house security operations centre running around the clock, is one of the most expensive and hardest-to-staff capabilities in IT: covering every hour of every day with escalation redundancy takes on the order of nine to fourteen people once shift mathematics, holidays and turnover are accounted for, and the analysts to fill those seats are in chronic global shortage. MDR resolves that by spreading scarce expertise across many clients, so an organisation gets the outcome of a SOC, a shrinking mean time to detect and respond, proactive threat hunting, expert response, without building one. The distinctions that matter in 2026 are sharp: MDR is a service, not a tool like EDR or XDR; it does more than an alert-forwarding MSSP, because genuine MDR contains threats rather than only flagging them; and it sits directly under the compliance regimes, because every DORA and NIS2 reporting clock starts at a detection that only continuous monitoring produces. This note covers what MDR is and is not, the staffing geometry that drives the cost, the build-versus-buy decision with a calculator to run your own numbers, and why for European organisations the jurisdiction of the SOC watching your telemetry is now part of the question.

A traditional Managed Security Service Provider monitors your environment and alerts you: it tells you something is wrong and hands the problem back to your team to investigate and fix. That was valuable when the alternative was no monitoring at all, and it leaves the hardest part, the response, with the people least equipped to do it at speed. MDR closes that gap by investigating and responding, and in 2026 the defining capability is active containment, the so-called 'Big R' of response: an MDR provider can isolate a compromised host or disable an account directly on your infrastructure, not merely recommend that you do. The practical test cuts through the marketing: when a threat fires at three in the morning, an MSSP sends a ticket, while an MDR provider contains the threat first and sends the ticket after.

SOC-as-a-Service sits adjacent, and the line is about where the action happens and how broad the coverage is. SOCaaS teams more often advise while your staff performs the containment, and the model tends to scale with the breadth of log ingestion, the length of retention, and the depth of compliance reporting, which makes it more comprehensive and usually more costly. MDR is frequently the lower-cost entry point, focused tightly on detecting and responding to threats, while SOCaaS covers more ground at a higher price. None of the three is universally right: the choice turns on how much of your environment needs watching, how much compliance reporting you must produce, and crucially whether you need a provider who will press the containment button or one who will tell you to. Getting that last question answered honestly, before signing, prevents the common disappointment of buying alerting and expecting response.

Mean Time To Detect is the interval from a threat entering your environment to your noticing it. Mean Time To Respond is the interval from that detection to containing the threat. The sum is the exposure window, the period an attacker operates inside your environment undisturbed, exfiltrating data, moving laterally, establishing persistence, and the entire purpose of detection and response is to compress that window toward zero. An unwatched tool measures dwell time in days or weeks, because nobody is acting on what it sees; a mature, staffed operation measures response in minutes, with some AI-augmented services quoting median times to resolution in the low double digits of minutes. The gap between those two states is the difference between an incident contained before it matters and a breach discovered after the damage is done.

MTTD and MTTR are also the language of proof, which matters more in 2026 than it used to. A service that reports a documented, improving MTTD and MTTR gives you concrete evidence your security works, evidence that satisfies boards, insurers and, increasingly, regulators. This is where detection metrics meet compliance, because the post-incident reports, audit trails and timing data a good MDR produces are exactly what a regulated entity must show to demonstrate it can detect, classify and report an incident within the windows the law sets. A number you can show is worth more than a control you can only assert, and MTTD with MTTR is the number, which is why a serious evaluation of any detection operation starts by asking what its measured times are and how they are trending, not what tools it runs.

The first shift is toward identity. As attackers increasingly work with stolen-but-valid credentials, hijacked sessions and abused tokens, the entry point is often the identity layer rather than the endpoint, and an intrusion using legitimate credentials may trip no endpoint alarm at all. Modern MDR answers this with Identity Threat Detection and Response, ITDR, monitoring the directory, single sign-on and authentication systems for the signs of a compromised identity, so that the layer attackers now favour is watched alongside endpoints and network. The second shift is the normalisation of proactive threat hunting: rather than waiting for alerts, good services run hypothesis-driven searches through logs and telemetry from an assume-breach posture, on the principle that the most dangerous intrusions are precisely the ones that did not fire an alarm. A service that only reacts is doing half the work; hunting is how the quiet, evaded threats get caught.

The third shift is the AI-SOC, and it is changing MDR's economics rather than replacing its people. AI-driven triage now filters the alert flood so analysts spend their hours on the small fraction of events that are genuinely high-risk, cutting false positives and pulling down both MTTD and MTTR, with some services automating initial triage and even containment under human oversight. This is enough of a change to the labour model, the escalation path and the pricing that buyers are advised to evaluate AI-native services as a separate category from legacy MDR rather than assuming they are the same product. The durable principle through all of it is human-in-the-loop for consequential decisions: automation absorbs the routine and the volume, while the calls that carry real risk, isolating a production server, rolling back data, disabling a key account, remain decisions a person approves. The direction is more automation under more, not less, accountable human control, which is the right direction, because the cost of an automated containment that gets it wrong is borne by your business, not the tool.

Start with response, because that is where the labels blur most. Ask precisely what the provider does when something fires: do they contain the threat directly on your infrastructure, the active 'Big R' that defines genuine MDR in 2026, or do they alert you and wait for your team to act? Ask for measured outcomes, not promises: what is their median MTTD and MTTR, validated how, and against what kind of incident, because a documented, independently checked response time is evidence and a marketing figure is not. Ask about coverage breadth honestly: do they correlate across endpoint, network, cloud and identity, or are they endpoint-centric with the other layers as blind spots, given that identity is where so many 2026 intrusions begin. And ask what threat hunting actually means in their service, whether analysts run hypothesis-driven searches proactively or the word is decoration on a purely reactive operation.

Then the questions that the comparison sites tend to skip, which decide whether the service works in practice. What is the escalation path at 3am, and who, by role, is reachable, because a provider whose night coverage is junior analysts escalating slowly to senior staff has a real gap precisely when incidents are most dangerous. How does the service integrate with your existing tools, and does its model lock you into a single ecosystem or accommodate the stack you already run, since integration that consumes weeks is integration you are paying for. What does onboarding require of you, especially the containment-authority decisions about which systems may be isolated automatically and which need a call first. And, for a European organisation, where do the SOC, the analysts and the telemetry processing physically and legally sit, because that answer determines whether your security data stays under a jurisdiction you can name. A provider that answers these crisply is selling an operation; one that retreats to feature lists and threat-actor statistics is selling a brochure, and the difference shows up at the first real incident, not in the sales cycle.

The honest framing of the build-versus-buy decision is not which detection operation is cheaper to run, but which one actually catches the intrusion before it becomes a breach, because the gap between a contained incident and a full breach is measured in figures that make the entire SOC budget look like a rounding error. A breach that runs undetected for weeks, because the in-house SOC was understaffed on the night it began, can cost orders of magnitude more than the annual difference between building and buying, in incident response, regulatory penalties, breach notification, lost business and reputational damage. For a board, the clearest financial proxy for the risk of an understaffed operation is exactly that gap between the cost of a breach caught early and one caught late, and it is the number that should anchor the decision, not the line-item comparison of staffing models.

This reframes what the calculator above is really telling you. The running-cost comparison matters, and for most organisations under significant scale it points clearly toward buying or hybridising rather than building. But the decisive variable is which option produces detection that genuinely works at 3am on a public holiday, because that is when the difference between an alert acted on and an alert missed is realised, and it is the missed alert, not the staffing model, that carries the catastrophic cost. An MDR service that reliably contains the incident is cheaper than a cheaper in-house SOC that misses it, by the full size of the breach avoided, which is why the cost-conscious decision and the security-conscious decision usually converge on the same answer. The right question to carry out of the calculator is not only which column is smaller, but which option you would trust to be awake and effective at the exact moment an attacker is counting on nobody being there.

Good detection rests on a stack you can see into, and the open-source foundation many serious operations use, a Wazuh-based platform of the kind covered in our SIEM field note, gives an operator full visibility into the rules, the telemetry and the response without a black-box vendor in the middle. On a self-hosted or hybrid model the same discipline this note describes applies directly: the shift geometry is real headcount you schedule, the MTTD and MTTR are numbers you measure in your own logs, the containment playbooks are actions you have agreed and can execute, and the threat hunting is hypothesis work your analysts run against telemetry you control. The hybrid pattern, an in-house team owning oversight and the deepest institutional knowledge while a managed layer carries the round-the-clock load, is the mature shape most organisations converge on, and it is one an operator who builds the underlying platform can deliver rather than only broker.

For European organisations there is a dimension the global MDR comparisons tend to omit, and it is decisive for regulated and public-sector buyers: where the SOC sits and which law governs it. Security telemetry is sensitive operational and often personal data, so an MDR service is also a data-processing arrangement, and the same sovereignty question that applies to any cloud applies to the SOC watching your environment, who can be compelled to hand over the telemetry, and under whose jurisdiction the analysts and the data sit. An MDR operation run wholly under EU jurisdiction keeps that telemetry beyond foreign compelled-access reach; one routed through or operated from another jurisdiction does not, whatever its detection quality. That is the lens we bring, because we are a European operator that builds and runs detection under EU jurisdiction rather than reselling a platform from elsewhere, so the sovereignty of your telemetry is a property of how we are built, not an add-on. Where it helps to have round-the-clock detection and response, built on infrastructure you can see into, run by people under EU jurisdiction, and tied to the board accountability the regulations now demand, that is the work our managed security practice exists to do, with the strategic ownership running through a virtual CISO engagement and the prevention side through vulnerability management.