Evaluating an EDR for a Mid-Market Team: A Buyer Guide

This guide does not rank products and does not score any. It gives you a grid to run the same evaluation on every candidate, so that the comparison reflects your environment instead of a brochure. Use it to write your requirements before the first demo, then to hold every vendor to the same questions.

Each section follows the same four steps: what to decide, what to ask the vendor, what should worry you, and what to get priced.

Before you start: define your own conditions

An EDR that suits a company with a large security team may be wrong for one with two IT generalists. Write down, in one page, the facts that frame the evaluation:

The operating systems and versions in use, including old ones you cannot retire yet, servers, and any non-Windows endpoints.
Who will read alerts, during which hours, and with what skills.
Whether you will pair the product with a managed detection service, or run it yourself.
Your regulatory and contractual obligations on where telemetry may be stored.
The other security tools it must work with: identity provider, email security, SIEM, ticketing.

Everything below should be answered against this page, not against the vendor's reference customer.

1. Coverage: what does it actually protect?

Decide. The list of device types and operating systems that must be covered, with a line for each exception you will tolerate.

Ask the vendor.

Which operating system versions and kernels does the agent support, and what is the support window for each?
Which capabilities differ by platform? Are detection, response actions and isolation all available on servers and non-Windows systems, or only on part of them?
How does the product treat devices that are intermittently connected, such as laptops that spend weeks off the corporate network?
What does it do on devices where the agent cannot be installed, if anything?

Warning signs.

A feature list that does not say which platforms each feature applies to.
Support for your older systems described as "possible" or "on request".
Evaluation limited to a lab that does not resemble your fleet.

Get priced. The cost for every device class you actually have, including servers and virtual machines, and the cost of anything you must add to cover the gaps.

2. Detection: how does it find things, and how can you tell?

Decide. The kinds of threats that worry you most (ransomware, credential theft, abuse of legitimate tools, hands-on-keyboard intrusion) and how you will check that the product sees them in your environment.

Ask the vendor.

What is the detection logic based on: signatures, behaviour, machine learning, rules you can read? Which of these can you inspect and adjust?
Can you write your own detections, and are they portable if you leave?
Can you see why an alert fired, with the process tree and the evidence, in a form an analyst can verify?
How are detections updated, how quickly, and are you told what changed?
Which independent evaluations exist, what exactly did they test, and when? A published evaluation tells you about a specific test on a specific configuration. Read its scope before citing it.

Warning signs.

Detections that cannot be explained ("the model decided").
No way to test the product against your own scenarios in a proof of concept.
Results quoted without the configuration used to obtain them.

Get priced. Any additional modules needed for the detections you were shown in the demo. Ask which of them were enabled during the demo, and which cost extra.

3. Response: what can it do, and who decides?

Decide. Which actions you accept being taken automatically (isolating a machine, killing a process, disabling an account) and which require a human. Write the authority down before the product arrives.

Ask the vendor.

Which response actions are built in? Which require a separate module or licence?
Can actions be limited by device group, so that servers are handled differently from laptops?
Can you roll back changes the product made, such as quarantined files or blocked processes?
What is the procedure when the agent itself is the problem, for example after a faulty update?

Warning signs.

Automatic remediation presented as a feature with no way to configure or limit it.
No documented procedure for a bad agent update. Ask it of every candidate: software with deep system access can fail at scale.
Response available only from the vendor's console, with no API.

Get priced. The people-time to handle response: if you rely on your own staff, include after-hours coverage; if on a managed service, see below.

4. Operations: what will running it cost you in time?

Decide. How many alerts your team can realistically handle per day, and what happens to the rest.

Ask the vendor.

What does a typical deployment involve? How is the agent rolled out, upgraded and removed across the fleet?
How much tuning does the product need in the first months, and who does it?
How does the agent update, and can you stage and delay updates for critical systems?
What are the performance impacts the vendor documents, and can you measure them on your own hardware in the trial?
What reporting and audit trail does it provide?

Warning signs.

A trial that skips deployment and runs on a handful of hand-picked machines.
Updates that cannot be controlled by you.
A requirement for "professional services" to reach basic functionality.

Get priced. Deployment, tuning and training effort, in days, for your team and for the vendor's.

5. Integration and data: where does the information go?

Decide. What data must be able to leave the product, in what format, and where the telemetry may be stored.

Ask the vendor.

In which regions is telemetry processed and stored? Can you choose?
How long is data retained by default, and what does longer retention cost?
What does the API cover: alerts only, or also raw telemetry and configuration?
Can the data be exported in a documented format to your own SIEM or data store, and at what cost?
Which sub-processors handle your data?

Warning signs.

Retention that is short by default and only extended through a priced add-on you discover late.
An export that works for alerts but not for the underlying events.
Vague answers on sub-processors and data location.

Get priced. Retention at the length you need, API access, and the cost of storing the telemetry in your own platform if you export it.

6. The managed service question

If the product is bundled with a monitoring and response service, evaluate the service as a separate offer. The software and the people are two purchases that happen to share an invoice.

Ask the vendor.

Which hours are covered by human analysts, and which by automation only?
What exactly does the service-level agreement measure (acknowledgement, investigation, containment, notification) and from which moment?
Which actions can analysts take without your approval?
Who owns the detections and investigation history if you stop the service?

Warning signs. Service credits as the only remedy; coverage described as "24/7" without saying whether humans or software are on duty; contract scope that excludes the data sources you care about.

Get priced. The service as a stand-alone line, with and without after-hours coverage and incident response hours included.

7. Exit: how do you leave?

Decide. What you need to leave without a gap in protection.

Ask the vendor.

How is the agent removed, and does removal work if your management console is no longer available?
Can you run another product alongside it during migration, and what does the vendor say about conflicts?
Which of your configuration, policies and custom detections can be exported in a usable form?
What happens to your data after termination, and how is deletion confirmed?
What are the renewal terms and the notice period?

Warning signs. Tamper protection with no documented removal path; auto-renewal with a long notice window; exports available only in a proprietary format.

Get priced. A migration scenario: parallel running of two agents for a defined period, plus the effort to rebuild exclusions and policies.

Running the evaluation

Give every candidate the same one-page brief and the same proof of concept on a sample of your own devices, including at least one you consider awkward. Record the answers in this grid. Where a vendor cannot or will not answer a question, write "not answered" and keep the cell visible; that is information, not a gap in your note-taking.

Take the final decision with three people in the room: someone who will operate it, someone who will pay for it, and someone who will have to explain a breach. If they disagree, the grid shows where.