Choose an XDR tool by testing it against your own incidents, not by feature lists. Check which of your data sources it truly joins, which response actions it can take safely, what evidence it shows for each alert, and how you leave if it fails. Decide whether you need software, a managed service or both.
Do you need XDR at all?
Start with the problem. If analysts spend most of an alert reading three consoles, a joined view may help. If you have no one to read alerts at night, you may need a service more than a product. If your endpoint tool already covers your risks, the extra platform may add cost and little else.
This guide does not rank vendors and names none. The criteria below are the part that lasts.
Which data sources does it really join?
Ask for the list of sources, then ask what "supported" means. There is a large gap between reading a log, enriching it, correlating it and acting on it.
For each source you care about (endpoints, identity, email, cloud control plane, network, SaaS), get answers to these:
- Is the data native to the platform, or ingested through a connector?
- How long does it take from event to visible alert?
- Which fields are kept, and which are dropped?
- Can you query the raw data, or only see the platform's alerts?
Then check it against your estate. A tool that joins sources you do not use is not a match.
What response actions can it take, and who approves?
List the actions: isolate a host, kill a process, disable an account, revoke a session, block a sender. For each one ask whether it can run automatically, whether you can require approval, and whether it can be undone.
NIST's incident response guidance, SP 800-61 Revision 3, frames response as part of cybersecurity risk management under the Cybersecurity Framework 2.0. Use that framing in the demo: a response action is a business decision with a technical switch, so approval rules matter as much as capability.
What evidence does each alert show?
An alert you cannot explain is an alert you cannot trust. During a trial, pick ten alerts and ask the analyst to explain each to a colleague using only what the tool shows. Look for the chain of events, the matching detection logic and a link to technique names, such as those in MITRE ATT&CK.
Ask for a way to export that evidence. You will need it for post incident reviews and, in some sectors, for regulators.
Product, service or both?
A product gives you control and needs people. A managed service gives you coverage and shifts some decisions to the provider. Ask for the service boundary in writing:
- What do they investigate, and what do they hand to you?
- Can they take response actions, or only recommend?
- What is the contact path at 3 a.m., and who decides?
- Who owns the detections: you, them or both?
What are the cost and exit terms?
We are not quoting figures. Ask how the price is set (per endpoint, per user, per data volume), what counts as billable, and what happens to price when you add a source. Ask what retention is included and what it costs to extend.
Then ask about leaving. Can you export raw data and detections in a usable format? How long does the provider keep your data afterwards? A good exit clause is a sign of a provider who expects to keep you by being useful.
A simple scoring sheet
Score each candidate from 0 to 3 against your own weighted list. A sample set of rows:
- Covers our top five data sources natively.
- Explains each alert from its own evidence.
- Supports approval and rollback for response actions.
- Lets us query raw data.
- Gives a clear service boundary, if managed.
- Has export and exit terms we accept.
- Fits the team we have, not the team we wish we had.
Weight the rows before the demos so the loudest presenter does not set the weights.
What to do
- Write your top three incident types and the data needed to detect them.
- Shortlist by those needs, not by market reports.
- Run a two week trial on your own data, with a labelled set of past incidents.
- Score with the sheet above, with two people scoring independently.
- Get service boundaries, pricing basis and exit terms in writing.
- Check references from a company of your size and shape.
Safeguard focuses on the application and software supply chain side and does not replace an XDR platform. Use it alongside, not instead.
Quick check
What is the most reliable test of an XDR tool?
Replaying a handful of your own past incidents, or constructed ones, and seeing whether it detects them and explains each alert from its own evidence.
Should we buy a product or a managed service?
Pick by staffing. If you cannot watch alerts around the clock, a service helps. If you have analysts and want control over detections, a product fits better.
Sources
Last reviewed: 18 October 2026.
