Paste-ready MDR requirements (24x7 SOC, endpoint, identity, cloud and network coverage, response authority, SLAs, onboarding), provider questions and a weighted scoring rubric.
See the structure before you download. The Word file has every section listed below, ready to fill in.
The sections in the document, in order.
Use this MDR RFP template when you're hiring a managed detection and response provider to watch your environment around the clock, investigate threats and contain them on your behalf.
MDR is a service, not software: you're buying a provider's analysts, processes and authority to act, and in 2026 that service should cover identity, cloud, email and network telemetry as well as endpoints.
The template is written for the security, IT and procurement team running the evaluation, and it covers when to issue an RFI first, the requirements to send, the questions that separate providers, and how to score the answers.
Download the editable Microsoft Word version below. Every requirement, vendor question and scoring weight on this page is in the document, ready to tailor and send.
An MDR evaluation is about the provider's people and processes as much as its technology, so most of the work is agreeing what the provider will watch, what it may do on your behalf, and how fast. The example schedule in this template runs about 12 weeks from kickoff to contract award. Onboarding follows the award and needs its own plan.
An MDR RFP buys a service. The provider's analysts watch your telemetry around the clock, investigate what they find, and take the response actions you have authorized. Some providers run the service on their own detection platform; others work with the EDR and SIEM you already own. An EDR, XDR or SIEM RFP buys software that your own team operates, which covers nights and weekends only if you staff them.
A co-managed arrangement sits in between: your team works cases during business hours and the provider covers the rest, or both work in a shared console. This template handles all of these set-ups, and requirement T1 makes each provider state which platform the service runs on and who owns the licenses. If you plan to run detection and response entirely in-house, use the RFPhub XDR or SIEM RFP template instead (linked below).
Signs you need an MDR RFP rather than an XDR or SIEM RFP:
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.
| ID | Requirement | Priority |
|---|---|---|
| F1 | Monitoring, triage and investigation of alerts and telemetry by the provider's own analysts 24 hours a day, every day of the year, including nights, weekends and public holidays. State where your security operations centers are, and whether any part of the service is subcontracted. | Must-have |
| F2 | Endpoint detection and response coverage for Windows, macOS and Linux workstations and servers, including virtual machines and cloud-hosted servers, through [our existing EDR / the provider's EDR]. State coverage for virtual desktops, containers and mobile devices. | Must-have |
| F3 | Identity threat detection and response for our cloud identity provider and on-premises directory, covering credential theft, password spraying, MFA fatigue and bypass, session token theft, risky sign-ins and privilege escalation. | Must-have |
| F4 | Cloud coverage for [list cloud providers]: monitoring of audit and control-plane logs and workload alerts for misuse of cloud identities, access keys and administrative rights, such as new privileged users, disabled logging or unexpected resource creation. | Must-have |
| F5 | Monitoring of our email and collaboration suite for account takeover, malicious inbox rules and forwarding, suspicious OAuth application consents, and unusual file sharing or downloads. | Must-have |
| F6 | Monitoring of audit logs from other SaaS applications we list, such as CRM, HR and source-code repositories. | Nice-to-have |
| F7 | Ingestion and analysis of network security telemetry, including firewall, VPN or ZTNA, DNS and web proxy logs. State whether you supply or support network detection and response (NDR) sensors, and what they add to the service. | Must-have |
| F8 | Proactive, hypothesis-driven threat hunting across our telemetry at a stated frequency, plus ad hoc hunts when a relevant new threat or exploited vulnerability is published, with results reported to us even when nothing is found. | Must-have |
| F9 | Response actions taken by the provider under a written response authority matrix that we approve: which actions analysts may take without contacting us (for example, isolating a host, ending a process, quarantining a file, disabling an account, revoking sessions or blocking an indicator), which need our approval, and how approval is obtained out of hours. | Must-have |
| F10 | Notification of every confirmed incident through the portal and, for high and critical severity, by phone to our escalation contacts in the order we set, with a written summary of what happened, the assets and users affected, the actions already taken and the actions we need to take. | Must-have |
| F11 | A clear statement of remediation scope: which remediation steps the provider performs itself (such as removing persistence, deleting malicious inbox rules, resetting credentials or releasing a host from isolation) and which are handed to our team with written guidance. | Must-have |
| F12 | A defined path from an MDR investigation to full incident response, including forensics, scoping, containment and recovery support. State what the MDR fee includes, how many incident response hours are included, who performs the work and how quickly it can start. | Must-have |
| F13 | Detection tuning for our environment: suppression of known-benign activity, custom detections for our critical applications and risks, and a process for us to request new detections and see the logic behind existing ones. | Must-have |
| F14 | Detections and incident reports mapped to MITRE ATT&CK tactics and techniques. | Must-have |
| F15 | A coverage view showing which MITRE ATT&CK techniques are covered by which of our telemetry sources, with recommendations to close gaps, updated for each service review. | Nice-to-have |
| ID | Requirement | Priority |
|---|---|---|
| T1 | A statement of the tooling model: the platforms the service runs on (EDR, SIEM or data platform, automation), whether each is supplied by the provider or by us, and who holds the licenses. List any of our current tools the service would require us to replace. | Must-have |
| T2 | For each of our existing tools [list EDR, SIEM, identity provider, email and collaboration suite, firewalls, cloud platforms], the integration depth: alerts only, full telemetry, or response actions through the tool's API. List the response actions available through each tool. | Must-have |
| T3 | A portal or shared console where our staff can see every alert, investigation, analyst note and response action in near real time, with the full timeline of each case. | Must-have |
| T4 | Co-managed operation: our analysts can query the underlying telemetry, run their own hunts and work cases alongside the provider's analysts, with a clear owner for each case. | Nice-to-have |
| T5 | Documentation of every agent, sensor or log collector we must deploy, where it runs, its sizing, and who maintains and updates it. Use direct cloud-to-cloud collection where the source supports it. | Must-have |
| T6 | Monitoring of telemetry health: an alert to us within a stated time when an agent goes offline, a log source stops sending or a sensor fails, so gaps in coverage are never silent. | Must-have |
| T7 | Searchable retention of telemetry for [number] days and of incident records for [number] years. State the default retention periods, the cost of longer retention and how we retrieve older data. | Must-have |
| T8 | Disclosure of automation and AI in the service: which triage, investigation and response steps are automated or AI-assisted, which are always reviewed by a human analyst before action, and whether our data is used to train models that serve other customers. | Must-have |
| ID | Requirement | Priority |
|---|---|---|
| I1 | Sign-in to the portal through our identity provider via SAML 2.0 or OIDC, with MFA and role-based access for our staff. | Must-have |
| I2 | Two-way integration with our IT service management (ITSM) platform, so incidents become tickets and status, comments and closure stay in sync in both directions. | Must-have |
| I3 | A documented REST API for incidents, alerts, response actions and reports, plus streaming of alerts and incident data to our SIEM or data lake via syslog or API in a documented schema. State whether OCSF is supported. | Must-have |
| I4 | Webhooks or API calls that trigger our own SOAR or automation playbooks when the provider confirms an incident. | Nice-to-have |
| I5 | Use of our asset inventory (CMDB) and vulnerability data to add business context, such as system owner, criticality and known exposures, to investigations. | Nice-to-have |
| I6 | Acceptance of our own watchlists and indicators, and sharing of indicators from our incidents in STIX/TAXII or another documented format. | Nice-to-have |
| ID | Requirement | Priority |
|---|---|---|
| S1 | A current SOC 2 Type II report and ISO/IEC 27001 certification covering the MDR service, its platform and its security operations centers, available under NDA. | Must-have |
| S2 | Controls on the provider's access to our environment: named analyst accounts, MFA, least-privilege roles, and a log of every action taken in our tools that we can review. State whether privileged access is granted just in time. | Must-have |
| S3 | Background checks for all staff with access to our data, and a list of the countries from which our data is accessed. State whether access can be restricted to analysts in a named country or region. | Must-have |
| S4 | FedRAMP authorization at the required impact level for the service and its platform, or equivalent regional certifications for public-sector use. Make this Must-have if you are a public-sector buyer. | Nice-to-have |
| S5 | Isolation of our tenant's data, encryption in transit and at rest, and storage of our telemetry and incident data in the regions we specify. | Must-have |
| S6 | A data processing agreement, a current list of sub-processors, and a contractual commitment to notify us of security incidents affecting our data or the provider's access to our environment within a defined time. State the time. | Must-have |
| S7 | Preservation of evidence and incident timelines in a form we can use for legal, insurance and regulatory purposes, with chain of custody for forensic evidence when required. | Must-have |
| S8 | Support for our incident-reporting obligations: written facts about a confirmed incident, delivered in time for us to meet deadlines set by regulators, customers and insurers (for example under NIS2, DORA or SEC disclosure rules, where they apply to us). | Must-have |
| S9 | Reports we can use as audit evidence of continuous monitoring and incident handling, for frameworks such as PCI DSS, ISO/IEC 27001 or SOC 2. | Nice-to-have |
| ID | Requirement | Priority |
|---|---|---|
| M1 | An onboarding plan with milestones for each telemetry source and agent deployment, a tuning period, and a defined go-live date when the SLAs start. State what monitoring and response we get during onboarding. | Must-have |
| M2 | An environment profile built with us during onboarding, covering critical systems and data, privileged accounts, expected administrative activity, business hours by region and escalation contacts, and reviewed at least [twice a year]. | Must-have |
| M3 | Incident runbooks agreed with us for common incident types, such as ransomware, business email compromise, compromised cloud credentials and insider activity, consistent with the response authority matrix. | Must-have |
| M4 | Contractual service levels, with service credits, for: time from alert to analyst triage, time to notify us of a confirmed high or critical incident, time to start a pre-approved containment action, and portal availability. For each, state the target, when the clock starts and stops, and how performance is measured and reported to us. | Must-have |
| M5 | 24×7 phone access to an analyst, so we can report a suspected incident or ask about an alert, with a stated response time. | Must-have |
| M6 | Monthly reporting on incidents, response actions, threat hunts, tuning changes, telemetry health and SLA performance, plus a quarterly summary written for executives and the board. | Must-have |
| M7 | A named service delivery manager and [monthly or quarterly] service reviews covering incidents, SLA performance, coverage gaps and recommendations. | Must-have |
| M8 | Advance notice of changes to the service, including the detection platform, security operations center locations, subcontractors and available response actions. | Must-have |
| M9 | An annual tabletop exercise with our team that tests the response authority matrix, the escalation contacts and the hand-off to incident response. | Nice-to-have |
| ID | Requirement | Priority |
|---|---|---|
| C1 | Pricing broken down by metric (per endpoint, per user, per employee or per data volume) and term, showing list price, discount and net price, and stating which telemetry sources, response actions, hunts and reports are included. | Must-have |
| C2 | Provider-supplied tooling (EDR, SIEM or data platform licenses) priced separately from the service, with a statement of what happens to those licenses, agents and data at the end of the contract. | Must-have |
| C3 | Terms for growth: how endpoint, user or data-volume overages are measured and charged, and how true-ups work. | Must-have |
| C4 | Incident response pricing: hours included in the MDR fee, rates for additional hours, retainer options, and whether unused retainer hours roll over or can be used for other services. | Must-have |
| C5 | A cap on price increases at renewal. State the cap. | Must-have |
| C6 | Ramped pricing that follows onboarding, so we don't pay full price for telemetry sources that are not yet connected. | Nice-to-have |
| C7 | A proof of value at no charge on a representative part of our environment. | Nice-to-have |
| C8 | Exit terms covering export of incident history, case notes, custom detections, runbooks and retained telemetry, transition assistance to a new provider, and support for removing agents. | Must-have |
These questions are designed to separate vendors, not to collect brochure answers. Ask for evidence: a demo, a document or a reference.
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.
| Criterion | Weight | What a strong response shows |
|---|---|---|
| Telemetry coverage and detection quality | 20% | Every Must-have source covered with real investigation, not just alert forwarding; detections tuned to your environment; results shown on your own data in the proof of value. |
| Response authority and incident handling | 20% | Analysts take the containment actions you authorize at any hour, a clear hand-off to incident response, and strong results in the simulated attack and tabletop exercise. |
| SLAs, reporting and transparency | 15% | Contractual SLAs with defined clocks and service credits, reports you would show your board, and full visibility of alerts, analyst notes and actions. |
| Tooling model and integration | 10% | A clear account of which platform the service runs on and who owns licenses, data and detections, plus working integration with your identity provider, ticketing and SIEM. |
| Onboarding and service management | 10% | A realistic onboarding plan with a defined go-live date, runbooks built with your team, and a named service delivery manager. |
| Security, data handling and compliance | 10% | Tightly controlled provider access to your environment, current SOC 2 Type II and ISO/IEC 27001, clear data location, and support for your incident-reporting obligations. |
| Commercials and total cost | 15% | Transparent pricing that separates the service, tooling and incident response, with fair overage, renewal and exit terms over a three-year view. |
| Total | 100% |
Scoring scale
Your environment and the telemetry the provider must cover (endpoint, identity, cloud, email and network); requirements for monitoring, investigation, threat hunting and response, each marked Must-have or Nice-to-have; a response authority matrix stating which actions the provider may take without asking; contractual SLAs with clear clock definitions; onboarding, reporting, security and data-handling terms; a pricing table that separates the service from tooling licenses and incident response hours; and the rubric you'll score with. This template includes all of them.
A managed security service provider (MSSP) traditionally manages and monitors security tools such as firewalls and SIEM, and forwards alerts to your team to investigate and act on. An MDR provider focuses on detection and response: its analysts investigate alerts, confirm what is real, and take containment actions such as isolating a host or disabling an account. The labels now overlap and some providers offer both, so ask each one exactly which actions its analysts take themselves and which they hand back to you.
It depends on what you already own and how long those contracts run. A provider running its own platform controls the detection content and response actions end to end, but its agents and licenses usually leave with it when the contract ends. A provider that works on your tools lets you keep them if you switch, but check which response actions it can take through each one. Either way, make every provider state the platform, who owns the licenses, data and detections, and what happens at exit.
At a minimum: time from alert to analyst triage, time to notify you of a confirmed high-severity incident, time to start a pre-approved containment action, portal availability, and the response time when you call to report a suspected incident. For each one, define when the clock starts and stops, how it is measured and reported, and the service credit if it's missed. Mean-time figures in marketing material are not SLAs, so put the targets in the contract.
The example schedule in this template runs about 12 weeks from kickoff to contract award, including three weeks for provider responses and three to four weeks for a proof of value. Onboarding follows the award: agents and log sources are connected, detections are tuned, and the SLAs begin at an agreed go-live date. If you're replacing a current provider, plan an overlap so nothing goes unmonitored during the switch.
Paste-ready requirements for finding and securing service accounts, API keys, tokens, workload identities and AI agents, with vendor questions, a scoring rubric…
Paste-ready ZTNA requirements (per-app policy, device posture, agent and agentless access, connectors, VPN migration), vendor questions that separate products, and a weighted…
Paste-ready requirements for immutable backup storage and cyber recovery vaults (object lock, isolation, multi-person approval, clean-room recovery), vendor questions and a weighted…
Please provide your feedback below.
"*" indicates required fields