A managed security services contract is mostly decided by what the request for proposal forgot to write down: which devices are in scope, who approves a firewall change at midnight, which provider accounts hold administrator rights in your tenants, and whether your logs and configurations come back when the contract ends. This template is a ready-to-issue request for proposal for a managed security service provider (MSSP) running a mix of managed firewall and network security, log monitoring, vulnerability scanning, endpoint tooling and compliance reporting. It gives numbered requirements that can each be verified and scored, a responsibility matrix, service level definitions, a scoring model, a proof of value script and a pricing schedule. It is vendor-neutral and written for security leaders, IT managers and procurement panels. For how the MSSP market works and how to shortlist, read the Managed Security Service Provider Buyers Guide; if you are buying a detection-led service only, use the MDR Service RFP Template instead.
How to use this template
- Replace text in square brackets, such as [Organisation], [number] and [firewall platform], with your own details. Delete service towers you are not buying.
- Each requirement has an ID (for example MSS-FW-03) and a type: M mandatory (pass or fail), S scored (0 to 5, weighted) or I informational.
- Service level targets, weights and volumes in brackets are illustrative, not market benchmarks. Set them before issue and do not change them after responses arrive.
- Complete the responsibility matrix in section 4 internally before issue. Anything not in a schedule is not in the service.
- Issue sections 1 to 12 to bidders. The Evaluation method and Implementation guidance sections are for your panel only.
1. Purpose and scope
[Organisation] invites proposals for managed security services covering the service towers below, operated by the provider under service levels, with [Organisation] retaining ownership of risk decisions, data and configurations.
- Service towers in scope: [A. managed firewall, VPN and web security]; [B. log collection and security monitoring]; [C. vulnerability scanning and patch reporting]; [D. endpoint security tool management]; [E. email security management]; [F. compliance reporting].
- Out of scope: [incident response beyond initial containment, unless bid as an option]; [penetration testing]; [general IT support].
- Drivers: [no in-house capacity]; [audit or insurance requirement]; [regulatory obligation, for example NIS2, DORA or PCI DSS]; [consolidation of several providers].
- Contract term: [three] years with a [12-month] break clause.
2. Organisation background and current state
| Item | [Organisation] value |
|---|---|
| Network security estate | [number and model of firewalls]; [VPN or ZTNA]; [web proxy]; [sites] |
| Endpoints and servers | [number] Windows, [number] macOS, [number] Linux; [EDR platform] |
| Identity and SaaS | [Active Directory, Entra ID, Okta]; [Microsoft 365 or Google Workspace]; [number] users |
| Log sources and platform | [SIEM in use or "bidder to supply"]; [number] sources; daily volume [GB] |
| Vulnerability management | [scanner in use]; [number] scanned assets; current patch process |
| Current providers | [existing MSSP or MSP, contract end date, transition constraints] |
| 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]; presentations and proof of value [dates]; decision [date].
- Single point of contact: [name, email].
- Answers: for each requirement state whether it is included in the base price, an add-on (price it), delivered by a subcontractor (name it) or not offered.
- Delivery model: name the operations centres, their hours and locations, staffing per shift, and every subprocessor and tool that will touch [Organisation] data.
- Samples: include a redacted monthly service report, a change record, a security incident notification and a vulnerability report.
4. Responsibility matrix
R = responsible, A = accountable, C = consulted, I = informed. Bidders confirm they can operate this matrix and mark any line they would change.
| Activity | Provider | [Organisation] |
|---|---|---|
| Firewall rule changes (standard) | R | A (approves through [change process]) |
| Emergency block of malicious indicator | R, A within pre-approved scope | I |
| Firmware and signature updates on managed devices | R | A for maintenance windows |
| Security monitoring and alert triage | R | I, C on severity 1 |
| Decision to declare an incident | C | A |
| Vulnerability scanning and reporting | R | I |
| Applying patches to servers and endpoints | [R or C] | [A] |
| Regulatory notification | C (supplies facts) | A, R |
| Access reviews of provider accounts | C | A, R |
5. Tower A: managed firewall, VPN and web security
| ID | Requirement | Type |
|---|---|---|
| MSS-FW-01 | Manages [firewall platform] and [VPN or ZTNA] configuration, signatures and firmware, applying vendor security updates for critical vulnerabilities within [14 days] of release, or within [48 hours] for vulnerabilities in CISA's Known Exploited Vulnerabilities catalogue on internet-facing devices. | M |
| MSS-FW-02 | All changes go through [Organisation]'s change process with a record of requester, approver, implementer, time and rollback steps; emergency changes are reviewed within [one business day]. | M |
| MSS-FW-03 | Rule base review every [six months]: unused, shadowed, overly permissive and expired rules reported with recommendations. | S |
| MSS-FW-04 | Configuration backups after every change, stored under [Organisation]'s control, with version history. | M |
| MSS-FW-05 | Management interfaces are not exposed to the internet; provider access comes from named source addresses through [Organisation]'s privileged access route. | M |
6. Tower B: log collection and security monitoring
| ID | Requirement | Type |
|---|---|---|
| MSS-MON-01 | Collects and monitors the log sources in Annex [X], including firewalls, identity provider sign-in and audit logs, endpoint security alerts, email security and cloud control plane logs. | M |
| MSS-MON-02 | Monitoring [24x7] by the provider's analysts; state which hours, if any, rely on automation only. | M |
| MSS-MON-03 | Detection content mapped to MITRE ATT&CK, reviewed [quarterly] with [Organisation], with custom use cases for [named business systems]. | S |
| MSS-MON-04 | Reports silent log sources within [4 hours] and coverage against the agreed source list daily. | M |
| MSS-MON-05 | Retains logs for [12 months] online and [further period] archived, stored in [region], searchable by [Organisation] at any time. | M |
| MSS-MON-06 | Pre-approved containment actions (block indicator, disable account, isolate endpoint) as set out in section 4, with every action logged and reversible. | S |
7. Towers C to F: vulnerability, endpoint, email and compliance
| ID | Requirement | Type |
|---|---|---|
| MSS-VUL-01 | Authenticated vulnerability scanning of [number] internal assets [weekly] and external attack surface [continuously or weekly], with results prioritised by exploitability, including CISA KEV status. | M |
| MSS-VUL-02 | Tracks remediation against [Organisation]'s deadlines and exception process and reports overdue items by owner. | S |
| MSS-EDR-01 | Manages [EDR platform] policy, agent health and exclusions; exclusions require [Organisation] approval and are reviewed [quarterly]. | S |
| MSS-EML-01 | Manages [email security platform] policies, quarantine release and SPF, DKIM and DMARC monitoring. | S |
| MSS-CMP-01 | Produces evidence packs for [ISO/IEC 27001, PCI DSS, Cyber Essentials, NIS2] audits from service records. | S |
For the remediation deadlines referenced in MSS-VUL-02, see the Remediation SLAs and Vulnerability Exceptions Guide.
8. Service levels
Ask bidders to define when each clock starts and stops, and how it is evidenced. An automated email is not a response.
| Measure | Definition | Target | Service credit |
|---|---|---|---|
| Time to notify (severity 1) | Alert to analyst phone call to [Organisation] contact | [30 minutes] | [%] |
| Time to triage (severity 2) | Alert to analyst investigating | [1 hour] | [%] |
| Emergency change | Approved request to change implemented | [2 hours] | [%] |
| Standard change | Approved request to change implemented | [3 business days] | [%] |
| Device restore | Managed device failure to service restored | [4 hours] | [%] |
| Log source gap | Source silent to [Organisation] notified | [4 hours] | [%] |
| Portal availability | Monthly uptime of portal and APIs | [99.5%] | [%] |
| ID | Requirement | Type |
|---|---|---|
| MSS-SLA-01 | Service levels measured from system timestamps [Organisation] can audit, reported monthly, credits applied without a claim. | M |
| MSS-SLA-02 | Monthly service report and quarterly service review with trends, open risks and improvement plan; named service manager. | M |
9. Security of the provider and its access
An MSSP holds administrative access to your firewalls, logs and often your identity provider and SaaS tenants. Its people, tools and application identities are a direct route into your estate.
| ID | Requirement | Type |
|---|---|---|
| MSS-SEC-01 | Every provider person with access is named, uses an individual account with phishing-resistant MFA, and is removed within [24 hours] of leaving the account. No shared or generic administrator accounts. | M |
| MSS-SEC-02 | List every service account, API key, OAuth or multi-tenant application, agent and remote support tool the service installs or registers in [Organisation]'s environment, with its permissions; [Organisation] can rotate or revoke each without provider action. | M |
| MSS-SEC-03 | Provider access is least privilege by tower, time-bound for administrative tasks where the platform supports it, and logged in [Organisation]'s own logs. | M |
| MSS-SEC-04 | Describe how the provider's own management platforms (remote monitoring and management, PSA, SIEM, jump hosts) are segregated per customer and protected, including MFA, patching and monitoring. | S |
| MSS-SEC-05 | Current independent assurance: ISO/IEC 27001 certificate or SOC 2 Type 2 report whose scope covers the service, and [Cyber Essentials Plus, if UK]; staff vetting policy; security incident history for three years. | M |
| MSS-SEC-06 | Notifies [Organisation] within [24 hours] of any security incident at the provider or a subprocessor that could affect [Organisation]. | M |
| MSS-SEC-07 | Data protection terms as a processor, subprocessor list, transfer mechanisms and data residency in [region]. | M |
The NCSC's guidance on choosing an MSP describes Cyber Essentials Plus as the UK government's minimum baseline, treats ISO 27001 or SOC 2 as signs of maturity, and expects 2-step verification on all MSP access points, including the provider's access to your systems. It also expects the contract to say whether the provider will tell you about incidents it suffers itself, which MSS-SEC-06 covers.
MSS-SEC-02 matters because provider application identities can bypass user MFA entirely. In the ConnectWise Cloud Backup breach, a stolen credential for a provider's multi-tenant application was used to sign in to more than 160 customer Microsoft 365 tenants with no user involved. See also the MSP Security Questionnaire Template.
10. Transition in
| ID | Requirement | Type |
|---|---|---|
| MSS-TRN-01 | Transition plan with phases, named roles, dependencies on [Organisation] and the outgoing provider, and acceptance criteria per tower. | M |
| MSS-TRN-02 | Baseline assessment of each managed device and log source in the first [60 days], reporting misconfigurations found. | S |
| MSS-TRN-03 | Runbooks for each tower written with [Organisation] and approved before service go-live. | S |
11. Exit
| ID | Requirement | Type |
|---|---|---|
| MSS-EXT-01 | At exit, delivers device configurations, rule documentation, logs held, detection content, runbooks and asset records in documented formats within [30 days] at no extra charge. | M |
| MSS-EXT-02 | Provides [90 days] of transition support in parallel with an incoming provider or [Organisation]'s own team. | S |
| MSS-EXT-03 | Removes all accounts, agents, applications and keys, hands over all administrator credentials for managed devices, and certifies deletion of [Organisation] data. | M |
| MSS-EXT-04 | States which licences (firewall subscriptions, SIEM, EDR) are held in the provider's name and whether they can be transferred. | S |
12. Pricing schedule
| Line | Basis | Year 1 | Year 2 | Year 3 |
|---|---|---|---|---|
| Tower A: managed firewall, VPN, web security | [per device, per site] | [ ] | [ ] | [ ] |
| Tower B: monitoring | [per log source, per GB, per user] | [ ] | [ ] | [ ] |
| Towers C to F | [per asset, per user] | [ ] | [ ] | [ ] |
| Tooling licences supplied by provider | [itemised] | [ ] | [ ] | [ ] |
| Transition | [fixed] | [ ] | n/a | n/a |
| Change requests beyond included volume | [per change or day rate; included volume per month] | [ ] | [ ] | [ ] |
| Growth of [20%] | [ ] | [ ] | [ ] | [ ] |
Bidders state renewal price caps, the price at the break clause and any minimum commitments. The NCSC notes that faster response times are likely to raise contract cost, so price each service level option separately where you are undecided between, for example, a one-hour and a four-hour severity 2 target.
Evaluation method and proof of value
| Criterion | Weight | Evidence |
|---|---|---|
| Service tower capability (sections 5 to 7) | [30%] | Response, samples, proof of value |
| Service levels and governance (sections 4 and 8) | [15%] | Response, references |
| Provider security and access model (section 9) | [20%] | Assurance reports, access list, interview |
| Transition and exit (sections 10 and 11) | [10%] | Plan, contract review |
| Three-year cost (section 12) | [25%] | Pricing schedule at expected volumes |
Scores use 0 to 5: 0 not met; 1 offered only at unpriced extra cost; 3 met; 5 met and demonstrated. A failed mandatory requirement excludes the bid. Shortlisted bidders take part in a proof of value of [30 days] that covers at minimum:
- Onboarding: connect [five] log sources and [one] firewall in read-only mode and receive the first coverage report.
- Detection test: agreed, authorised test activity (a sign-in from an unusual location to a test account, a blocked connection to a test indicator, a test mailbox forwarding rule); record time to triage and notify against section 8.
- Change test: submit a standard and an emergency firewall change request out of hours; check the record and the approval route.
- Access review: the bidder lists every account and application it created during the trial; [Organisation] compares this with its own logs.
- Reporting: review the trial service report and vulnerability report for accuracy and usefulness.
- Clean up: the bidder removes all access, and [Organisation] confirms in its own logs that nothing remains.
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Follow a supply chain method: the NCSC groups its supply chain security principles into four stages: understand the risks, establish control, check your arrangements, and continuous improvement. This RFP covers the first two; quarterly reviews and the access reconciliation below cover the rest.
- Write the responsibility matrix first: disputes after signature are nearly always about patching, change approval and who declares an incident.
- Treat the provider as third-party privileged access: MSS-SEC-01 to MSS-SEC-03 put provider identities and integrations under your governance. See the Vendor Privileged Access Management (VPAM) Guide.
- Prepare for provider compromise: agree how you would cut provider access in an hour, and rehearse it. See the Compromised MSP Playbook.
- Measure after go-live: service level attainment by tower; percentage of in-scope log sources reporting; KEV vulnerabilities on managed devices past deadline; emergency changes as a share of all changes; provider accounts and applications reconciled at each quarterly access review.
Common failure patterns
- Scope by tool name: "managed SIEM" without a log source list and use cases produces alert forwarding by email.
- Provider identities outside your governance: shared administrator accounts and multi-tenant applications nobody on your side can list or revoke.
- Firmware lag on edge devices: internet-facing firewalls and VPNs patched on a monthly cycle while their vulnerabilities are being exploited within days.
- Licences in the provider's name: exit becomes a re-procurement of every subscription.
- Price-led scoring: weighting cost above provider security selects the provider with the least control over its own access.
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| Monitoring (6) | SI-4, AU-6 | DE.CM-01, DE.AE-02 |
| Change and patching (5, 7) | CM-3, SI-2, RA-5 | ID.RA-01 |
| Provider access (9) | AC-2, AC-6, AC-17 | PR.AA-05 |
| Supplier, contract and exit (9 to 12) | SA-4, SA-9, SR-6 | GV.SC-05, GV.SC-07, GV.SC-10 |
The threat these controls address is described in MITRE ATT&CK T1199 Trusted Relationship.
Standards and references
- NCSC: Choosing a Managed Service Provider (MSP)
- NCSC: Supply Chain Security Guidance
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- CISA: Known Exploited Vulnerabilities Catalog
- MITRE ATT&CK: T1199 Trusted Relationship
Related NHI Mgmt Group resources: Managed Security Service Provider Buyers Guide · Cybersecurity for MSPs and MSSPs Guide · MDR Service RFP Template · MSP Security Questionnaire Template · Security Vendor Evaluation and RFP Guide