How to Choose an MSP: A Buyer's Scorecard and Checklist

The most popular advice on how to choose an MSP is to collect three quotes, compare the per-user price, confirm the provider offers 24/7 support, and sign with whoever lands in the middle. That process reliably produces the most expensive contract you will ever sign. It measures the one number a vendor can discount without changing anything, and it ignores the two things that decide whether the relationship works: whether the provider can prove outcomes, and whether you can walk away.

Treat an MSP as a resilience purchase with a reversible structure. You need a requirements document written before anyone pitches, a weighted scorecard that scores price last, a three-year total cost model instead of a monthly fee, and an exit test you run before you sign. Here's the version I'd hand a CTO who wants to get this right once.

How to Document Requirements Before Vendor Calls

Requirements written after the first vendor call are the vendor's requirements, not yours. Write the page first, then send it.

The case for that discipline is financial. Uptime Institute's 2024 Global Data Center Survey, which collected responses from more than 850 data-center owners and operators plus more than 750 vendors and consultants, found that 53% of operators had experienced an outage during the previous three years. Frequency is improving, down from 78% in 2020 and 60% in 2022. Cost is not. 54% said their most recent significant outage cost more than $100,000, and roughly one in five put it above $1 million. You are buying a reduction in both probability and consequence, so your document has to record both.

Six steps, in order.

1. Write the business outcomes in plain words. Faster deployments, fewer incidents, lower cloud spend, a clean SOC 2 audit in March. Attach a number or a threshold to each one, because an unmeasured outcome becomes an argument in month eight. If you can't quantify it, impose a ceiling instead: no more than one severity-one incident per quarter.
2. Map in-scope services and critical systems. Identity first, then backup, cloud, endpoints and network, then whatever runs the business, such as the ERP, the warehouse system or the billing platform. A provider that runs your help desk but not your identity provider is not managing your risk.
3. Record regulatory duties, data sensitivity and where data sits. Name the frameworks you answer to, the retention rules, the residency limits and who is allowed to touch production data.
4. Set operating hours, time zones and after-hours needs. A support line staffed in your time zone at 7am beats a 24/7 badge answered from a queue eight hours away.
5. Write the escalation path for the worst day. Named roles, phone numbers and tiers, down to who wakes up the account director when the second hour passes with no restore.
6. Set the transition deadline and convert everything into measurable service-level requirements. Separate what a system must do from how reliably it must do it, which is the same split you apply to functional and nonfunctional requirements in any build.

The test that sets your recovery targets: write down what a four-hour outage at 2pm on a Tuesday costs your business in revenue, payroll and missed commitments. That figure, not a vendor's default, is what your restore targets should be built around.

Finish with a one-page brief you can send to three providers at once. Same brief, same questions, same scoring, which is the only way the answers become comparable.

A Weighted Scorecard for Comparing MSPs

Price is the weakest signal in the room. It's the only number a provider can cut without changing staffing, tooling or process, and it's the number most buyers rank first. Score everything else before commercial terms and the cheap quote loses on its own merits.

ISACA's MSP selection guidance recommends evaluating technical skills and competencies first, using qualitative and quantitative performance metrics, and tailoring criteria to your own risk profile rather than applying a uniform checklist. It proposes a weighted scorecard: security and resilience 30%, technical capability 25%, service performance 20%, transition capability 15% and commercial fit 10%.

ISACA's guidance also cites Deloitte's finding that 44% of surveyed companies found vendors lacked the capabilities needed to achieve expected quality and cost savings. That is the failure mode a weighted scorecard exists to catch, because capability gaps don't show up in a demo. They show up in year two.

Score the evidence, not the language

A 4 on security means a current SOC 2 Type II report you have read, an incident-response runbook you have skimmed, and backup-restore test results with dates on them. Not a slide. ISACA's guidance is explicit that buyers should require evidence rather than assertions, including certifications, staffing coverage, sample reports and a proof-of-capability exercise. Building that evidence filter is the core of any vendor selection criteria exercise, and it's the step most buyers skip.

Three habits make the grid work. Have two evaluators score separately and reconcile differences before the group discussion, because the first person to speak anchors everyone else. Put the weights inside the RFP so vendors know how they will be judged and stop padding the parts that score nothing. And set a floor of 3 on security and resilience so a weak posture cannot be rescued by a discount.

Here's how the weights bite. Say a low-cost provider scores 2 for security, 3 for technical capability, 3 for performance, 2 for transition and 5 on commercial fit. Weighted, that's 2.75 out of 5, and its only strength is worth 10% of the decision. A provider scoring 5, 4, 4, 4 and 2 lands at 4.1 and wins despite charging more. Rank three finalists on the same grid and treat any total below 3.0 as a sourcing problem, not a scoring problem. Go back and find better candidates.

Source Candidates and Test Technical Fit

Stop collecting a long list. KPMG's global managed-services survey conducted with HFS Research found that in 2024 process expertise was the top reason for choosing a managed services provider at 26%, followed by industry expertise at 24%. Buyers are picking people who have solved the problem before, so source for that and skip the rest.

1. Start with six to eight names and cut hard. Peer referrals, your incumbent software vendors, industry associations. Cut to three that match your stack, geography, operating hours and regulatory scope, and write one sentence per provider explaining why it survived. If you can't write the sentence, it doesn't belong in the RFP.
2. Send the same RFP to all three. Require every proposed control and SLA to map to a stated business outcome, name every assumption, and disclose every subcontractor in the delivery chain.
3. Demand evidence of this environment, not a generic demo. Ask for an architecture review of your actual estate, named engineers with current certifications, a current SOC 2 Type II or ISO 27001 report, a sample incident report with root cause, and written IP assignment and NDA terms. Probe their disaster recovery planning with the last restore test they ran, not the policy document.
4. Call two clients who weren't on the vendor's reference sheet. Ask what broke in year two and who fixed it. Reference sheets are curated. Year-two stories are not.

How we shortlist suppliers: we check each one for proven experience in the same problem and technology, using references the client chooses, and we look for written IP assignment, NDAs and security evidence such as SOC 2 or ISO 27001 where it matters. Then we bring the client the best three options that fit, with our reasoning written down, and the client talks to those suppliers directly and picks.

A provider that cannot name its engineers or hand over a real incident report should not reach the pricing stage. Save the live proof exercise for the pilot, where you can score what you observed rather than what a solutions architect rehearsed.

Compare SLAs and Three-Year Total Cost

An uptime percentage and a response time are the two numbers providers most like to publish, and the two that prove least. A provider can hit every response target on the contract while restoring nothing, because acknowledging a ticket and ending an outage are different jobs.

Ask for raw 12-month SLA reports and read the priority-one restoration figures. Then put every proposal against the same baseline.

Normalize the money before you compare it

Give every vendor the same service matrix and demand a three-year total cost model: migration, licensing, cloud pass-through charges, monitoring tools, backup retention, overages, professional services and exit assistance. A per-device quote means nothing until those lines are in the same columns. If you want a reference point for what the market charges before you build the model, these typical MSP monthly fees show the range you're negotiating inside.

A cheaper per-device quote routinely costs more once exclusions and rate-card work land on the invoice. Keep an internal owner on the contract, because the IT department outsourcing decision fails most often when nobody inside the company still reads the reports.

Ask for outcome metrics, not ticket throughput

Request the numbers that show resilience moved: mean time to restore critical services, successful backup-restore tests, change-failure rate, recurring-incident reduction, vulnerability-remediation age and documented hours of downtime avoided. Two or three of those, tracked monthly, tell you more than a dashboard of ticket counts.

Generic 24/7 support with no severity definitions, no maintenance windows, no reporting cadence and no service credits is not an SLA. It's a slogan. A higher fee is justified only when the provider backs it with auditable outcome data and remedies that cost them something.

Test How Easily You Could Leave

Picture a 40-person firm whose MSP holds global administrator rights on its email, cloud tenant and firewall. Three years in, the firm wants to switch and discovers the runbooks live only inside the provider's support portal. Nothing is broken. Everything is stuck.

That's the risk the monthly fee hides. Privileged access to identity, cloud, backup, endpoint and security systems makes technical dependency far more consequential than price. The UK National Cyber Security Centre guidance on choosing an MSP says a contract should define renewal, renegotiation, termination, roles, responsibilities and liabilities. Use it as a checklist rather than a document you file. New York's Department of Financial Services takes the same line from the other direction, assessing third-party providers by system access, data sensitivity, location and service criticality.

Demand these terms in writing before award.

• Provider-neutral ownership of credentials, configurations, documentation, monitoring data and runbooks, sitting in your tenant and your repository.
• A usable export format, tested on real data rather than promised in an appendix.
• Named transition personnel and a defined handover window, so offboarding isn't a queue ticket.
• A pre-agreed offboarding rate and timeline, priced at signing, not negotiated during a dispute.
• Caps on renewal increases and exit charges, because your infrastructure, geography or compliance obligations may change before a multiyear term ends.

Four tests you can run before signing. Request a sample data export and open the file. Read one week of administrative-access logs and check whether every entry has a business reason. List every subcontractor who touches your systems. Then hand the documentation package to a second qualified provider and ask whether they could take over from it alone.

The best MSP is not the one with the broadest bundle. It's the one that makes replacement feasible, which is exactly why its documentation is clean, its access is logged and its exit terms are boring. Ask the final question in the final meeting, out loud: what exactly happens in the first 30 days after termination? A vague answer is your answer.

Run a Paid Pilot Before You Commit

Sign a 60 to 90 day pilot on one non-critical site, team or workflow before anyone commits to a multi-year term. Paid, scoped and measured, because free pilots get free effort.

Set pass criteria before it starts, drawn from your own scorecard: the minimum security and resilience score, the restore times from the severity table, and response quality judged on real tickets you watched move.

• Technical pass: one restore you initiated and verified, with the documentation the provider supplied.
• Operational pass: P1 and P2 response times hit on actual incidents during the pilot.
• Human pass: the named account contact answered when things went wrong, not the sales lead.

Run a go or no-go review at the end with the same evaluators who scored the proposals, and write down the reasons either way. If the pilot is only partly successful, take a 12-month term with clear exit clauses rather than a three-year lock-in, and treat the renewal as a second decision. Keep your own copy of every document produced during the pilot, and test one restore yourself instead of trusting the provider's report.

The right MSP is the one whose evidence holds up in a live pilot, not the one with the best proposal deck.

---

If you want to spend your evaluation weeks scoring three credible providers instead of screening twenty, TekRecruiter runs an MSP and outsourcing search on the same evidence standard this article sets out, checking each supplier on team, references, IP, security and contract terms before you see a name. We bring you the best three options that fit your stack, budget and requirements, with our reasoning written down, and you talk to those suppliers directly and choose. It costs the same as going to them yourself, and often less.