How to Evaluate an MDR Provider Before an Attack

The worst time to learn what “managed response” means is while an attacker is moving through your environment. One provider may isolate a compromised endpoint within minutes. Another may investigate the alert, call your team, and wait for written approval. Both can market the service as MDR, yet the operational outcome is very different.

That is why an MDR evaluation has to move beyond logos, dashboards, and threat-count slides. Buyers need to understand what the provider watches, which evidence its analysts can see, what they are allowed to do, how quickly they escalate, and where their responsibility stops. The service should be judged as an operating model, not simply as a security tool.

Start With the Outcome MDR Is Supposed to Produce

Managed detection and response combines security technology with human analysis to find, investigate, and respond to threats. EDR can generate endpoint telemetry and take endpoint actions. A SIEM can collect and correlate logs. A SOC is the function that monitors and investigates. MDR is the managed service that brings selected tools, analysts, processes, and response together.

The practical outcome is not “more alerts.” It is fewer unreviewed alerts, faster confirmation of real incidents, decisive containment when authorized, and a clear handoff into remediation and recovery. If a proposal cannot explain that flow in plain language, the buyer does not yet know what is being purchased.

Map the Coverage Before Comparing Providers

A 24/7 service can still have major blind spots. The provider can only analyze the systems and identities that are connected, licensed, logging correctly, and within contract scope. Begin with an asset and data-source map.

Endpoints: employee laptops, servers, virtual machines, and specialized devices.

Identity: Microsoft Entra ID or another identity provider, privileged accounts, and remote access.

Email and collaboration: Microsoft 365 or other platforms where phishing and account compromise appear.

Network and cloud: firewalls, cloud workloads, VPNs, DNS, and relevant applications.

Business-critical systems: line-of-business platforms, backup systems, and systems that cannot be isolated without operational consequences.

Ask the provider to show which sources are monitored on day one, which require additional licensing or integration work, and how it detects a sensor or log source that stops reporting. “We integrate with Microsoft” is not a coverage map.

Define Response Authority Before the Contract Is Signed

Response authority determines whether analysts can contain a threat or can only recommend an action. More authority can shorten exposure, but automatic action can interrupt legitimate operations. The right answer depends on the asset and the business impact.

Scenario	Provider may act immediately	Client approval or ownership
Known malware on a standard workstation	Isolate the endpoint if pre-authorized	Confirm user impact and reimage or restore
Suspicious administrator sign-in	Revoke sessions or disable account if the playbook permits	Validate identity and restore appropriate access
Activity on a production server	Collect evidence and escalate urgently	Approve containment when shutdown could affect operations
Ransomware indicators	Execute agreed containment steps	Invoke incident leadership, legal, insurer, recovery, and communications plans

Build these decisions into playbooks. Name the systems that may be isolated automatically, the actions that always require approval, the people who can grant approval, and the fallback when nobody answers. A 15-minute notification target has limited value if the call reaches a person who cannot authorize action.

Read the SLA as an Incident Timeline

An SLA should define more than availability. Ask when the clock starts, how severity is assigned, and whether the commitment covers acknowledgement, analyst investigation, customer notification, containment, or resolution. Those are different milestones.

How quickly is a high-severity alert reviewed by a human?

What evidence must exist before an event becomes an incident?

How quickly is the named customer contact notified?

Which response actions are included, and which are separately billed?

What happens when the primary contact does not respond?

Does the SLA change outside business hours or during widespread events?

Test the Service During Onboarding

Onboarding is not complete when agents are installed. It is complete when coverage is verified and both teams can execute the response workflow. Run a controlled escalation test: generate an approved test event, confirm that telemetry arrives, measure analyst handling, verify the contact tree, and document the result.

The test should also expose operational assumptions. Can the provider open a ticket in the client’s system? Can it reach the executive incident lead after hours? Does the help desk know that an isolated device is part of a security response? Are recovery credentials accessible to the people who need them?

Require Reports That Help You Govern the Service

Threat counts are easy to display and hard to interpret. Governance reporting should show whether coverage and response are improving.

Coverage percentage for in-scope endpoints, identities, and log sources

Data-source health and time since last telemetry

Alert volume by disposition, including false positives and confirmed incidents

Time to acknowledge, investigate, notify, and contain by severity

Actions taken under delegated authority

Repeat detections and unresolved root causes

Open recommendations, named owners, and due dates

Results of escalation tests and tabletop exercises

Know What the Customer Still Owns

MDR does not transfer every security responsibility. The customer still owns business-risk decisions, accurate asset information, user access approvals, application-specific context, remediation funding, legal and regulatory decisions, insurance notification, communications, and recovery priorities. The provider can support several of those activities, but the accountable business owner remains inside the organization.

This boundary matters most after containment. Isolating a device may stop suspicious activity. It does not rebuild the device, restore a business process, determine whether notice is legally required, or explain the event to customers. Buyers should identify who performs each downstream task before an incident.

A Practical MDR Provider Evaluation Checklist

Document the systems, identities, and log sources that must be covered.

Ask each provider to map its service to that scope and identify exclusions.

Review sample response playbooks and define authority by asset type.

Convert SLA language into an incident timeline with measurable milestones.

Inspect a sample incident report and monthly governance report.

Run an escalation and telemetry test during onboarding.

Confirm exit terms, data access, license ownership, and log-retention arrangements.

Assign internal owners for remediation, recovery, legal, insurance, and communications.

Where TruePoint Systems Fits

TruePoint Systems provides managed IT, cybersecurity, and SOC/MDR services. That combination can reduce the gap between the team that detects suspicious activity and the team that manages endpoints, identities, infrastructure, and user support. Buyers should still confirm the precise technologies, response permissions, escalation targets, and service levels that apply to their agreement.

The useful sales conversation is not “Do you monitor 24/7?” It is “Show us what happens from the first signal through containment, remediation, and recovery in our environment.”

Frequently Asked Questions

What is the difference between EDR and MDR?

EDR is endpoint security technology that records activity, detects suspicious behavior, and may support endpoint response. MDR is a managed service in which analysts use EDR and other data sources to investigate and respond. Buying EDR does not automatically provide continuous human review.

Can an MDR provider isolate a device without permission?

Only if the contract and approved playbooks give it that authority. Buyers should define the rule by asset type. Automatic isolation may be appropriate for standard workstations but require approval for production systems.

Does MDR replace an internal IT team or MSP?

Usually not. MDR focuses on detection, investigation, and agreed response. IT operations still have to patch systems, manage identities, restore services, support users, and remove root causes. An integrated provider may perform both roles, but the scope should be explicit.

Which MDR metrics matter most?

Coverage, data-source health, time to investigate, time to notify, time to contain, repeat incidents, and closure of recommendations are more useful than raw alert volume.

How often should the escalation process be tested?

Test it during onboarding, after material contact or system changes, and periodically thereafter. The organization should choose a cadence based on risk and document the result.

Review the Response Model Before You Need It

TruePoint Systems can help business and IT leaders review current monitoring coverage, response gaps, and ownership boundaries. The goal is a practical picture of what will happen during a real event and what needs to be fixed before then. Start the conversation at https://truepointsystems.com/contact/.

How to Evaluate a Managed Detection and Response Provider