Detection strategy: why an MDR choice always comes too late without a strategy

A detection strategy is a documented set of decisions that describes which attack scenarios your organisation wants to see, which crown jewels are in scope, which telemetry is needed to cover those scenarios, which detection rules turn that telemetry into an alert, and who does what within what timeframe for each type of alert. It is not a tool choice, not a vendor shortlist, not a maturity score. It is a set of explicit decisions you make before an MDR vendor enters the picture, so that during the selection you know what you are procuring and why. Reverse that order and you choose a vendor on the basis of what it shows in a demo, then hope afterwards that the coverage matches what the organisation needs.

This piece explains why an MDR contract without a prior detection strategy rarely delivers what the CISO expected of it, what a workable strategy looks like, and which components you need to have set out as a minimum before you open the conversation with the market. It is intended for the CISO who has to explain internally why the selection cannot begin yet, or who has just established that the current contract delivers telemetry without the context in which that telemetry means anything.

Why does an MDR selection fail without a strategy?

The answer lies in what an MDR vendor actually sells. An MDR service combines telemetry (logs, endpoint events, network traffic, identity events), a platform that correlates that telemetry, a set of detection rules that run on that platform, and a team that responds to alerts. What the vendor shows in a demo is the capacity of that stack against generic attack scenarios. What it cannot show, because it does not yet know the organisation, is how well that stack covers your crown jewels, understands your business processes, and sets your response chain in motion. That difference only emerges during the transition phase, and by then the contract has already been signed.

Without a strategy, then, you choose on the basis of something that does not predict what you will get. You weigh the clarity of the demo, the chemistry of the account team and the rate per endpoint, while the real question is which attack steps on which systems you want to detect and which telemetry gives the most signal there. That question is independent of the vendor. If you have not answered it before the selection begins, you answer it implicitly through the choice, and that implicit answer usually diverges from what the organisation needed.

The second reason lies in the structure of the market. A large part of the MDR offering is built around a single detection platform and a single set of generic use cases that run on that platform. That is understandable from the vendor's model; it makes the service scalable. For the buyer it means that the coverage of their specific risk scenarios becomes dependent on incidental overlap between the vendor defaults and their own environment. A sceptical CISO tests that overlap before signing. A CISO without a strategy has no benchmark and falls back on the persuasive power of the presentation.

A third reason is operational. An MDR contract without use-case context delivers alerts whose relevance you cannot establish internally. The team on the client side receives notifications that lack context, because the vendor does not know which server is an ERP production host and which is a test environment. The response becomes slow, trust erodes, and within a year the question arises whether MDR is the right model at all. The problem rarely lies in the MDR model. It lies in the absence of the strategy document that should have given the vendor the context.

So what is the difference between telemetry and a detection strategy?

Telemetry is roughly what your systems churn out in logs and events. A detection strategy is the narrative that determines which telemetry you deliberately collect and what you are going to do with it. That narrative begins with threat models and crown jewels, and ends with an operationalised response chain. The telemetry follows from that narrative, not the other way around.

In practice it goes the other way round: an organisation has a SIEM, an EDR solution, a few identity logs, and builds a detection rule set on top of them because those are the sources that happened to be available. That is a telemetry strategy disguised as a detection strategy. It lacks a central element: the scenarios you want to see are never named. You detect what is detectable with what you have, and not what needs to be detectable because it matters. MITRE ATT&CK, the MITRE-maintained framework that systematically describes attack techniques, is the most widely used instrument for this: it lets you name, for each crown jewel, which techniques a serious attacker would deploy and which detection coverage you need for that as a minimum. A detection strategy without a mapping to ATT&CK is usually a telemetry inventory with a different label.

The reverse also holds. A strategy without telemetry reality is a wish list. Anyone who names scenarios without testing which logs and events are actually available within which retention window, and what data quality those sources have, writes a document that stalls in execution. The order, then, is: scenarios first, telemetry mapping afterwards, not the other way around. But the document is only complete when both sides have been filled in.

What goes into a workable detection strategy?

A detection strategy does not need to run to a hundred pages. It has to be explicit on a limited number of points, and those points are traceable for both your own team and a future MDR vendor. The minimum components, in order:

Threat models per business domain. Which types of attacker are realistic for your sector and scale, what motives do they have, and what behaviour do they apply. Not "ransomware in general", but concrete: financially motivated criminal groups that buy initial access through stolen credentials, supply-chain actors that enter via managed IT, insider risks around privileged access. The Cyber Threat Landscape report from ENISA and the annual publications of the Netherlands' National Cyber Security Centre offer a structured basis here that you bring back to your own sector.

Crown-jewels inventory with associated impact. Which systems, datasets and processes must under no circumstances go down or leak, and what is the expected impact in time and money if that does happen. This is not a complete IT inventory; this is the top of the risk pyramid. Without this layer, detection becomes an across-the-board ambition and, in execution, falls back on the sources that were easiest to tap.

Use cases per crown jewel. For each crown jewel: which attack steps you are trying to detect, with which detection logic, and in which phase of the attack chain. Here MITRE ATT&CK comes into play as a common language. A use case is "suspicious lateral movement from an ERP host" or "credential abuse on a financial reporting system", not "we monitor the logs of X". A use case is a hypothesis about what an attacker would do, with a measurable detection condition.

Telemetry mapping per use case. Which sources provide the signal for this use case, with which retention, and what data quality. This is where half of all strategies fall down. A use case that depends on a log source with unreliable retention or limited fields works in the demo and collapses in production. The NIST Cybersecurity Framework version 2.0, the structure maintained by the United States' National Institute of Standards and Technology, offers under its Detect function the discipline to make the telemetry mapping explicit per scenario instead of leaning on a tool default.

Response RACI per scenario type. Who sees which alert first, who escalates, who decides on containment, who informs the board, who speaks on behalf of the organisation. For an MDR service, this explicitly includes: where the vendor's responsibility ends and where that of your own team begins. An MDR contract without this layer is a promise without a working chain.

A strategy that sets out these five components is ready for a vendor conversation but for one point. That one remaining point is the testing itself, and you carry that out before you sign, not after.

How do you test an MDR vendor against this strategy?

The testing is not about the demo. It is about the degree to which the vendor can cover each of the five components, on which telemetry it builds that coverage, and which gaps it honestly names. A vendor that says it covers everything without having read the strategy gives the wrong answer to the first question. A vendor that indicates, per use case, which telemetry it requires, which detection logic it uses, and on which points it depends on client-side work, delivers a testable proposal.

Three concrete questions on which the testing rests. One, can you lay the detection strategy against your default content and give a coverage percentage per use case, with a justification at MITRE ATT&CK technique level. Two, which parts of the response chain does the vendor run itself, which parts are the client's responsibility, and what does the handover look like at the moment an alert has to lead to containment. Three, how is the detection coverage maintained over time, because the threat landscape shifts and without periodic recalibration the strategy ages within a year.

If you cannot ask these three questions with a document in hand, you are buying on trust rather than on fit. Trust has a place in the working relationship, but not as the basis for the selection itself.

What this means for the choice you make

For the CISO preparing the MDR process internally: the usable conclusion is that the strategy is the steering material for the selection, not a nice-to-have that will come along later. An MDR choice without a prior detection strategy delivers telemetry without use-case context, and that situation rarely reverses of its own accord within a running contract. The repair costs more than the strategy would have cost up front.

For the board or the CFO, the message is more businesslike. An MDR contract is generally a multi-year expenditure at a fixed rate per protected unit. A contract that does not rest on an in-house detection strategy is judged on the rate, while the real question is which risk is covered per euro. That question can only be answered once the strategy is in place. Until then, the choice is an expenditure without traceable risk reduction, and that is precisely the kind of decision the regulator queries and for which the board must be able to account.

For your own team, the message is operational. The strategy is not the work of an external party that writes it up for you. It arises from the conversation between security, IT, business owners and risk management about what needs to be protected, against whom, and with what priority. An external party can structure it, test it and help assemble it, but it must be owned by the organisation itself. Otherwise it sits in a vendor portal and not in the heads of the people who have to execute it.

The logical next step, then, is not an RFP for MDR. It is a short, honest assessment of what strategy is in place and what is missing. Only when those five components are explicit does the conversation with the market open from a position of advantage rather than a position of disadvantage. Reverse that order and you buy a service and keep the original problem.