How to choose a managed IT service provider: what to ask before you sign

Short answer: A good MSP shows you their answers to a handful of specific questions – SLA terms, after-hours response, tooling stack, industry experience, onboarding plan, outage handling, and out-of-scope work – in writing, before you sign anything. The cheapest provider is almost never the right one. The most polished sales process is not always the right one either. The right MSP is the one whose answers to the questions below are specific, written down, and survive a reference check with their existing clients.

This is the buyer’s checklist. Twelve questions every SMB should ask before signing a managed IT services agreement, what good answers look like, what the red flags sound like, and what to verify after the conversation. Use this whether you are picking your first MSP, switching from another provider, or evaluating an upgrade from a break-fix arrangement.

What good MSP evaluation looks like

Before getting to the questions, two framing notes that change how you read every answer:

Get answers in writing. Sales calls are good for vibe-checks. They are bad for committing scope. Anything that ends up mattering – SLAs, scope, exclusions, pricing structure, term, out clauses – should appear in the written proposal or contract. “We will totally cover that” said on a call does not bind anyone. “Section 4.2 covers that” does.

Score answers on specificity, not enthusiasm. A confident “yes, we handle that” with no follow-up detail is worth less than a “here is exactly how we handle it, here is the documented process, here is how it shows up in your reports.” Specificity correlates strongly with operational maturity. Vagueness correlates strongly with surprises later.

With that in mind, the twelve questions.

1. What is your response time SLA, and what is your resolution time SLA?

These are different. Response time is how long until someone acknowledges your ticket. Resolution time is how long until the issue is actually fixed. Many MSPs commit to response and stay vague about resolution, which lets them mark a ticket “responded to” while the user waits days for a fix. (For the deeper primer on how SLAs actually work, see what is an SLA and why it matters for your IT support.)

Good answer: “Our response SLA is 15 minutes for critical, 1 hour for high priority, 4 hours for normal. Our target resolution times are 4 hours for critical, 1 business day for high priority, 3 business days for normal. Here is how each priority is defined. Here is what happens when we miss an SLA.”

Red flag: Response SLA only, no resolution commitment. Or SLA “targets” with no penalty or accountability when missed. Or vague priority definitions that let the MSP downgrade your ticket to a tier with looser SLAs.

Verify: Ask to see SLA performance from the last quarter for similarly-sized clients. A real MSP tracks this and can show you the numbers.

2. How do you handle after-hours and weekend incidents?

The 2am ransomware call is when MSP quality matters most. Standard managed IT engagements include after-hours response for high-severity incidents only – true 24/7 helpdesk is a premium add. The question is what counts as a high-severity incident and how fast someone actually responds.

Good answer: “After-hours, our on-call team responds to critical incidents within X minutes. Critical means [specific definitions – ransomware indicators, full M365 outage, server down, account compromise]. Non-critical issues wait until business hours. Our 24/7 SOC monitors EDR and email security alerts continuously and pages on-call engineers automatically when patterns indicate a real incident.”

Red flag: “We have an on-call rotation” with no specific response time. Or after-hours coverage that is really just “the owner’s cell phone.” Or after-hours support gated behind an extra fee that was not in the proposal.

Verify: Ask what their last after-hours incident looked like – when did it page, who responded, how long until containment. A specific recent example beats any abstract promise.

3. What tooling do you use, and is it included?

The MSP’s tooling stack determines what they can actually do. RMM, MDM, EDR, email security, ticketing, monitoring, backup – each tool is either included in their per-user fee or it is not. If it is not, you are either paying for it separately or going without. (For what RMM actually does, why it is the backbone of proactive managed IT, and what to ask about it specifically, see the RMM primer.)

Good answer: A specific named stack. “We use Ninja for RMM, Intune for MDM, SentinelOne for EDR, Mimecast for email security, [PSA tool] for ticketing, Veeam for backup. All tooling is included in the per-user fee. Here is what each tool does and what visibility you get into it.”

Red flag: Vague answers about tooling. “We use industry-leading tools” is not an answer. Or tooling that is provided but not actually deployed – “we have EDR available” but the rollout requires a separate project.

Verify: Ask whether the tooling is deployed during onboarding or sold to you as a separate project. The answer determines whether the per-user fee in the proposal is the real cost or just the starting cost. The pricing breakdown for managed IT services covers what is normally bundled vs billed separately.

4. Do you have experience in our industry, and what does that look like?

For most SMBs, industry experience is a nice-to-have. For regulated businesses (healthcare, legal, financial services, defense contractors), it is closer to a requirement. The question is whether the MSP knows your specific compliance landscape, the typical line-of-business apps in your industry, and the regulatory expectations you operate under.

Good answer: “We have X clients in your industry. The compliance frameworks we routinely handle are [HIPAA, SOC 2, PCI, CMMC]. Common applications we support in your space are [specific apps]. Here are 2-3 reference clients in your industry you can speak with.”

Red flag: “We work with everyone.” That is a generalist MSP positioning itself as a vertical specialist – red flag for industries where vertical experience matters. Or industry experience that turns out to be a single client they onboarded six months ago.

Verify: Reference calls with same-industry clients. Ask the references whether the MSP understood industry-specific requirements without being taught. (For the full vertical-vs-generalist MSP decision – when specialization actually matters and when a strong generalist is equivalent or better – see the comparison guide.)

5. What does onboarding look like, in detail?

Onboarding is where the MSP relationship is built or broken. A real onboarding takes 30-90 days, produces documentation, deploys tooling, sets a security baseline, and resolves the gaps the MSP found during discovery. A bad onboarding is a portal login and a phone number. (For the full week-by-week breakdown of what good onboarding actually looks like, see what to expect in the first 90 days of MSP onboarding.)

Good answer: A defined plan with phases, deliverables, and a timeline. “Week 1-2: discovery, asset inventory, account audit. Week 3-4: tooling deployment (RMM, EDR, email security, backup). Week 5-6: security baseline (MFA enforcement, conditional access, patch policy). Week 7-8: documentation, runbooks, ticketing handover. Week 9-12: shadow period where we run alongside your existing setup. Day 90: full handover to managed operations.”

Red flag: No defined onboarding process, or onboarding that is “we will get you set up in the first week.” That timeframe is too short to do real work. Or onboarding that is bundled into the monthly fee with no clear scope – the MSP will cut corners to keep their internal labor costs down.

Verify: Ask for a sample onboarding plan from a similar-sized client. Ask what onboarding deliverables look like. A real MSP has templates.

6. How do you handle a major outage or security incident?

When your CRM is down or you are watching ransomware encrypt your file server, the MSP’s incident response process is the only thing that matters. The question is whether they have one or whether they figure it out as they go.

Good answer: A documented incident response procedure. “For security incidents we follow a defined runbook: detect, contain, eradicate, recover, document. We have a dedicated incident response lead. Communication during incidents goes through a single channel. We provide post-incident reports within 5 business days.”

Red flag: “We have lots of experience with this” is not a process. Or a process that exists in someone’s head but is not written down. Or no clear escalation path from helpdesk to incident response.

Verify: Ask to see a redacted incident report from a previous client engagement. The structure of that document tells you everything about their operational maturity.

7. What is not included in the contract?

Possibly the most important question on this list. Every MSP contract has scope boundaries. The dangerous contracts are the ones that do not name them clearly. You will eventually need something that is out of scope, and how the MSP handles that conversation is what defines the relationship. (The exclusions section is one of the eight sections every managed IT services agreement should contain – if it is missing or vague, the contract is not finished.)

Good answer: A specific exclusions list. “Out of scope work includes: major infrastructure deployments, compliance certifications, custom development, on-site visits beyond X hours per quarter, line-of-business application support, and 24/7 helpdesk above the included tier. Out of scope work is billed at $X/hour or scoped as a project.”

Red flag: “We handle everything.” Nobody handles everything. Either the MSP is hedging the truth (and you will discover the limits the hard way) or the MSP genuinely tries to handle everything and is therefore terrible at the things that need specialty depth. Both outcomes are bad.

Verify: Walk through your most likely “what about…” scenarios with the MSP and ask whether each one is in scope, out of scope, or project work. The clarity of those answers predicts the friction in the relationship.

8. What are the contract terms – length, termination, and renewal?

The legal scaffolding around the engagement matters. A fair MSP contract is structured to protect both parties. An unfair one is structured to lock you in.

Good answer: Clearly stated term length (often 1-3 years), termination clauses for cause and for convenience, notice period for non-renewal (30-90 days), and a defined exit process for transferring data and access to a new provider.

Red flag: Auto-renewal with a 90+ day notice window that is easy to miss. Or termination only “for cause” with vague definitions of cause. Or no exit process – you sign up and you are stuck if it does not work out.

Verify: Ask explicitly: “If we decide to leave in 12 months, what happens? What do you provide us, and what do you charge for the transition?” The answer should be specific and reasonable. (If you are already planning to leave your current MSP, the switching playbook covers what to audit before giving notice.)

9. How do you handle data ownership and access during and after the contract?

Critical question that most buyers skip. Your data, accounts, documentation, and tooling configurations belong to your business. The MSP holds them. What happens at the end of the relationship determines whether you can leave cleanly.

Good answer: “All data, documentation, and configurations are yours. On termination, we provide complete documentation, transfer admin access on whatever schedule you specify, and remove our tooling agents on a defined timeline. You retain all account ownership. We do not hold anything hostage.”

Red flag: Documentation owned by the MSP. Tooling that is “leased” rather than included (which means it disappears when the contract ends). Admin access that the MSP retains and the client never gets back. Custom integrations or scripts that the MSP wrote but does not transfer.

Verify: Ask to see the data transition section of the contract before you sign. If it is not there, get it added.

10. How do you handle pricing changes over time?

MSP costs are not fixed forever. Your headcount changes. Tooling costs go up. The MSP’s underlying labor costs change. The question is how that translates into your bill – and that depends in part on which pricing model the MSP uses (per-user, per-device, flat tiered, or all-inclusive).

Good answer: “Per-user pricing scales with your headcount automatically. We give 60-90 days notice on any rate change and rate changes are tied to specific triggers (annual renewal, scope change, regulatory shift). Our last rate change was X% in [year], driven by [specific reason].”

Red flag: Open-ended ability to change pricing with short notice. Or pricing structures that look attractive at signing but escalate based on consumption metrics that are hard to predict.

Verify: Ask what the average annual increase has been for existing clients over the past 3 years. A specific number indicates an MSP that thinks about pricing transparently.

11. What does your security posture look like?

You are about to give an MSP administrative access to your most critical systems. They are a high-value target for attackers because compromising one MSP gives access to many businesses. Their security posture is your security posture.

Good answer: “We are SOC 2 Type 2 certified [or working toward it]. We have cyber insurance with $X coverage. We use EDR, MFA, and conditional access on our own infrastructure. We do not allow personal devices. We have an incident response plan and a documented breach notification procedure for clients. We perform internal penetration testing annually.”

Red flag: “We take security seriously” without specifics. No SOC 2 or equivalent certification. No cyber insurance, or insurance with low coverage limits. Sloppy security practices observable in the sales process (insecure email handling, unsigned documents, public file shares).

Verify: Ask for their SOC 2 Type 2 report or attestation. Ask whether their incident response plan covers client notification and what the timeline is.

12. Can we speak with three reference clients?

References are the highest-signal part of the evaluation. The MSP will hand you their happiest clients. Ask the right questions and you still learn a lot.

Good answer: Three clients of similar size and industry, willing to take a 30-minute call. Bonus if one of them is a former client who left on good terms.

Red flag: Reluctance to provide references. Or references who are obviously coached and stick to talking points. Or only one reference, or references in industries radically different from yours.

Reference call questions worth asking:

• How long has the relationship been? Why did you choose this MSP originally?
• Walk me through a recent incident – how did the MSP handle it?
• What is the worst thing about working with this MSP?
• Have they ever missed an SLA, and how was it handled?
• If you had to pick the MSP again today, would you?
• What surprised you, good or bad, after the contract started?

The “worst thing” and “surprised you” questions are where the real signal is. A reference who genuinely enjoys working with the MSP will still answer those questions honestly. A coached or fake reference will deflect.

Bonus: questions to ask yourself before the calls

The questions above are for the MSP. There are also questions for your own organization that affect which MSP is right for you:

What does our environment actually look like? A complete inventory – users, devices, locations, key applications, sensitive data, current tooling, current security gaps. The MSP cannot scope accurately if you cannot describe accurately. If you have never had a network assessment, commissioning one before the MSP evaluation usually pays back fast – it turns “we want better IT” into a specific findings list both sides can quote against.

What are we trying to fix? “We want better IT” is not a goal. “We want fewer outages, better security posture, predictable cost, and someone to call when our M365 admin gets stuck” is a goal. Specificity helps both sides.

What is our budget range? Not the exact number, but the range. The MSP cannot help you scope a $50K/year engagement if they are pricing $150K/year service. Tell them what you are working with.

Who internally will own this relationship? MSP relationships need an internal owner. If nobody owns it, you will not get the strategic value out of the engagement, and the MSP will gradually drift toward the path of least resistance. Pick the owner before signing.

What is our exit plan if it does not work? Not because it will fail, but because thinking through the exit before you commit forces you to negotiate the right contract terms. A relationship you can leave cleanly is a relationship that performs better.

What good MSPs do during the sales process

The sales experience itself is data. A few things that distinguish good MSPs:

They want to do discovery before quoting. A 30-60 minute call is not enough to scope managed IT for a 50-person business. A real MSP wants to see your environment – asset inventory, M365 admin center, network diagram, current tooling – before they put a number in writing.

They name what they do not do. A confident MSP will tell you which problems they are not the right answer for. Pure compliance specialists will tell you they are not the right MSP for general IT. Generalist MSPs will tell you when a specialist is a better fit. Honesty in scope is a strong positive signal.

They show you the contract early. A good MSP gives you the actual contract template before you commit, not after. This signals that the contract is fair enough that they are comfortable showing it to a prospect.

They follow up in writing. If they tell you something on a call, it should appear in the proposal. If it does not, ask for it. The proposal is what you will be holding them to in 12 months, not the conversation.

They do not use high-pressure tactics. Limited-time pricing, urgent decision deadlines, and “this offer expires Friday” language are all sales pressure designed to short-circuit due diligence. A good MSP knows they will be a 3-5 year relationship and acts accordingly.

Red flags worth walking away from

Some sales-process red flags are bad enough that they should end the evaluation immediately:

• Quoting without discovery. Anyone who quotes managed IT for a 50-person business off a 20-minute call is selling you a number, not a service.
• No SLA or vague SLAs. Without measurable commitments, you have no recourse when service degrades.
• Reluctance to provide references. This is the single highest-signal red flag.
• No SOC 2 or similar attestation. For an MSP that will have admin access to your environment, this is increasingly table stakes.
• Heavy upsell pressure. If the pre-sales conversation is dominated by which add-ons you should buy, the MSP is selling, not advising.
• Their own security looks bad. Insecure email, public Google Docs sales materials, no MFA visible on the team’s accounts. If they cannot run their own security, they cannot run yours.
• Negative or evasive answers about exit terms. A relationship designed to be hard to leave is a relationship that will not need to compete to keep you.
• Pricing that looks too good. Below the standard SMB MSP range almost always means something is missing from the scope.

After the calls: how to compare quotes

You will probably end up with 2-4 proposals. Comparing them by headline price alone is a mistake. The relevant comparison is total scope at total cost.

Build a scope matrix. List every service you need (helpdesk, EDR, email security, M365 admin, backup, MFA, monitoring, patching, documentation, QBRs, etc.) down the left column. Each MSP gets a column. Mark each cell as “included,” “add-on,” or “not offered.” This makes apples-to-apples comparison possible.

Calculate the all-in cost. Per-user fee plus tooling licensing plus onboarding plus typical project work for a year. Cheap MSPs often have low headline rates and high real costs once you add the line items.

Weight intangibles deliberately. Cultural fit, communication style, response speed during sales, how they handled awkward questions. These predict what the relationship will feel like in month 18.

Trust your discomfort. If something felt off during the sales process, it will feel worse after you sign. Sales is the MSP putting their best foot forward. Operations is the steady-state.

The right MSP usually does not have the lowest price, the flashiest deck, or the smoothest sales process. It is the one whose answers were specific, whose contract was fair, whose references checked out, and whose scope matches what you actually need.

How Sequentur thinks about the evaluation process

Sequentur is a security-first MSP / MSSP for small and mid-sized businesses across the 15-to-250-employee range, including both general SMBs and regulated industries like healthcare, legal, financial services, and defense contractors. Our standard managed engagement covers the full operational layer – helpdesk, endpoint management, patching, M365 administration, backup operations, EDR, email security, and MFA enforcement – and our security tier adds 24/7 MDR monitoring, conditional access governance, and compliance documentation maintenance.

In our sales process we lead with discovery. For small or straightforward environments, a single call is sometimes enough to scope and quote. For larger or more complex environments – multiple locations, on-prem servers, regulated industries, custom apps – we want to understand what your environment actually looks like, what is working today, where the gaps are, and what your business is trying to accomplish before we put numbers in writing. Either way, we are happy to walk you through our SLA terms, our exclusions list, our incident response process, our SOC 2 status, and our reference clients. If we are not the right MSP for your business, we will tell you so during the evaluation rather than after you sign.

If you are evaluating MSPs and want to put us through this list of questions, schedule a call. Bring the questions above. We will answer them in writing as part of the proposal.