An EDR or XDR RFP that asks "do you detect ransomware?" gets the same yes from every bidder, so the decision ends up resting on a slide deck instead of on how the agent behaves on your own machines. This template gives you a ready-to-issue request for proposal for endpoint detection and response or extended detection and response, with numbered requirements that can each be tested in a proof of concept and scored. It covers prevention efficacy, telemetry depth and retention, tamper protection, operating system coverage, response actions, XDR integrations, managed detection and response options, platform security, services and commercials. It is vendor-neutral and written for security operations leads, endpoint engineering teams and procurement panels. For how the market is structured and what separates EDR from XDR, read the EDR and XDR Buyer's Guide; for the selection process, the Security Vendor Evaluation and RFP Guide.
How to use this template
- Replace text in square brackets, such as [Organisation], [operating systems] and [number], with your own details. Delete requirements that do not apply.
- Each requirement has an ID (for example EDR-TMP-02) and a type: M mandatory (pass or fail), S scored (0 to 5, weighted) or I informational.
- If you are buying EDR only, delete section 4.6 (XDR) and move its weight to telemetry and response. If you want a managed service, keep section 4.7 and also use the MDR RFP Template.
- Weights, volumes and timings in brackets are illustrative. Set them before issue and do not change them after responses arrive.
- Issue sections 1 to 8 to bidders. The Implementation guidance section is for your panel only.
1. Purpose and scope
[Organisation] invites proposals for an endpoint detection and response platform [with extended detection and response capabilities] [and an optional managed detection and response service]. The platform must prevent common malware and ransomware, record enough endpoint activity to investigate an intrusion, resist attempts to disable it, and let analysts contain a compromised device within minutes.
- In scope: [number] Windows workstations; [number] macOS devices; [number] Linux and Windows servers; [virtual desktop infrastructure]; [cloud virtual machines and container hosts]; [mobile devices, if required].
- Out of scope: [email security]; [SIEM replacement, unless XDR is chosen as the primary analytics platform]; [device management and patching].
- Drivers: [end of life of the current antivirus]; [ransomware risk]; [cyber insurance requirements]; [lack of investigation data after a past incident]; [analyst workload].
- Contract term: [three] years with an option to extend.
2. Organisation background and current state
| Item | [Organisation] value |
|---|
| Endpoints by operating system and version | [Windows client versions and number]; [macOS versions]; [Windows Server versions]; [Linux distributions, kernel versions] |
| Legacy or special systems | [unsupported operating systems]; [air-gapped hosts]; [OT engineering workstations]; [kiosks] |
| Current protection | [current antivirus or EDR, licence end date]; [application control]; [device management platform] |
| Security operations | [in-house SOC hours]; [number of analysts]; [MSSP or MDR provider]; [SIEM and SOAR] |
| Identity platform | [directory and identity provider], for XDR identity signals |
| Network and email sources | [firewalls, proxies, email security], for XDR correlation |
| Data residency | [regions where telemetry may be stored and processed] |
3. Instructions to bidders
- Timeline: RFP issued [date]; clarification questions by [date]; responses due [date, time, time zone]; proof of concept [dates]; decision [date].
- Single point of contact: [name, email].
- Response scale: available now; available with configuration; custom development; third-party product required (name it); roadmap (committed date); not supported. Roadmap answers score zero unless contractually committed.
- Evidence: reference product documentation for each "available now" answer and state the licence tier required. You may reference public independent test results, such as MITRE ATT&CK Evaluations, stating the test round, configuration and whether prevention or detection-only mode was used.
- Feature parity: for every requirement, state any difference in support between Windows, macOS and Linux. An answer without an operating system breakdown is treated as Windows only.
4. Functional requirements
4.1 Prevention efficacy
| ID | Requirement | Type |
|---|
| EDR-PRV-01 | Blocks known and unknown malware on execution, using signatures, machine learning and behavioural detection, with prevention working while the device is offline. | M |
| EDR-PRV-02 | Detects and stops ransomware behaviour (mass file encryption, shadow copy deletion) and describes any rollback or file recovery capability per operating system. | M |
| EDR-PRV-03 | Detects fileless and script-based attacks, including malicious PowerShell and living-off-the-land binary use, and integrates with the Windows Anti-Malware Scan Interface (AMSI). | S |
| EDR-PRV-04 | Detects credential theft behaviour such as access to LSASS memory, and blocks it where the operating system allows. | S |
| EDR-PRV-05 | Provides granular exclusions (by hash, signer, path and process) with mandatory justification, expiry and audit trail. | S |
| EDR-PRV-06 | Offers device control (USB storage) and host firewall management, or integrates with existing tools for these. | I |
See the EDR Tuning and Exclusions Management Guide.
4.2 Telemetry depth and retention
| ID | Requirement | Type |
|---|
| EDR-TEL-01 | Records process creation with full command line and parent chain, file, registry, network connection, DNS, module load, logon and script content events on Windows; list the equivalent event types on macOS and Linux. | M |
| EDR-TEL-02 | Retains raw searchable telemetry for at least [30, 90] days in the base licence; state the cost for [180 or 365] days. | M |
| EDR-TEL-03 | States whether telemetry is filtered or sampled on the endpoint before upload, and which events are dropped. | S |
| EDR-TEL-04 | Provides a documented query language for threat hunting across all endpoints and supports scheduled custom detections. | S |
| EDR-TEL-05 | Streams raw telemetry and alerts to [SIEM or data lake] in near real time, with no extra licence for export; state the format. | S |
| EDR-TEL-06 | Maps detections to MITRE ATT&CK technique IDs and shows the process tree for each alert. | S |
See the Endpoint Telemetry Guide.
4.3 Tamper protection and sensor resilience
| ID | Requirement | Type |
|---|
| EDR-TMP-01 | Prevents local administrators and SYSTEM-level processes from stopping, uninstalling or modifying the agent without a per-device or per-session token issued from the console. | M |
| EDR-TMP-02 | Raises a high-severity alert when an agent stops reporting, is tampered with, or loses kernel visibility, and states the detection delay. | M |
| EDR-TMP-03 | Detects and blocks loading of known vulnerable drivers used to disable security tools (bring your own vulnerable driver), and describes the blocklist update process. | S |
| EDR-TMP-04 | Detects attempts to disable or modify security tools and event logging (MITRE ATT&CK T1685 Disable or Modify Tools). | S |
| EDR-TMP-05 | Detects a device booting into Safe Mode or an alternative operating system to bypass the agent, where the platform allows. | S |
See the Bring Your Own Vulnerable Driver and EDR Killers Guide and the EDR Tampering and BYOVD Response Playbook.
4.4 Operating system coverage and agent operations
| ID | Requirement | Type |
|---|
| EDR-OS-01 | Supports all operating systems and versions listed in section 2; list support end dates for each and for older versions still in our estate. | M |
| EDR-OS-02 | On Linux, states the sensor technology (kernel module, eBPF or user mode), supported kernels and behaviour after a kernel update. | S |
| EDR-OS-03 | Agent and content updates can be staged in rings (test, pilot, broad), pinned and rolled back by [Organisation], and the bidder describes its own release testing and staged rollout of detection content. | M |
| EDR-OS-04 | States typical CPU, memory, disk and bandwidth overhead on [reference workstation and server], and supports VDI and non-persistent images. | S |
| EDR-OS-05 | Deploys through [device management platform], reports agent health per device and identifies unprotected devices on the network. | S |
4.5 Investigation and response
| ID | Requirement | Type |
|---|
| EDR-RSP-01 | Isolates a device from the network while keeping its connection to the console, from the console and API, within [one minute]. | M |
| EDR-RSP-02 | Kills processes, quarantines files, blocks hashes across the estate and removes persistence. | M |
| EDR-RSP-03 | Provides a remote shell for analysts with role-based restriction, approval for high-risk commands, and full session logging. | S |
| EDR-RSP-04 | Collects forensic artefacts (memory image, files, event logs) for preservation without altering evidence more than necessary. | S |
| EDR-RSP-05 | Supports automated response playbooks with human approval steps and integrates with [SOAR]. | S |
4.6 XDR integrations and correlation
| ID | Requirement | Type |
|---|
| EDR-XDR-01 | Ingests and correlates signals from [identity provider], [email security], [cloud audit logs] and [network controls] into single incidents; list native and third-party connectors. | S |
| EDR-XDR-02 | Takes response actions in connected tools, such as disabling a user, revoking sessions or blocking an indicator at the firewall. | S |
| EDR-XDR-03 | Detects identity-based attacks (for example anomalous sign-ins or service account misuse) and links them to endpoint activity. | S |
| EDR-XDR-04 | States data ingestion limits, retention and extra cost for third-party data sources. | I |
See the XDR Guide.
4.7 Managed detection and response options
| ID | Requirement | Type |
|---|
| EDR-MDR-01 | Describe any managed service: hours of coverage, analyst locations, time to triage and time to notify by severity. | I |
| EDR-MDR-02 | State which response actions the service may take without approval, and how [Organisation] sets and changes that authority. | S |
| EDR-MDR-03 | Supports a third-party MDR provider of [Organisation]'s choice through full API and console access. | S |
See the MDR Buyer's Guide.
An EDR agent runs with the highest privilege on every device and the console can run commands on all of them, so the platform and its update channel are part of your attack surface.
| ID | Requirement | Type |
|---|
| EDR-SEC-01 | Console access through [Organisation] SSO with phishing-resistant MFA; granular roles separate viewing, response and policy change; remote shell is a separately granted role. | M |
| EDR-SEC-02 | API credentials are scoped, expiring, revocable and logged; list every API permission available. | M |
| EDR-SEC-03 | All console actions, policy changes and remote shell sessions are logged and exportable to [SIEM]. | M |
| EDR-SEC-04 | Describe code signing of agent and content updates, secure development practices and how a faulty update is detected and halted. | M |
| EDR-SEC-05 | Provide a current independent assurance report, a [SIG or CAIQ] response, vulnerability disclosure policy and incident history for the last three years. | M |
| EDR-NF-01 | Console availability of [percentage]; agents keep preventing threats when the cloud console is unreachable. | S |
| EDR-NF-02 | Exports telemetry, detections and configuration at exit, with certified deletion. | M |
6. Implementation, services and support
- Migration: describe the switch from [current product], including coexistence period, removal tooling and how protection gaps are avoided during cut-over.
- Policy tuning: describe audit or detect-only mode, the tuning period and how exclusions are reviewed before prevention is enforced.
- References: [two or three] references of similar size and operating system mix, at least one with Linux servers in production.
- Support: severity definitions, response targets, named technical contact and escalation path for a suspected faulty update.
7. Commercials
| Cost element | What to state |
|---|
| Licence metric | Per endpoint, per user or per workload; how servers, VDI, containers and short-lived cloud instances are counted |
| Tiers and add-ons | Which section 4 requirements need a higher tier (telemetry retention, XDR, threat hunting, device control, identity) |
| Data costs | Retention beyond the base period; third-party data ingestion; export |
| Managed service | Price for MDR, if offered, per endpoint, with incident response retainer terms |
| Growth, renewal and exit | Price for [growth percentage] more endpoints; renewal cap; exit charges |
8. Evaluation method and proof of concept
| Criterion | Weight | Evidence |
|---|
| Prevention and detection results | [30%] | Proof of concept test scenarios |
| Telemetry, hunting and response (4.2, 4.5, 4.6) | [20%] | Analyst-scored proof of concept tasks |
| Tamper resistance and agent operations (4.3, 4.4) | [15%] | Proof of concept tests, update process review |
| Platform security (section 5) | [10%] | Assurance reports, architecture review |
| Implementation and support | [5%] | Section 6, references |
| Three-year life-cycle cost | [20%] | Section 7 |
Scores use 0 to 5: 0 not met; 1 roadmap only; 3 met with configuration; 5 met fully and demonstrated. The proof of concept runs for [number] weeks on [number] representative devices per operating system, including a server and a developer workstation, and covers at minimum:
- Deployment through [device management platform]; record agent health, overhead and any application conflicts.
- An authorised adversary emulation run by [internal red team or testing provider] in an isolated test segment, using a scenario mapped to ATT&CK techniques relevant to us; record what was prevented, detected, missed and how alerts were grouped.
- Ransomware simulation with a sanctioned test tool on a non-production host; record time to block and any rollback.
- Tamper tests: attempt to stop and uninstall the agent as local administrator; confirm the alert and the delay.
- Analyst tasks: hunt for a given command line across all test devices; isolate a device; collect a memory image; scored by the analysts who will use the platform.
- Staged update: push a new agent version to the test ring only, then roll it back.
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Test in your own estate: public evaluations show how a product behaved in one lab configuration. Your own proof of concept, on your images and with your applications, decides false positive load and overhead.
- Weight telemetry by your team: a small team without a SOC should weight prevention, automated response and MDR higher; a mature SOC should weight raw telemetry, retention and query capability higher.
- Treat the update channel as a risk: score EDR-OS-03 and EDR-SEC-04 seriously. Ring-based deployment for agent and content updates is the control that limits the impact of a faulty release.
- Linux and macOS parity: many products are strongest on Windows. If servers carry your crown jewels, weight Linux results separately.
- Identity angle: EDR consoles, API keys and MDR provider accounts are highly privileged identities. Put them under the same controls as other privileged access; see the PAM RFP Template.
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|
| Prevention (4.1) | SI-3, CM-7 | PR.PS-05 |
| Telemetry and detection (4.2, 4.6) | AU-12, SI-4, AU-6 | DE.CM-09, DE.AE-02 |
| Tamper protection and integrity (4.3, 5) | SI-7, SI-4 | PR.PS-01, DE.CM-09 |
| Response (4.5, 4.7) | IR-4 | RS.MI-01 |
| Platform and supplier (5) | SA-9, SR-6 | GV.SC-05, GV.SC-06 |
Standards and references
Related NHI Mgmt Group resources: EDR and XDR Buyer's Guide · EDR Guide · Endpoint Security Guide · MDR RFP Template · Security Vendor Evaluation and RFP Guide