Most MSP RFPs fail before the first vendor reads them. They are either too vague - 'we need IT support' - or too prescriptive, specifying tooling that limits who can respond. A good RFP forces vendors to answer the same questions in a comparable format. Here is a template and the reasoning behind each section.
The Purpose of a Good RFP
A well-written RFP serves two purposes: it forces you to articulate your own requirements clearly, and it gives vendors enough context to price accurately. Vague RFPs produce vague proposals that collapse during scope negotiations. Specific RFPs attract vendors who actually understand your environment.
An RFP is not a binding document. It is an invitation for vendors to propose. Keep it structured but leave room for vendors to flag things you have not considered - a good MSP will surface gaps in your current environment as part of the response.
Section 1: Company Overview and Current State
Describe your business: industry, number of employees, number of locations, and a rough description of your IT environment. Include: number of workstations, servers (on-prem or cloud), primary line-of-business applications, current M365 or Google Workspace status, and your existing IT support model.
State honestly what is not working. Vendors need to understand whether you are starting from scratch, migrating from another MSP, or trying to supplement internal IT. Each scenario has a different onboarding cost and risk profile.
Section 2: Scope of Services Required
List what you need. Be specific: 24/7 helpdesk, endpoint management, patch management, security monitoring, backup and disaster recovery, M365 administration, network management, vendor management. Ask vendors to indicate whether each item is included, excluded, or available as an add-on.
Do not list tools. List outcomes. You want 'patch compliance above 95% within 72 hours of release' not 'must use Ninja RMM.' Tool selection is the MSP's domain. Outcome expectations are yours.
Section 3: Service Level Requirements
Define your SLA expectations: response time for critical incidents, resolution time targets, escalation paths, and after-hours coverage. Ask vendors to state their actual SLAs in writing - not marketing claims. Request sample reports showing historical SLA performance.
Ask specifically about escalation: who handles P1 incidents at 2am on a Sunday? Is that person on staff or contracted? Where are the technicians located? For BC businesses, timezone and physical proximity can matter.
Section 4: Security and Compliance Requirements
State any compliance requirements: BC PIPA, PIPEDA, CIS Controls, SOC 2, or industry-specific frameworks. Ask vendors to describe how they satisfy each requirement and request documentation. A vendor who cannot produce a security policy for their own operations is not going to manage yours well.
Ask about their own cyber insurance, their incident response procedure, and whether they have had a breach in the last three years. This is uncomfortable but necessary. You are trusting them with your environment.
Evaluating Responses
Score responses across four dimensions: scope coverage, SLA credibility, security posture, and price reasonableness. Do not pick the cheapest vendor unless they also score highest on the other three dimensions. The cost of a bad MSP relationship is measured in downtime, data loss, and staff frustration.
Request a reference from a BC business of similar size. Call the reference. Ask one question: 'Would you renew?' The answer tells you more than the proposal document.