XDR RFP Template (Free): EDR and XDR Requirements

How to run an XDR RFP

An XDR evaluation is mostly about two things: how well the endpoint agent detects and contains attacks without disrupting your machines, and how much of the rest of your environment the platform can see and act on. The example schedule in this template runs about 12 weeks from kickoff to contract award. Agent rollout and removal of your current endpoint product follow the award and need their own plan.

1. Map your endpoints, telemetry and current tools (weeks 1-2). Count endpoints and servers by operating system and version, including virtual desktops, cloud-hosted servers and containers. List the tools the platform must see or act through: identity provider and directory, email and collaboration suite, cloud accounts, firewalls and network sensors, SIEM, SOAR and ticketing. Note when your current endpoint product's contract ends, because the migration plan works back from that date. Write down what happens today when an endpoint alert fires at night.
2. Assemble the buying team. Include the security operations lead and analysts who will use the console every day, the endpoint and server teams who will deploy the agent and carry the risk of an agent problem, and the owners of identity, email, cloud and network tools. Add procurement, legal and privacy (what telemetry leaves your environment and where it is stored), and finance. If an MDR provider works for you today, involve it early: it may need to operate the new platform.
3. Choose native or open XDR, and decide whether you need an RFI (weeks 2-3). Decide whether you want one vendor's endpoint, identity, email and cloud products working together (native XDR), a platform that works through the tools you already own (open or hybrid XDR), or either (see the next section). If that's still open, or your long list has more than five vendors, issue a short RFI asking which of your tools each platform covers natively or through integration, which response actions it can take through each, and how it prices. Use the answers to build a shortlist.
4. Tailor and issue the RFP (weeks 3-6). Delete requirements that don't apply, adjust priorities, and add your environment details and tool list to Section 1. If you're buying EDR only, delete the XDR telemetry and integration lines rather than marking them Nice-to-have. Give vendors three weeks to respond, with a written question-and-answer window in the first week.
5. Score the responses (weeks 6-7). Have each evaluator score independently against the rubric before comparing notes, and set aside any vendor that misses a Must-have. Check every 'yes' for whether it needs an add-on module, a higher license tier, a third-party product or a feature still in preview, and whether a telemetry source supports response actions or only alerts.
6. Run a proof of concept with two or three vendors (weeks 7-10). Deploy agents to a pilot group that includes workstations, servers and each operating system you run, and connect your identity provider, email suite and one cloud account. With your IT team's agreement, run benign attack simulations on test machines and test accounts, such as a credential theft attempt followed by lateral movement and a malicious inbox rule, and check whether each platform links them into one incident and lets you contain it. Measure agent impact on your busiest servers, test the update controls, forward alerts to your SIEM, and call references that migrated from another EDR.
7. Negotiate and award (weeks 10-12). Use the pricing table to compare like for like, including add-on modules, data retention and third-party data ingestion. Plan the migration from your current endpoint product, with an overlap period so no endpoint goes unprotected, and settle renewal caps and exit terms before you sign.

XDR vs EDR vs SIEM: which RFP do you need?

EDR watches endpoints: it records process, file, network and user activity on laptops and servers, detects attacks, and lets analysts isolate a host, end a process or remove a file. XDR starts from that endpoint foundation and adds telemetry from identity, email, cloud and network tools, correlates it into incidents, and takes response actions across those tools. A SIEM collects and stores logs from almost any source for detection, investigation, compliance reporting and long-term retention, but it relies on other tools, or a SOAR platform, to take most response actions.

XDR has no standards-body definition, and vendors use the label differently. Native XDR works mainly through one vendor's own products; open or hybrid XDR works through integrations with tools from other vendors. Requirement T1 makes each vendor state which it offers and list every integration, so you can compare like with like. XDR and a SIEM can run side by side, with the XDR forwarding alerts to the SIEM for retention and correlation with other logs. If you want a provider to operate detection and response around the clock, use the RFPhub MDR RFP template instead (linked below).

Signs you need an XDR RFP rather than an EDR-only or SIEM RFP:

• Attacks you investigate cross several tools, such as a phished account that leads to a compromised laptop, and your analysts piece them together by hand.
• You want to disable an account, revoke sessions or pull an email from the same console where you isolate a host.
• Your endpoint product is due for renewal and you're considering a wider platform from the same or another vendor.
• Your main need is detection and response, not long-term log retention or compliance reporting across every system, which is SIEM work.

XDR RFP requirements

Each line is written to paste straight into your RFP. Must-have means a vendor that cannot meet it is out; Nice-to-have earns extra points. Change the priorities to fit your situation, and delete what doesn't apply.

Functional

Technical and architecture

Integration

Security and compliance

Implementation and support

Commercial and pricing

Questions to ask XDR vendors

These questions are designed to separate vendors, not to collect brochure answers. Ask for evidence: a demo, a document or a reference.

1. Show a redacted incident from a real customer environment where your platform linked activity across endpoint, identity and email into one incident. Show the first signal, how the alerts were grouped, and which response actions were taken from the console.
2. For each of our tools [list], is it covered by your own product or by an integration? Which data do you collect from it, and which response actions can you take through it? Who maintains each integration, and what happens when the other vendor changes its API?
3. Walk us through how a new agent version and a new detection content update reach our endpoints: the testing before release, the staged rollout, and what we can delay, pause or roll back.
4. Which components of your agent run in kernel mode on each operating system, how does the agent behave if one of them fails, and what is your plan to reduce kernel dependence where operating systems offer alternatives?
5. An attacker replays a stolen session token to open a user's mailbox from a new country, creates a forwarding rule, then signs in to a server with the same account. Show what the platform detects, how it links the events, and which actions are available to us.
6. During the proof of concept we'll run benign attack simulations mapped to MITRE ATT&CK on test machines. Which techniques do you expect to block, which to detect only, and how will the console show us the difference?
7. If you have taken part in MITRE ATT&CK Evaluations, which rounds, and which products and settings were used? How do they differ from the edition and configuration you propose for us?
8. What raw telemetry do you keep, at what level of detail and for how long by default? What does it cost to keep it searchable for [number] days?
9. Which triage, investigation and response steps can automation or AI features carry out without an analyst approving them? How do you check AI-generated conclusions, and is our data used to train models that serve other customers?
10. What performance impact should we expect on our busiest servers and on developer workstations, and which exclusions do you recommend? Share the tuning guidance you give customers.
11. What does it take to forward alerts and raw telemetry to our SIEM? Is anything lost, delayed or charged extra when we do?
12. How would you move us from our current endpoint product [name]: removal, coexistence during rollout, order of waves, and how long both agents run side by side?
13. Which modules and features in your proposal are generally available today, which are in preview, and which are on the roadmap? Give dates for the roadmap items.
14. What managed services do you or your partners offer on the platform, such as MDR, managed threat hunting and incident response? What response authority do their analysts have, and who keeps our detections and data if we end the service?
15. Provide two references of similar size and environment: one that handled a confirmed incident with your platform, and one that migrated to it from another EDR product.

Scoring rubric

Score each criterion from 1 to 5, multiply by its weight, and add the results. The weights below are a starting point; agree on your own before any proposals arrive so the scoring can't be bent around a favorite.

Scoring scale

• 5 Exceeds: meets every Must-have and most Nice-to-haves, shown in a demo or proof of concept, with a matching reference customer.
• 4 Strong: meets every Must-have and some Nice-to-haves, with clear evidence.
• 3 Adequate: meets most Must-haves; gaps have a credible workaround or a dated roadmap commitment.
• 2 Weak: misses one or more Must-haves, or the answer is vague.
• 1 Poor: does not meet the requirement, or no answer.

Frequently asked questions

What should an XDR RFP include?

Your endpoint counts and the other telemetry sources the platform must cover; requirements for the endpoint agent, correlation, threat hunting, response actions and automation, each marked Must-have or Nice-to-have; a statement of whether you want native or open XDR; integration requirements for your SIEM, SOAR, identity provider and ticketing; agent update controls, security and data-handling terms; a pricing table that separates modules, data ingestion and retention; and the rubric you'll score with. This template includes all of them.

What is the difference between native and open XDR?

Native XDR works mainly through one vendor's own products, such as its endpoint agent, identity protection, email security and cloud security, so the parts are designed to work together. Open or hybrid XDR works through integrations with tools from other vendors, so you can keep products you already own. The labels are used loosely, so ask every vendor to list exactly which of your tools it covers, what data it collects from each, and which response actions it can take through them.

Do we still need a SIEM if we buy XDR?

It depends on what you need beyond detection and response. XDR focuses on detecting and responding to attacks across the sources it covers, while a SIEM collects logs from almost every system for broader correlation, compliance reporting and long-term retention. If you need those, keep or buy a SIEM and forward XDR alerts to it. If you don't, check the XDR platform's retention terms carefully before deciding you can do without one.

Should we buy XDR or MDR?

XDR is a platform your own team operates, and MDR is a service in which a provider's analysts monitor, investigate and respond for you around the clock. If nobody watches alerts at night and weekends, you need MDR or an XDR vendor's managed service as well as the technology. An MDR provider may run its service on your XDR platform or bring its own, so decide first whether you want to own the platform or have the provider supply it.

How long does an XDR RFP take?

The example schedule in this template runs about 12 weeks from kickoff to contract award, including three weeks for vendor responses and three to four weeks for a proof of concept on your own machines. Agent rollout and removal of your current endpoint product follow the award. Plan an overlap so no endpoint is left unprotected during the switch.

Related RFP templates

• Managed Detection and Response (MDR) Software RFP Template
• Security Information and Event Management (SIEM) Software Solution RFP Template
• Security Orchestration, Automation, and Response (SOAR) Software RFP Template
• Threat Intelligence Software RFP Template

Download Template