What to Expect From a Managed EDR Service

A managed EDR service is not defined by a dashboard or a generic promise of monitoring. It is defined by what the provider watches, how it investigates, when it escalates, and what it may do during an incident.

The service usually combines endpoint technology with analyst work. Exact scope varies. Some providers only triage endpoint alerts and recommend actions. Others maintain policies, investigate related identity or email signals, contain devices under pre-approval, and support incident response. The proposal and contract should separate included work from optional or customer-owned duties.

What the service commonly includes

A well-defined managed EDR service may include agent-health monitoring, endpoint alert triage, investigation using available telemetry, searches for related activity, severity classification, notification, containment recommendations, approved response actions, regular reporting, and tuning. Each item should state the covered devices, data sources, hours, service target, and handoff.

It may not include agent deployment, operating-system patching, identity administration, mailbox remediation, vulnerability management, backup recovery, forensic imaging, legal or privacy advice, communications, or full incident-response retainers. If any of those are offered, confirm whether they are included, separately priced, or delivered by another party.

Confirm these items before signing

Endpoint types, operating systems, and data sources in scope
How sensor health and coverage gaps are reported
Monitoring hours and the handoff between provider and customer
Severity criteria, escalation contacts, and communication channels
Response actions the provider may take without waiting for approval
Actions that remain the customer’s responsibility
Reporting cadence, evidence retention, and remediation follow-up
Any exclusions, minimums, or third-party dependencies

The response-authority matrix matters as much as the technology. A provider may be able to isolate a device or recommend action, but the business must decide in advance which actions are authorized and who owns recovery.

What onboarding should produce

Onboarding should leave more than installed sensors. Expect an agreed asset scope, coverage baseline, supported operating systems, exclusions, customer and provider contacts, severity definitions, notification channels, response-authority matrix, integration list, data-handling record, and acceptance test.

The provider should know which endpoints are ordinary workstations, executive devices, servers, and critical systems. It needs business context for approved administration tools, maintenance windows, high-impact applications, remote-access products, and activities likely to create detections. The customer should know how to report a concern, update contacts, request a search, approve an action, and escalate service issues.

What daily operation should look like

The provider monitors covered telemetry during the contracted hours, validates detections, gathers context, and records a disposition. Benign events may be closed with evidence. Suspicious events may be escalated for customer context. Confirmed malicious activity may trigger a pre-authorized containment action or an urgent recommendation.

The customer maintains devices, fixes failed agents where assigned, responds to provider questions, carries out identity or application changes, and tracks remediation. Both sides review recurring noise, missing telemetry, unresolved risks, and changes to the environment.

A sample escalation path

Suppose the provider detects a scripting interpreter launched by an office document, followed by an unfamiliar network connection and a scheduled task. The analyst validates the process chain, user, device, destination, and related activity. Under the agreed severity rules, the provider creates a case and contacts the primary security or IT owner.

If standard workstations are pre-authorized for containment, the provider isolates the laptop and records the action. If isolation requires approval, the notice should state the evidence, recommended action, business risk, and response deadline. The customer confirms the user's activity, starts the identity and email review, and decides how the device will be rebuilt or returned to service.

The case record should show detection time, triage time, severity, evidence, analyst conclusion, contact attempts, customer acknowledgement, actions, approvals, remaining work, and closure basis. Test this path before a real event, including the secondary contact when the primary does not respond.

Containment authority needs boundaries

Use a matrix by device class and action. A provider might isolate standard workstations on high-confidence malicious activity, require approval for executive devices, and only recommend actions on servers. Define whether it can stop processes, quarantine files, block indicators, or request account action through an integration.

For every permitted action, state the trigger, evidence threshold, notification, audit record, exception, and reversal procedure. Confirm how emergency changes are handled and reviewed. The customer remains responsible for business-continuity and recovery decisions unless the agreement explicitly assigns work elsewhere.

Reporting should support decisions

A useful monthly or quarterly report should include in-scope and healthy endpoints, stale or missing sensors, alert and incident counts by severity and disposition, response timings tied to contractual definitions, containment actions, recurring detections, exclusions, unresolved remediation, service issues, and recommended changes.

Counts without context can mislead. Fewer alerts may mean better tuning, less activity, broken sensors, or broader suppression. Ask the provider to explain material changes and show open actions with owners and dates.

Tuning needs customer context and governance

The provider may recognize common false positives, but the customer knows whether a remote tool, script, or business application is approved. Establish a tuning process that captures the exact condition, business reason, scope, approver, date, and review date. Keep exclusions narrow and preserve telemetry where possible.

The provider should not make a broad suppression permanent merely because the customer did not answer quickly. Define an interim disposition and escalation for unresolved application context.

Incident support and service limits

Ask what happens after an alert becomes a confirmed incident. Does the standard service continue investigation, help scope other endpoints, preserve evidence, join an incident bridge, or provide written findings? Are deeper forensics, malware analysis, recovery support, insurer coordination, or on-site work separate services? What are their availability and rates?

The business should maintain its own incident plan, contacts, insurance notification procedure, legal and privacy assessment path, communications ownership, backups, and recovery authority. A managed endpoint service contributes evidence and actions within scope; it does not automatically become the full incident team.

Plan offboarding before onboarding

The exit terms should cover agent removal or transfer, policy export, alert and case export, telemetry access, customer data return and deletion, credential revocation, integration removal, open-incident handoff, and continuity during transition. Confirm formats and time limits. Keep a current asset and configuration record so the provider is not the only source of operational knowledge.

Test the service model

Ask for a walkthrough of a realistic incident: a suspicious endpoint, an affected user, a possible identity signal, and a containment decision. Confirm what the provider sees, who is notified, the expected evidence in the incident brief, and how unresolved remediation is tracked.

Then run a controlled test. Verify sensor health, alert creation, analyst receipt, customer notification, investigation detail, a safe isolation and release where approved, ticket updates, after-hours escalation, and final reporting. Record gaps, owners, and acceptance conditions.

Questions to ask before signing

Which devices, data sources, licences, and operating systems are included?
Does “24/7” mean automated collection, human monitoring, investigation, or all three?
When do acknowledgement and response clocks start and stop?
Which actions may analysts take without approval, and on which device classes?
What happens if no customer contact responds?
How are failed sensors, exclusions, false positives, and recurring alerts handled?
What evidence, reports, and telemetry can the customer access and export?
Where is data stored and processed, and which subprocessors are involved?
Which incident activities and integrations cost extra?
What happens to agents, records, credentials, and open incidents at termination?

The NIST small-business incident-response guidance is a useful reference for the roles that remain important after a managed service is in place.

Start with the EDR pillar guide, then compare managed and in-house EDR and review EDR deployment best practices before choosing a provider. Use the managed EDR onboarding guide and SLA checklist to test the proposed service.

Need to evaluate a proposed managed EDR scope? Talk to Quantm.