Most managed detection and response contracts fail on the questions nobody asked at tender: who may isolate a server at 3am, how fast a human actually looks at an alert, and whether you can take your data and detections with you when you leave. This template is a ready-to-issue request for proposal for an MDR service, with numbered requirements that can each be verified and scored. It covers coverage hours and telemetry, detection, response authority, service levels, analyst access, reporting, the security of the provider itself, and exit terms, with mandatory and scored criteria, a weighted model and a proof of value plan. It is vendor-neutral and written for security leaders, SOC managers and procurement panels. For how the MDR market works and what to look for, read the MDR Buyer's Guide; this page is the procurement document.
How to use this template
- Replace text in square brackets, such as [Organisation], [EDR platform] and [number], with your own details. Delete requirements that do not apply.
- Each requirement has an ID (for example MDR-RSP-03) and a type: M mandatory (pass or fail), S scored (0 to 5, weighted) or I informational.
- Service level values, weights and volumes in brackets are illustrative, not market benchmarks. Set them from your own risk appetite before issue and do not change them after responses arrive.
- Issue sections 1 to 10 to bidders. The Implementation guidance section is for your evaluation panel only.
- Write the response authority matrix in section 6 with your incident response owner and legal team before issue; it is the part of the contract you will rely on during an incident.
1. Purpose and scope
[Organisation] invites proposals for a managed detection and response service that monitors [Organisation]'s environment continuously, investigates and triages threats, takes agreed containment actions, and supports incident response and recovery.
- In scope: [endpoints and servers]; [Microsoft 365 or Google Workspace]; [identity providers]; [cloud accounts in named providers]; [network and firewall telemetry]; [SaaS applications]; [OT, if any].
- Out of scope: [vulnerability scanning]; [penetration testing]; [full digital forensics and incident response retainer, unless bid as an option].
- Drivers: [no 24x7 coverage]; [alert backlog]; [cyber insurance requirement]; [regulatory obligation, for example NIS2 or DORA].
- Contract term: [three] years with a [12-month] break clause.
2. Organisation background and current state
| Item | [Organisation] value |
|---|
| Endpoints and servers | [number] Windows, [number] macOS, [number] Linux; [EDR platform in use or "bidder to supply"] |
| Identity | [Active Directory, Entra ID, Okta]; [number] users; [number] privileged accounts |
| Cloud and SaaS | [providers and number of accounts]; [key SaaS] |
| Log platform | [SIEM in use / none]; current daily ingest [GB] |
| Current security team | [number] staff, [hours covered]; [existing incident response retainer] |
| Sites and time zones | [locations] |
| Regulatory context | [GDPR, NIS2, DORA, PCI DSS, sector rules]; data residency [requirement] |
3. Instructions to bidders
- Timeline: RFP issued [date]; clarifications by [date]; responses due [date, time, time zone]; proof of value [dates]; decision [date].
- Single point of contact: [name, email].
- Answers: state for each requirement whether it is included in the base price, an add-on (price it), delivered by a subcontractor (name it), or not offered.
- Delivery locations: list every location from which analysts will access [Organisation] data, and every subprocessor.
- Sample deliverables: include a redacted incident report, a monthly service report and a sample runbook.
4. Coverage and telemetry
| ID | Requirement | Type |
|---|
| MDR-COV-01 | Monitoring and response 24 hours a day, 365 days a year, by the bidder's own analysts; state staffing per shift and whether any shift is subcontracted or automated only. | M |
| MDR-COV-02 | Supports [Organisation]'s existing [EDR platform] and [SIEM] without requiring replacement; or supplies and manages them (state which and price separately). | M |
| MDR-COV-03 | Ingests and investigates identity telemetry ([Entra ID sign-in and audit logs, Okta System Log, Active Directory events]) and cloud control plane logs, not endpoint only. | S |
| MDR-COV-04 | Ingests [Microsoft 365 or Google Workspace] email and collaboration events, including mailbox rule changes and OAuth application consents. | S |
| MDR-COV-05 | Reports telemetry health daily: assets not reporting, log sources silent for more than [4 hours], and coverage against the agreed asset list. | M |
| MDR-COV-06 | Retains raw telemetry for [12 months] and investigation records for [contract term plus 1 year]; states where data is stored. | S |
The NCSC's SOC guidance treats deciding which log sources a SOC receives as a design task in its own right. Agree the onboarding list before contract, not after.
5. Detection and investigation
| ID | Requirement | Type |
|---|
| MDR-DET-01 | Detection coverage mapped to MITRE ATT&CK techniques for the in-scope platforms, with the mapping provided and kept current. | S |
| MDR-DET-02 | Custom detections for [Organisation]'s high-value assets and business processes, written with [Organisation] and reviewed [quarterly]. | S |
| MDR-DET-03 | Proactive, hypothesis-led threat hunting at least [monthly], with findings reported even when nothing is found. | S |
| MDR-DET-04 | Identity-centred investigation: correlates endpoint, identity, email and cloud activity for the same user, service account or application. | S |
| MDR-DET-05 | Describe where AI or automation is used in triage, how its decisions are checked by analysts, and whether [Organisation] data is used to train models. | M |
| MDR-DET-06 | Threat intelligence relevant to [Organisation]'s sector, with emerging threat notifications and retrospective searches when new indicators are published. | S |
See the ITDR RFP Template if identity detection is being bought separately, so the two do not overlap.
6. Response authority
Define in advance what the provider may do without asking. Bidders confirm they can operate this matrix and state any action they cannot perform.
| Action | Standard assets | Critical assets [list] | Privileged and service accounts |
|---|
| Isolate endpoint from network | [Pre-approved] | [Call [on-call role], act if no answer in 15 minutes] | n/a |
| Kill process, quarantine file | [Pre-approved] | [Pre-approved] | n/a |
| Disable user account, revoke sessions and tokens | [Pre-approved] | [Pre-approved] | [Approval required] |
| Reset password, require MFA re-registration | [Pre-approved] | [Pre-approved] | [Approval required] |
| Disable service principal or rotate credential | [Approval required] | [Approval required] | [Approval required] |
| Block indicator at firewall, email or proxy | [Pre-approved] | [Pre-approved] | n/a |
| ID | Requirement | Type |
|---|
| MDR-RSP-01 | Performs the pre-approved actions above within the response time in section 7, and records every action with analyst name, time, reason and reversal steps. | M |
| MDR-RSP-02 | Escalates by phone to the [Organisation] contact list for severity 1 and 2 incidents, with documented escalation if contacts do not answer. | M |
| MDR-RSP-03 | Containment for identity and cloud: revoke refresh tokens and sessions, disable accounts in [identity providers], remove malicious mailbox rules and OAuth grants. | S |
| MDR-RSP-04 | Incident response for confirmed incidents: included hours per year [number], scope (remote, on site), and rates beyond that; whether a separate retainer is required. | S |
| MDR-RSP-05 | Supports [Organisation]'s regulatory notification timelines (for example GDPR Article 33's 72 hours) by providing incident facts within [24 hours] of confirmation. | M |
| MDR-RSP-06 | Preserves evidence (triage images, logs, timelines) in a forensically sound way and hands it over on request. | S |
7. Service levels
Ask bidders to define each measure precisely: when the clock starts, when it stops, and how it is reported. Vague terms such as "response" can mean an automated email.
| Measure | Definition | Target | Service credit |
|---|
| Time to triage (severity 1) | Alert generated to analyst actively investigating | [15 minutes] | [%] |
| Time to notify (severity 1) | Analyst confirmation to [Organisation] contacted by phone | [30 minutes] | [%] |
| Time to contain (pre-approved actions) | Confirmation to containment action completed | [60 minutes] | [%] |
| Time to triage (severity 3 and 4) | Alert to investigation started | [4 hours] / [next business day] | [%] |
| Telemetry gap notification | Log source or agent silent to [Organisation] notified | [4 hours] | [%] |
| Portal availability | Monthly uptime of customer portal and APIs | [99.5%] | [%] |
| ID | Requirement | Type |
|---|
| MDR-SLA-01 | Service levels are measured from system timestamps [Organisation] can audit, reported monthly, with credits applied automatically. | M |
| MDR-SLA-02 | Severity definitions are agreed with [Organisation] and can be changed by mutual agreement without a contract amendment. | S |
8. Analyst access, reporting and governance
| ID | Requirement | Type |
|---|
| MDR-ACC-01 | [Organisation] staff can talk directly to analysts handling an incident (chat, phone, bridge) at any hour, not only through tickets. | M |
| MDR-ACC-02 | A named service manager and a named technical lead for the account. | S |
| MDR-ACC-03 | Portal and API access for [Organisation] to see all alerts, investigations, actions taken and raw evidence, including alerts closed as benign. | M |
| MDR-REP-01 | Monthly report: alerts by severity, true and false positive rates, service level performance, actions taken, coverage gaps and recommendations. | M |
| MDR-REP-02 | Quarterly service review with trend analysis and detection changes; annual tabletop exercise with [Organisation]. | S |
| MDR-REP-03 | Post-incident report within [5 business days] of closure, with timeline, root cause and recommendations. | S |
9. Security of the provider
An MDR provider holds remote response rights over your estate. Its own identities are a direct path into yours.
| ID | Requirement | Type |
|---|
| MDR-SEC-01 | Every provider identity with access to [Organisation] systems is named, uses phishing-resistant MFA, and is removed within [24 hours] of the analyst leaving the account. No shared accounts. | M |
| MDR-SEC-02 | List every API key, service principal, OAuth application and agent the service needs in [Organisation]'s tenants, with permissions, and support rotation and revocation by [Organisation]. | M |
| MDR-SEC-03 | Current independent assurance report (for example SOC 2 Type 2 or ISO/IEC 27001 certificate with scope covering the service), staff vetting policy and security incident history for three years. | M |
| MDR-SEC-04 | Notifies [Organisation] within [24 hours] of any security incident at the provider that could affect [Organisation]. | M |
| MDR-SEC-05 | Data protection terms as a processor, including subprocessors, transfer mechanisms and data residency in [region]. | M |
See the How to Read a SOC 2 Report Guide for MDR-SEC-03.
10. Exit terms and commercials
| ID | Requirement | Type |
|---|
| MDR-EXT-01 | At exit, delivers all telemetry held, investigation records, custom detections and runbooks in documented formats within [30 days], at no extra charge. | M |
| MDR-EXT-02 | Provides [90 days] of transition support in parallel with an incoming provider. | S |
| MDR-EXT-03 | Removes all agents, accounts, keys and integrations and certifies deletion of [Organisation] data. | M |
| MDR-EXT-04 | Where the provider supplies the EDR or SIEM licence, states whether [Organisation] can keep or transfer it at exit. | S |
- Price basis: per endpoint, per user, per GB of ingest or fixed fee; how servers, cloud workloads and identities are counted.
- Included and extra: incident response hours, threat hunting, onboarding, tooling licences.
- Growth and renewal: price for [20%] growth, renewal cap, and price at the break clause.
Evaluation method and proof of value
| Criterion | Weight | Evidence |
|---|
| Detection and investigation quality (sections 4 and 5) | [30%] | Proof of value, sample reports |
| Response authority and service levels (sections 6 and 7) | [25%] | Response, proof of value timings |
| Analyst access and reporting (section 8) | [10%] | Proof of value, references |
| Provider security and exit (sections 9 and 10) | [15%] | Assurance reports, contract review |
| Life-cycle cost | [20%] | Section 10 |
Scores use 0 to 5: 0 not met; 1 offered only at extra cost not priced; 3 met; 5 met and demonstrated. The proof of value runs for [30] days on [a representative subset of production] and covers at minimum:
- Onboarding: time to full telemetry for the agreed subset and the first telemetry health report.
- Authorised adversary emulation, agreed in writing, across endpoint, identity and email (for example a test user consenting to a test OAuth application and a test mailbox forwarding rule); record time to triage, notify and contain against section 7.
- An out-of-hours test escalation to check MDR-RSP-02 and MDR-ACC-01.
- Quality review: [Organisation] analysts score three investigation write-ups for accuracy and usefulness.
- Export test: retrieve raw data and investigation records through the API (MDR-ACC-03, MDR-EXT-01).
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Agree response authority internally first: the matrix in section 6 needs sign-off from IT operations, business owners of critical systems and legal. Without it, providers default to "notify only" and containment waits for you.
- Test service levels, do not read them: an emulated incident at 2am on a weekend tells you more than any SLA table.
- Treat provider access as third-party privileged access: MDR-SEC-01 and MDR-SEC-02 put provider identities and integrations under your governance. See the Vendor Privileged Access Management (VPAM) Guide.
- Keep ownership of detections and data: MDR-EXT-01 avoids lock-in; check the contract wording matches the RFP answer.
- Measure after go-live: track mean time to triage and contain for severity 1 and 2; percentage of in-scope assets reporting; true positive rate; number of incidents found by hunting; and actions taken without waiting for [Organisation].
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|
| Coverage and detection (4, 5) | SI-4, AU-6 | DE.CM-01, DE.AE-02 |
| Response authority and incident handling (6) | IR-4, IR-4(1), IR-8 | RS.MA-01 |
| Notification and reporting (6, 8) | IR-6 | RS.CO-02 |
| Provider security, contract and exit (9, 10) | SA-4, SA-9 | GV.SC-05, GV.SC-10 |
Standards and references
Related NHI Mgmt Group resources: MDR Buyer's Guide · MDR Guide · Co-Managed SOC and SOC-as-a-Service Guide · Security Vendor Evaluation and RFP Guide · ITDR RFP Template