Selection Criteria Across Different Buyer Contexts
Choosing an MSP feels overwhelming because you’re evaluating something you may not fully understand. Providers use similar language, promise comparable outcomes, and present polished proposals that obscure meaningful differences. The vendors who seem most professional might be the best salespeople rather than the best operators. You need a framework that cuts through marketing to reveal actual capability and fit.
Three filtering principles before we diverge: Every legitimate MSP should provide written SLAs with specific response times, carry cyber liability insurance, and give you complete ownership of your documentation and data. These aren’t premium features. They’re baseline requirements. Any provider failing these basics isn’t worth further evaluation regardless of price or promises.
For the First-Time MSP Buyer
I’ve never hired an IT company before. What questions should I even be asking?
You know you need help but aren’t sure what good help looks like. The proposals you’ve received use technical jargon, reference certifications you don’t recognize, and quote prices you can’t contextualize. You need a translation layer that converts industry-speak into evaluation criteria you can actually apply.
The Questions That Actually Matter
Start with response time commitments. Ask specifically: “If our server goes down at 10 AM on a Tuesday, what happens?” A credible answer includes concrete timeframes. Critical issues should get human response within 15 minutes to 1 hour. Problems preventing individual employees from working should be addressed within 1 to 4 hours. Routine requests can wait 24 to 48 hours. If a provider can’t articulate specific commitments, they’re selling hope rather than service.
Ask about their monitoring approach. “What systems do you watch, and what happens when something looks wrong?” Good answers reference specific tools (RMM platforms), 24/7 automated monitoring, and defined escalation procedures. Vague answers about “keeping an eye on things” suggest reactive rather than proactive management.
Probe documentation ownership directly. “If we end this relationship, what do you hand over?” You should receive complete network documentation, all passwords and credentials, configuration records, and procedural documentation. Providers who hesitate or qualify this answer are building dependency, not partnership. Your environment belongs to you regardless of who manages it.
Ask about their own security. “Do you carry cyber liability insurance? Are you SOC 2 certified?” An MSP handling your systems becomes an attack vector into your business. Providers without their own security rigor will bring that sloppiness to your environment. SOC 2 Type II certification means their security practices have been independently audited. Insurance means they’ve been evaluated by underwriters who assess risk professionally.
Red Flags to Walk Away From
Reluctance to provide references signals problems. Established MSPs have satisfied clients willing to speak on their behalf. If a provider can’t connect you with three references in your size range and industry, either they’re too new to have track record or their existing clients aren’t happy enough to recommend them.
Contracts requiring long commitment before proving service quality suggest confidence problems. Quality providers offer 90-day pilots, month-to-month initial terms, or satisfaction guarantees. Those demanding 36-month commitments before you’ve experienced their work are prioritizing lock-in over earning your business.
Pricing dramatically below market raises questions. If comprehensive managed services typically cost $125 to $175 per user and someone quotes $60, they’re either cutting corners on service delivery, planning aggressive upselling, or building a client base to sell. Understand exactly what’s excluded before celebrating savings.
Resistance to written SLAs means accountability avoidance. Verbal promises about “great service” and “fast response” mean nothing without contractual commitment. If they won’t put response times in writing, they’re preserving flexibility to deprioritize you when convenient.
Building Your Evaluation Shortlist
Start with referrals from businesses similar to yours. Other companies in your industry, size range, or region have already done the research. Their recommendations come with built-in validation that no marketing can replicate.
Check certifications as quality signals. Microsoft Solutions Partner designation (the replacement for Gold/Silver levels) indicates technical competency verified by Microsoft. CompTIA Trustmark suggests commitment to industry standards. SOC 2 certification confirms security practices. None of these guarantee quality, but absence of any recognized credentials warrants scrutiny.
Evaluate proposals for specificity. Good proposals detail exactly what’s included, what triggers additional charges, and how service level will be measured. Vague proposals heavy on promises and light on particulars often deliver vague service.
Meet the people who’ll actually support you. Sales teams present well. The question is whether the technical staff matches. Request introduction to your account manager and lead technician before signing. Their competence and communication style preview your ongoing experience.
The best predictor of future service is current behavior. If they’re responsive, clear, and helpful during the sales process, that pattern usually continues. If getting answers feels like pulling teeth now, imagine needing urgent help at 11 PM.
Sources:
- SLA benchmarks: Gartner Peer Insights B2B Service Criteria
- Certification standards: MSPAlliance, CompTIA, Microsoft Partner Programs
- Evaluation frameworks: CIO.com Vendor Selection Guidelines
For the IT Manager Vetting Vendors
Leadership wants me to evaluate MSP options. How do I assess technical capability beyond the sales pitch?
You understand technology well enough to spot gaps in provider capabilities, but you’re evaluating companies from the outside. Sales teams present curated versions of reality. You need methods to penetrate the polish and assess whether a provider can actually deliver what your environment requires.
Technical Due Diligence Framework
Request their technology stack documentation. A mature MSP should immediately produce a list of tools they deploy: RMM platform, PSA system, security stack, backup solution, and documentation platform. If they can’t articulate their toolset clearly, operational maturity is questionable. Compare their stack against industry standards. Legitimate choices exist for each category, but outdated or obscure tools suggest underinvestment.
Ask about their security operations specifically. “Walk me through what happens when your monitoring detects a potential threat on a client endpoint.” Listen for process maturity: automated isolation, defined escalation paths, forensic capability, and communication protocols. Vague answers about “investigating and fixing it” suggest ad-hoc response rather than mature security operations.
Probe their escalation procedures. “What happens when a problem exceeds your first-tier technician’s capability?” Strong answers describe tiered support structures, clear escalation criteria, and access to specialized expertise. Weak answers suggest flat organizations where the same generalists handle everything regardless of complexity.
Request sample documentation from a sanitized client environment. How they document others predicts how they’ll document you. Look for completeness: network diagrams, asset inventories, configuration records, and procedural runbooks. If their documentation sample is thin, expect thin documentation of your environment.
Evaluating for Your Specific Environment
Map your technical requirements against their stated capabilities. If you run specialized applications, ask specifically about their experience supporting those platforms. If you have compliance requirements, verify they understand the specific controls required. Generic capability claims mean nothing without validation against your actual needs.
Assess their experience with your scale and complexity. An MSP excellent for 20-user single-office companies might struggle with your 80-user multi-location environment. Ask for references at comparable complexity. Request case studies of similar implementations. Experience transferability isn’t automatic.
Evaluate their project capability separately from ongoing support. Many MSPs handle break-fix well but lack capacity for significant projects like cloud migrations, infrastructure upgrades, or security implementations. If your roadmap includes major initiatives, verify project execution capability with specific examples and dedicated project resources.
Test their communication patterns during evaluation. How quickly do they respond to your questions? How clearly do they explain technical concepts? How proactively do they identify issues in your current environment? Evaluation behavior previews ongoing relationship dynamics.
The Technical Reference Check
When speaking with references, ask technical questions they can actually answer. “How long does it typically take them to resolve a critical issue?” “Have they ever missed an SLA commitment, and how did they handle it?” “What’s their biggest technical weakness?” “Would you hire them again knowing what you know now?”
Request permission to speak with a reference’s technical contact, not just executive sponsor. The IT manager at a current client sees daily operational reality that executives don’t. Their perspective reveals whether delivery matches sales promises.
Ask references about transition experience. “How did onboarding go? What problems emerged? How long until operations stabilized?” Every MSP transition has bumps. The question is how the provider handled them.
Sources:
- Technology stack standards: Gartner MSP Technology Infrastructure
- Security operations maturity: NIST Cybersecurity Framework
- Evaluation methodologies: ITIL Service Provider Assessment
For the Business Owner Who’s Been Burned
My last IT company was a disaster. How do I avoid repeating that mistake?
You’ve experienced what bad looks like. Maybe they disappeared during emergencies. Maybe they held your data hostage. Maybe they simply promised more than they delivered for months before you finally escaped. Your skepticism is earned. The question is how to channel it into effective evaluation rather than either trusting too quickly or never trusting at all.
Diagnosing What Went Wrong Before
Before evaluating new providers, understand specifically why the last relationship failed. Different failure modes require different screening.
If they couldn’t actually solve your problems, you had a capability mismatch. Screen for technical depth by asking detailed questions about your environment type. Request references from companies with similar technical requirements. Verify certifications relevant to your specific platforms.
If they were impossible to reach when you needed them, you had a service model problem. Demand specific SLAs with teeth. Ask about after-hours coverage and who actually provides it. Verify staffing levels relative to client count. Understand their triage process for competing priorities.
If they held your data or documentation hostage, you experienced predatory practices. Verify documentation ownership in writing before signing. Ensure contracts specify data portability requirements. Ask directly: “What happens to our credentials and documentation if we terminate?”
If they overpromised and underdelivered, you experienced sales-operations disconnect. Meet operational staff, not just sales. Ask references specifically about promise-versus-delivery alignment. Request service level reports from existing clients.
Trust Verification Processes
Background verification goes beyond references. Check how long they’ve been in business. Search for complaints with Better Business Bureau and industry forums. Verify their insurance is current. Confirm certifications directly with issuing bodies rather than trusting displayed logos.
Contract terms reveal priorities. Legitimate providers don’t need predatory terms. If termination clauses seem designed to trap you, if data ownership isn’t clearly yours, if pricing can change unilaterally, the contract itself signals relationship quality expectations.
Pilot periods test reality. Propose 90-day trial before full commitment. During pilot, deliberately test response times, escalation paths, and communication quality. Create scenarios that reveal capability: urgent requests, complex problems, and after-hours needs. A provider confident in their service welcomes verification.
Ask about their worst client experiences. “Tell me about a time a client relationship went badly. What happened? What did you learn?” Honest answers reveal self-awareness and improvement orientation. Defensive deflection or claims of universal satisfaction suggest either dishonesty or dangerous lack of reflection.
Protecting Yourself Contractually
Documentation ownership clause must explicitly state all network documentation, credentials, passwords, and configurations belong to you and will be transferred completely upon termination. No exceptions, no conditions, no fees for “knowledge transfer.”
Termination provisions should allow exit with reasonable notice (60 to 90 days) without punitive fees, especially after initial contract term. Providers requiring months of notice or charging remaining contract value as termination fee are building prison walls, not partnerships.
Service level guarantees should include consequences for non-performance. SLAs without remedies are aspirations, not commitments. Credits for missed response times, termination rights for repeated failures, and reporting requirements create accountability.
Data handling terms should specify your data location, their access limitations, their breach notification obligations, and their security practices. If they won’t commit these in writing, they haven’t thought carefully about their responsibilities.
The goal isn’t paranoid distrust. It’s informed protection. Quality providers don’t resist reasonable protections because they expect to meet commitments. Only those planning to underdeliver need contract terms that trap clients.
Sources:
- Contract best practices: Gartner Vendor Management Research
- Trust verification: MSPAlliance Provider Standards
- Protective clauses: CIO.com Outsourcing Contract Guide
For the Compliance-Driven Buyer
We have regulatory requirements. How do I verify an MSP can actually support our compliance needs?
Your industry has specific rules about data handling, security controls, and documentation. Non-compliance isn’t just risk. It’s potential fines, audit failures, and business continuity threats. You need an MSP who genuinely understands your regulatory environment, not one who claims compliance capability based on buzzword familiarity.
Verifying Actual Compliance Capability
Request their compliance documentation directly. A provider genuinely capable of supporting HIPAA, PCI-DSS, SOC 2, or other frameworks should produce relevant documentation immediately: their own compliance certifications, client implementation examples, and control mapping documents. Hesitation or vague promises to “figure it out together” reveal that compliance is marketing claim rather than operational reality.
Ask about Business Associate Agreements if you’re healthcare-adjacent. Any MSP accessing protected health information must sign a BAA accepting legal responsibility under HIPAA. If they hesitate, don’t understand what you’re asking, or want to negotiate BAA terms extensively, they haven’t done this before. Your organization cannot afford to be their learning experience.
Verify their understanding is specific, not generic. Ask them to explain the specific controls relevant to your compliance framework. “Walk me through how you’d address HIPAA’s technical safeguard requirements in our environment.” Generic answers about “taking security seriously” reveal surface familiarity. Specific answers about access controls, encryption requirements, audit logging, and breach notification procedures demonstrate genuine capability.
Request audit history if they claim relevant certifications. SOC 2 Type II reports cover specific time periods and can be shared with prospective clients under NDA. Ask for the most recent report. Verify the scope covers services relevant to your needs. Check for exceptions or qualifications that might affect your situation.
Industry-Specific Screening
For healthcare (HIPAA): Beyond BAA willingness, verify experience with healthcare-specific applications (EHR/EMR systems), understanding of minimum necessary standards, and breach notification procedures. Ask how many healthcare clients they currently serve. Request healthcare-specific references.
For financial services (SOC 2, PCI-DSS, state regulations): Verify experience with financial data handling, understanding of audit requirements, and ability to support examination preparation. Ask about their own financial services experience and whether they maintain PCI-DSS certification for their own operations.
For legal firms (client confidentiality, ethics rules): Verify understanding of attorney-client privilege implications for data handling, conflict checking procedures if they serve multiple law firms, and experience with legal practice management systems.
For government contractors (CMMC, FedRAMP requirements): Verify whether they maintain relevant government certifications for their own infrastructure. Understand their experience with CUI handling requirements. Ask about their security clearance procedures for staff accessing sensitive environments.
Compliance Cost Reality
Compliance-capable MSPs cost more than general providers. Healthcare-focused MSPs typically charge 20% to 30% premium over standard rates. This reflects real operational differences: additional security tools, compliance-specific training, audit preparation overhead, and liability exposure they accept.
Be skeptical of providers matching standard rates while claiming compliance capability. Either they’re absorbing cost they can’t sustain, or their “compliance support” is superficial. Neither scenario serves your interests.
Budget for compliance as ongoing requirement, not one-time project. Regulations evolve. Audit requirements change. Your compliance posture requires continuous attention, not initial setup followed by neglect. Ensure your provider’s engagement model includes regular compliance review, not just incident response.
Compliance isn’t a feature you add. It’s a capability you verify. The difference matters when auditors arrive.
Sources:
- HIPAA requirements: HHS.gov Technical Safeguard Standards
- SOC 2 framework: AICPA Trust Services Criteria
- Compliance verification: Gartner Regulatory Compliance Assessment
- Industry-specific requirements: CompTIA Industry Verticals Research
The Bottom Line
Selecting an MSP requires matching your specific situation to provider capability. First-time buyers need frameworks for asking the right questions and recognizing red flags. Technical evaluators need methods to verify capability beyond sales presentations. Those recovering from bad experiences need trust verification processes and contractual protections. Compliance-driven buyers need evidence of genuine regulatory capability, not marketing claims.
Across all contexts, certain principles hold. Written SLAs with specific commitments matter more than verbal assurances. Documentation ownership should be unambiguous and unconditional. References from similar organizations provide validation marketing can’t replicate. Pilot periods reveal operational reality before full commitment.
The right provider exists for your situation. Finding them requires asking harder questions than providers expect, verifying claims rather than trusting presentations, and protecting yourself contractually against the failure modes you most want to avoid.
Trust your skepticism while remaining open to genuine quality. Both excessive suspicion and excessive trust create problems. The goal is informed evaluation that identifies true fit, not cynicism that prevents progress or naivety that repeats past mistakes.