Buying security tools is easier than sustaining the work around them. Someone still has to decide whether an alert matters, investigate related activity, reach the right business owner, and act within an agreed authority. When those responsibilities are unclear, another dashboard can add work without improving the response.
Managed detection and response, or MDR, is best evaluated as an operating service: people, investigation processes and technology working within a defined scope. The term alone does not establish coverage, response powers or service levels. Those details belong in the agreement.
The following seven signs are prompts for a service review, not a diagnosis that every business must outsource. An internal team, a co-managed arrangement or an external service may be appropriate. The question is which model can reliably perform the work your organization needs.
1. After-hours coverage depends on someone noticing an email
An alert arriving overnight is different from an analyst reviewing it overnight. Ask who monitors the queue, how an urgent case reaches a responder, and what happens if the first contact does not answer.
If the answer depends on informal goodwill, define the gap before requesting proposals. State the required hours, escalation path and business systems in scope. Distinguish acknowledgment, investigation and authorized response when comparing service commitments. A promise of continuous monitoring does not automatically include continuous hands-on containment.
2. Your team spends its time clearing queues
Recurring alerts may consume attention without producing a clear investigation or a useful tuning decision. Look at a sample of closed cases: can a reviewer understand what happened, why the case was closed and what follow-up was needed?
Track queue age and unresolved important cases rather than rewarding closure volume alone. An MDR evaluation should ask who tunes detections, who maintains context about your environment, and how recurring noise is corrected. Outsourcing an unchanged queue without a feedback process can preserve the underlying problem.
3. Evidence is split across tools and teams
Endpoint activity, identity events, email and cloud services may be reviewed separately. The issue is whether an investigator can assemble the evidence needed for a decision, not whether the organization owns every available product.
Microsoft describes Defender XDR as coordinating detection and investigation across several workloads. That capability is not the same as a staffed operating service. For an organization using Microsoft security, review applicable licensing, deployment, data availability and operational ownership before assuming coverage exists.
Ask a prospective provider to identify required integrations and known visibility gaps. Agree who notices when a sensor or connector stops providing data, and how that interruption is escalated.
4. Nobody can clearly authorize containment
A provider may recognize a threat yet lack permission to isolate a device, disable an account or make a cloud change. Conversely, broad automatic authority can be inappropriate for a system with significant operational dependencies.
NIST’s incident response guidance addresses responsibilities across internal and external participants. Use that principle to write a practical authority matrix: what the provider may do, what needs approval, who can grant it, and what happens when that person is unavailable.
Treat production systems and sensitive business roles deliberately. Manufacturing environments need coordination with operational owners before actions that could affect a process. A generic endpoint isolation playbook is not an adequate substitute.
5. Log collection exists, but its usefulness is uncertain
Logs only help an investigation if the right events are available to the people doing the work. The joint ASD ACSC, CISA and partner logging guidance recommends an agreed logging policy covering collection, monitoring and retention responsibilities.
Use an evaluation to establish which data sources support your priority detection cases. Document retention, access controls, investigation access and service-provider responsibilities. Avoid collecting sensitive data without a defined purpose simply because storage is available.
Ask for evidence that a missing log source is detected. A service report that lists connected products without showing their health leaves an important operational question unanswered.
6. The response plan has not been exercised with the people involved
A contact list and a written plan are useful starting points. They do not demonstrate that an internal team and its suppliers can coordinate a response. NIST SP 800-61 Rev. 3 supports exercises involving relevant third parties as part of improvement.
Use a clearly hypothetical scenario, such as a suspected account compromise outside normal hours. Walk through evidence collection, business escalation, containment approval and recovery ownership. Do not perform unapproved containment on live systems to prove a service works.
Record what the exercise reveals: an unreachable contact, a missing permission or unclear handoff to incident response support. Give each improvement an owner and a follow-up date.
7. Leadership sees activity reports but cannot judge service performance
Alert totals and tool inventories do not explain whether the operating model is improving. Ask for a case walkthrough that separates the first signal, analyst review, escalation, authorized action and handoff. Confirm how each time interval is measured and which delays depend on your own organization.
For example, a hypothetical review might find that analysts investigate promptly but wait for an outdated business contact to approve action. Buying faster triage alone would not fix that delay. Updating responsibilities and exercising the escalation path might be the more valuable first change.
Turn the signs into a purchasing decision
Before discussing a contract, write a one-page scope: critical services, required coverage hours, included technologies, internal owners and actions requiring approval. Use that scope when evaluating internal and managed security operations. Request a responsibility matrix and a redacted or demonstration case walkthrough, not another organization’s confidential incident data.
Compare providers on clear deliverables:
- What is monitored, what is excluded, and how coverage health is reported.
- Who investigates and tunes detections, and what an escalation contains.
- Which response actions are included, with what approvals and limitations.
- How evidence can be accessed or exported, and how handover works if the service ends.
Keep prevention and remediation ownership visible. MDR does not remove the need for patching, access management or prioritizing exposure. A monitored vulnerability still needs an accountable treatment decision.
Choose an operating model you can verify
The strongest reason to evaluate MDR is a specific operational gap your organization cannot sustainably close today. Define that gap, test the proposed handoffs and agree how performance will be reviewed. A credible service should make responsibilities and limitations easier to understand, while helping your team reach defensible investigation and response decisions.