Questions to Ask an MSP Before You Sign: A Small Business Owner’s Checklist

Table of Contents

Most managed IT contracts are signed after one or two sales calls, a proposal review, and a gut check. That process works fine when the provider is good. When they are not, you typically find out three months in, locked into a one or two year agreement with no clear way out. That’s why we put together this checklist of Questions to ask an MSP before you sign.

The questions below are not meant to be asked all at once in a single call. They are meant to be spread across your evaluation process and used as a scoring tool. A provider who answers every question clearly and specifically is demonstrating how they operate. One who hedges, deflects, or gives you vague assurances is also demonstrating how they operate.

Print this out. Keep it open during calls. Write down the actual answers. The pattern across those answers will tell you more than any proposal document.

For context on how to structure the full evaluation process, see our guide on how to choose a managed IT provider. This post is the companion piece: the specific questions to use once you are in those conversations.

About Their Service Model

“What exactly is included in your base monthly fee, and what triggers a separate invoice?”

This is the single most important question. Vague answers here produce billing disputes later. A good provider gives you a written list of inclusions and exclusions without being asked twice.

Good answer: A specific list. Help desk support (unlimited or with a defined cap). Monitoring. Patch management. Backup monitoring. Security tools by name. Clear statement of what counts as a project and gets scoped separately.

Red flag: “We cover everything you need” or “most things are included.” That language means nothing and will cost you money.

“Is your help desk support unlimited or capped? And what counts as a help desk request versus a billable project?”

Many plans advertise “unlimited support” but define project work broadly enough that routine requests end up as separate invoices. You need both answers, not just one.

Good answer: A specific hour cap if there is one, or a clear statement that support is genuinely unlimited. A concrete example of what qualifies as a project versus a support ticket.

Red flag: Reluctance to define the boundary, or an unusually long list of things that count as projects.

“Do you offer on-site support, and if so, is it included or billed separately?”

Remote-only providers cost less but are not the right fit for every business. If your team regularly needs someone physically present for hardware installs, server issues, or network changes, that needs to be in the contract before you sign.

Good answer: Clear statement of whether on-site is included, how it is scheduled, and what response time looks like for on-site visits in Toronto.

Red flag: On-site described as available but with no clear process or pricing for when you actually need it.

“What does your pricing model look like: per user, per device, or something else? And how are those terms defined?”

Per user and per device are not the same thing. If your employees use multiple devices, a per-device contract can cost significantly more than it appears. You need to know exactly how you will be billed before you agree to the rate.

Good answer: A clear explanation of the billing unit with a concrete example. If per user, does one user with three devices count as one or three? For more context on how different pricing models compare, see our managed IT services pricing guide for Toronto businesses.

Red flag: Pricing defined in a way that is open to interpretation. That ambiguity resolves in their favour.

About Their Team and Operations

“How many clients does each technician on your team support?”

This question reveals capacity. A technician managing 50 client environments cannot give any of them meaningful attention. There is no universal right number, but the answer tells you whether your account will be a priority or a queue item.

Good answer: A specific ratio with an explanation of how workload is managed across the team. Acknowledgement that the ratio affects response quality.

Red flag: Reluctance to answer, or a ratio that seems implausibly low without explanation.

“Where is your support staff based, and who actually picks up the phone when we call after hours?”

Some providers advertise 24/7 support but route after-hours calls to an offshore help desk with no knowledge of your environment. The location question is not about geography for its own sake. It is about whether the person answering your call can actually resolve your issue.

Good answer: A specific answer about where support staff are located, what their level of access is after hours, and what happens to issues that require escalation.

Red flag: “We have 24/7 support” without a clear description of who provides it and what they can actually do versus what gets logged for the next business day.

“Who is my primary point of contact, and what happens to our account knowledge if that person leaves?”

Institutional knowledge about your environment walking out the door when a technician leaves is one of the most common frustrations in managed IT relationships. A well-run provider documents everything in a system, not in someone’s head.

Good answer: A named account manager or team lead with a clear process for knowledge documentation. Confirmation that your environment configuration is stored in their platform, not with an individual.

Red flag: “You will work with whoever is available” or any answer that suggests your account context lives with one person.

About Their Security Stack

“What specific security tools are included in your standard service? List them by name.”

“Cybersecurity is included” is not an answer. Ask them to name every tool: the antivirus or endpoint detection and response platform, the email filtering product, the backup solution, the MFA enforcement tool, the dark web monitoring service. Each of those is a different product with a different price and capability level.

Good answer: A specific list with product names and a brief explanation of what each one does. Confirmation of whether these are included at the base rate or require an upgrade.

Red flag: Generic language about “enterprise-grade security” or “comprehensive protection” without naming a single product.

Explore Xoomler’s Cybersecurity Services

“Do you enforce multi-factor authentication across all accounts and systems, or is it optional for users?”

MFA that is optional gets turned off. Cyber insurers in 2026 require mandatory MFA enforcement as a condition of coverage. A provider who offers it as optional is not meeting insurer requirements and is creating a security gap your policy may not cover.

Good answer: MFA is enforced, not optional. Specific explanation of how enforcement is implemented across Microsoft 365, VPN, remote access tools, and any other relevant systems.

Red flag: “We recommend MFA and can help set it up.” Recommending is not enforcing.

“What is the difference between the antivirus you include and endpoint detection and response (EDR)? Which do you provide?”

Many providers still include basic antivirus in their standard tier and offer EDR as an upgrade. These are fundamentally different capabilities. Antivirus catches known malware based on signatures. EDR monitors behaviour in real time and can catch threats antivirus misses. Ask which one is in the base package.

Good answer: A clear explanation of the difference and a specific statement about which is included. If EDR is an upgrade, what is the cost?

Red flag: Conflating antivirus and EDR, or using them as interchangeable terms. That suggests the person selling to you does not understand the products they are selling.

“Does your service keep us compliant with current cyber insurance requirements? And can you document that?”

Cyber insurers now verify controls at renewal. MFA, EDR, tested backups, patch management, and documented incident response are the most commonly required controls in 2026. A provider who cannot confirm their service meets these requirements may be leaving you exposed when your policy renews.

Good answer: Yes, with a specific list of controls they maintain and confirmation that they can provide documentation for an insurer.

Red flag: Uncertainty about what insurers require, or a statement that compliance is the client’s responsibility.

“If a serious security incident happens at 11pm on a Tuesday, what exactly happens? Who do we call, and what do you do in the first hour?”

The incident response question cuts through marketing language faster than almost anything else. Providers with a real process can describe it specifically. Providers without one will give you a vague reassurance.

Good answer: A specific answer: emergency contact number, response time commitment for critical incidents, who is available after hours, what the first steps of containment look like, and how they communicate with you during an active incident.

Red flag: “We take security incidents very seriously” or any answer that does not describe a specific process with specific people.

Monitor with charts with annual data analysis on screen. Computer showing diagram and graph used for financial investment on desk in empty office. Analytics research report in space, Questions to Ask an MSP

About Reporting and Accountability

“What is in your monthly report, and can you show me an example?”

Monthly reporting is the accountability mechanism for the entire relationship. If a provider cannot describe what is in their report, they either do not produce a meaningful one or have something to hide. Ask to see a real example, with client details removed.

Good answer: A specific description: patch compliance status, backup job results, security alerts and how they were handled, help desk ticket summary, any outstanding issues and recommended actions. A willingness to show you an anonymised example.

Red flag: A report described as a “summary of activity” with no specifics, or a provider who does not produce monthly reports at all.

Do you operate with SLAs or SLOs, and what is the difference in practice for us as a client?”

Most providers will say SLA without thinking twice. It is worth understanding what you are actually getting.

An SLA (Service Level Agreement) is a contractual commitment, typically minimum thresholds written into your contract with consequences if they are breached. An SLO (Service Level Objective) is an internal performance target the provider sets for themselves, usually more ambitious than the contractual floor and used to drive continuous improvement rather than just avoid penalties.

A provider who only has SLAs is telling you they manage to the minimum. One who also tracks SLOs is telling you they are trying to improve.

Good answer: A clear explanation of both, with specific numbers for each. For example, the SLA might commit to a four-hour response on critical issues. The internal SLO might target 30 minutes. Ask which number they actually hit in practice, and whether that performance data appears in your monthly report.

Red flag: Using SLA and SLO interchangeably, or a blank look at the distinction. Either suggests the provider has not thought seriously about their own performance standards. Also watch for SLA commitments that are written so loosely that they are nearly impossible to breach regardless of actual service quality.

“How do you track and report on your own response time performance? Do you measure against your SLA commitments?”

This is the accountability question most buyers skip. Any provider can write response time commitments into a contract. A provider who actively measures and reports their own performance against those commitments is operating transparently. One who does not measure it has no way to know whether they are meeting it.

Good answer: A specific tool or process for tracking ticket response and resolution times, with confirmation that this data appears in client reporting.

Red flag: “We always respond quickly” without any measurement to back it up.

About Compliance and Industry Experience

“How many clients do you currently support in my industry, and what specific compliance requirements have you helped them meet?”

General IT competence and industry-specific competence are different things. A provider who has never worked with a Toronto healthcare clinic will not know what PHIPA requires of cloud storage configurations. A provider who has never worked with a law firm will not understand the implications of legal privilege for remote access tools.

Good answer: Specific client examples (even anonymised), named compliance frameworks they have experience with (PHIPA, PIPEDA, Law Society requirements, CRA obligations), and an offer to connect you with a reference in your industry.

Red flag: “We work with businesses of all kinds” or vague references to healthcare and legal without any specific experience described.

“If we handle personal health information or sensitive client data, how does your service address our obligations under PHIPA or PIPEDA?”

This question is specifically for Toronto businesses in regulated industries. Healthcare clinics, legal firms, accounting practices, and financial services businesses all have specific data handling obligations that affect how an MSP must configure and manage their environment. A generalist provider who has not thought about this will not give you a useful answer.

Good answer: Specific knowledge of the relevant legislation, how their service configuration addresses it, and whether they can provide documentation for a regulatory review.

Red flag: “We follow best practices for data security.” That is not an answer to a compliance question.

About the Contract

“What is the contract length and what are the cancellation terms?”

Most Toronto MSP contracts run one to three years. Know the length before you sign and understand what happens if you want to leave early. Some contracts include significant termination fees. Others include no exit at all outside of documented service failures.

Good answer: Clear statement of contract length, notice period for cancellation, and any early termination fees. A provider confident in their service will not pressure you into a long commitment before you have seen what they can do.

Red flag: Pressure to sign a multi-year contract before you have had any meaningful experience with the provider.

“Is there an auto-renewal clause, and what is the notice window to prevent it?”

Many managed IT contracts automatically renew for a full additional term if you do not provide written notice within a specific window, often 60 to 90 days before the renewal date. Missing that window is one of the most common reasons businesses get locked into contracts they wanted to leave.

Good answer: Clear confirmation of whether auto-renewal exists, the exact notice period, and what form the notice must take (written, email, certified mail).

Red flag: Any contract term that is vague about the renewal process or the notice requirement.

“Who owns our environment documentation, passwords, and network diagrams if we decide to leave?”

Your configuration files, admin credentials, network diagrams, and system documentation belong to your business. Some providers treat this documentation as their own and use it as leverage when a client wants to switch. Get explicit ownership language in the contract before you sign.

Good answer: Clear statement that all documentation belongs to the client, with a description of how it is stored and what the off-boarding process looks like.

Red flag: Vague language about documentation, or a provider who becomes defensive when you raise the question.

“What does the off-boarding process look like if we switch providers in the future?”

This question is worth asking even if you have no intention of leaving. The answer tells you how the provider views the relationship. One who has a clear, professional off-boarding process is confident in their service quality. One who makes the question uncomfortable has structured the relationship to make leaving difficult.

Good answer: A clear description of how access is transferred, how documentation is handed over, and what the transition timeline looks like. For more on what a well-managed switch involves, see our guide to how to switch IT providers without downtime.

Red flag: Reluctance to discuss it, vague references to “working something out,” or a contract with no clear off-boarding obligations.

About Onboarding

“Walk me through exactly what happens in the first 30 days after we sign.”

Onboarding sets the foundation for everything that follows. A provider who has done this many times has a clear process. One who is improvising will give you a general description with no specifics.

Good answer: A week-by-week breakdown: environment assessment, documentation, monitoring agent deployment, security tool installation, staff introduction to the help desk, and a baseline report at the end of 30 days.

Red flag: “We will get you set up and take it from there.” That is not a process. That is a gap dressed up as flexibility.

“Will you do a full assessment of our current environment before finalising the contract?”

A responsible provider will not send a final quote without understanding what they are taking on. The assessment, sometimes called a network audit or discovery review, identifies what exists, what is missing, what is at risk, and what the scope of ongoing management actually looks like. Skipping it means the quote is a guess.

Good answer: Yes, the assessment happens before the contract is finalised. Description of what the assessment covers and how long it takes.

Red flag: A provider who sends a final contract without ever reviewing your environment. They are pricing something they have not looked at.

The Question That Reveals the Most

“What types of businesses are not a good fit for your service?”

This question is the most revealing one on the list. Every provider has a sweet spot: a business size, an industry, a complexity level where they do their best work. A provider who can honestly tell you who they are not right for is a provider who knows themselves.

One who claims to be the right fit for everyone, from five-person startups to 500-person enterprises, across every industry, at every complexity level, is either not being honest or is spread too thin to serve any of them well.

Good answer: A specific and honest description of the business profile they serve best, and a candid acknowledgement of where they are not the strongest fit.

Red flag: “We work with businesses of all sizes and industries.” That is a sales answer, not an honest one.

A Note on How to Use This List

You do not need every question answered before your first call. The early questions about service model and team structure belong in the first conversation. Security stack questions belong once you have received a proposal. Contract questions belong once you are seriously considering signing.

The pattern you are looking for across all of them is specificity. A provider who gives specific, documentable answers to specific questions is operating with accountability. A provider who gives you reassurance instead of answers is asking you to trust them without giving you any reason to.

If you are ready to start the evaluation process, our managed IT services pricing guide for Toronto businesses covers what to expect on cost before you start conversations. And if you are still deciding whether managed IT is the right move, see our honest guide to see if managed IT support is worth it for your Toronto business.

Frequently Asked Questions

How many questions should I ask an MSP before signing?

There is no set number, but you should get clear answers across five areas before signing: what is included in the base fee, what the security stack actually is, what the monthly reporting looks like, what the contract terms are, and what the off-boarding process involves. If any of those areas are vague after two conversations, that is your answer.

What should an MSP’s SLA include?

At minimum: a defined response time by issue severity (critical, high, medium, low), a resolution time target for each severity level, a process for escalation when the initial response does not resolve the issue, and a commitment to after-hours coverage with a description of what that coverage actually includes.

Can I negotiate MSP contract terms?

Yes. Contract length, notice periods, termination clauses, and scope definitions are all negotiable. A provider confident in their service will engage with these conversations. One who resists negotiation on exit terms is usually doing so because those terms benefit them more than you.

What happens if an MSP does not meet their SLA commitments?

It depends entirely on what the contract says. Some contracts include service credits for missed SLA commitments. Most do not. This is worth asking about before you sign, and worth getting documented if the provider makes verbal commitments about response times.