Skip to content 
Table of Contents
Most advice on how to choose a managed service provider reads like it was written by someone who has never actually signed an MSP contract. Verify their certifications. Check their response times. Ask for references.
What nobody tells you is that MSPs are exceptionally good at looking credible. They have polished onboarding decks, rehearsed answers to standard questions, and reference clients who were carefully selected because they never had a serious incident.
The real test of an MSP is not what happens on a Tuesday afternoon when nothing is broken. It is what happens at 2am on a Friday when your ERP system goes dark before a Monday payroll run, or when a phishing attack gets through their email filter and they have to explain why to your board.
The 12 questions to ask your MSP below are designed to get past the pitch and into the operational reality. Some will feel uncomfortable to ask. Ask them anyway. If you are serious about how to choose a managed service provider that holds up under real operational pressure, these are the questions that separate the credible from the convincing.
What does your SLA penalise you for, not just promise?
Any MSP can write a 99.9% uptime commitment into a contract. What matters is what happens when they miss it. Ask them directly: what is the financial or service remedy if you breach the SLA? How is downtime calculated? Does scheduled maintenance count? What is excluded?
Most MSP SLAs are written to be difficult to breach on paper, even when clients experience genuine disruption. Response time SLAs, for instance, often measure the time to acknowledge a ticket, not to resolve it. A technician sending an automated reply at 2am technically stops the SLA clock.
What to listen for: A confident MSP will cite specific credit structures and explain what is excluded. They will not need to check the contract while answering.
Watch for: Vague language like ‘we take SLA breaches very seriously’ or pivoting to how rarely they miss targets instead of answering what happens when they do.
How do you staff the helpdesk at 11pm on a Sunday?
This is not a question about whether they offer 24/7 support. They all say yes. This is a question about the actual human beings picking up the phone outside business hours.
Is it the same team? A dedicated overnight shift? A partner NOC in a different timezone? A third-party answering service that logs tickets for Monday morning? Each model has entirely different implications for how fast a critical issue gets escalated to someone with real access and real authority to act.
Also ask: what is the escalation path at 11pm on a Sunday, and who has the authority to make infrastructure changes without waiting for a senior engineer to wake up?
What to listen for: Specific headcount, named escalation paths, and the distinction between tier-1 logging staff and engineers with actual system access after hours.
Watch for: ‘We have 24/7 coverage’ without any detail on what that coverage actually consists of.
What breaks most often in the first 90 days with a new client?
This is a diagnostic question disguised as a conversational one. A mature MSP has run enough onboardings to have a clear answer. They know their own friction points: documentation gaps, tooling conflicts, staff resistance to new processes, discovery surprises in legacy environments.
If they answer ‘honestly, not much, our onboarding is pretty smooth,’ that is either exceptional or a red flag. Onboarding a new IT environment is inherently disruptive. The MSPs who say it goes smoothly are often the ones who avoid the hard work of proper discovery and just layer their tools on top of whatever they find.
What to listen for: Candid specifics. ‘We consistently find that the first patch cycle surfaces deferred updates clients did not know they had’ is a far better answer than ‘our process is thorough so we rarely have problems.’
Walk me through the last security incident you had to contain.
Not a hypothetical. Not their incident response policy. An actual event, with a timeline, a cause, a series of decisions, and an outcome.
You are not asking this to catch them out. You are asking because incident response is the single area where operational discipline is most visible. Did they detect it or did the client? How long between detection and containment? Who communicated what to the client and when? What changed afterward?
An MSP that has never handled a real incident has never been tested. An MSP that refuses to discuss past incidents, citing confidentiality, is avoiding a question they should be able to answer in general terms without naming the client.
Watch for: ‘We have not had any significant incidents’ or a rehearsed policy recitation instead of a real event narrative.
What does your patching process look like when a zero-day drops?
Routine patching is a baseline expectation. What separates average MSPs from operationally mature ones is how they handle unplanned urgency. When a critical vulnerability is published on a Wednesday, what happens in their environment before the weekend?
Ask who owns the decision to push an emergency patch outside the normal maintenance window. Who assesses the risk of patching against the risk of not patching? Who communicates with the client, and at what threshold does the client get a call versus an email versus a ticket update?
This question also reveals whether patching is a manual, engineer-dependent process or a documented, repeatable one that does not fall apart when someone is on leave.
What to listen for: A named decision owner, a documented risk-assessment step, and a client communication threshold. Not just ‘we use [RMM tool] to push patches.’
How do you handle a situation where your tooling caused the outage?
This happens. RMM agents corrupt update cycles. Backup software conflicts with endpoint tools. Monitoring scripts misfire and trigger cascading alerts. It is one of the most uncomfortable scenarios in MSP relationships because the vendor is both the cause and the responder.
Ask them directly: has this ever happened, and what did you do? If they say it has never happened, their environment is either very small or they are not being honest. If they describe a real instance, pay close attention to whether their first instinct was transparency or deflection.
Watch for: Any answer that focuses on how unlikely this is rather than how it would be handled when it happens.
What is in your contract that most clients do not read until it matters?
This question is deliberately disarming. You are inviting them to be honest about their own contract, and a trustworthy MSP will take that invitation.
The clauses that tend to matter most in practice: auto-renewal notice windows (often 60 to 90 days, easy to miss), definitions of what constitutes a covered device versus an excluded one, data ownership and portability provisions, limitations on liability caps in the event of a breach, and the conditions under which the MSP can terminate the contract without penalty to them.
If the salesperson cannot answer this and needs to pull in legal or account management, that tells you something. A provider who knows their contract well enough to flag its edge cases before you sign is a provider who has dealt with those edge cases before.
What to listen for: Specific clause references, not generalities. ‘Our auto-renewal clause requires 90 days written notice and clients sometimes miss the window’ is the kind of honest answer that builds trust rather than destroying it.
How does your pricing change as we grow?
Flat-rate pricing sounds predictable until your headcount grows 40% in a year, you acquire a subsidiary, or you migrate to cloud infrastructure that changes your device count entirely. Ask for three scenarios: what happens to your monthly bill if you add 25 users, if you onboard a new office, and if you decommission 20 legacy servers and move to a cloud-managed environment.
Also ask whether pricing is reviewed annually and what has historically driven price increases for existing clients. An MSP that cannot model these scenarios has either not thought about them or is not inclined to be transparent before the contract is signed.
Watch for: Per-device or per-user models with no ceiling, combined with no change-control process for scope adjustments.
Which compliance frameworks do you actually operate in, not just sell around?
Most MSPs will tell you they support HIPAA, PCI-DSS, SOC 2, ISO 27001 and anything else you name. What that usually means is that they will not actively break your compliance posture and they have a documentation template you can use for audits.
Actually operating within a framework means their own internal processes, staff training, access controls, and audit trails meet the standard, not just their client deliverables. Ask: are your own systems SOC 2 certified? Have you been through a PCI audit on your internal environment? Can you share your most recent third-party security assessment?
For regulated industries, this distinction is the difference between an MSP who can genuinely support your compliance program and one who will hand you a PDF at audit time and call it done.
What to listen for: Specific certifications for their own organisation, not just their client services. Any hesitation here is informative.
What does your offboarding process look like?
Asking about the exit before you have even entered tells an MSP something about how you operate. It also tells you something about them by how they react.
A confident provider will walk you through offboarding without defensiveness, because they do not rely on lock-in to keep clients. Ask specifically: what is the data return process, how long does it take, what format is the documentation handed over in, who owns the credentials to your own systems during a transition, and what are the knowledge-transfer obligations in the contract.
MSPs who make offboarding sound painful, slow, or administratively complex are often the ones relying on switching costs to retain clients they have stopped serving well.
Watch for: ‘We would really need to discuss that if we got to that point’ or anything that suggests offboarding is not a defined process.
Who specifically will manage our account, and what is their exit risk?
Account management continuity is one of the most underestimated factors in MSP relationships. The person who sells you the engagement is rarely the person managing it six months later. And the person managing it at month six may not be there at month eighteen.
Ask for the name and background of the account manager who would own your relationship. Then ask what happens to your account if that person leaves. Is there a documented handover process? Is account knowledge stored in a shared system or carried around in one person’s head?
MSP staff turnover is genuinely high in the industry. A provider who cannot articulate what continuity looks like has not thought through a problem that will almost certainly affect you at some point.
Watch for: Any answer that centres entirely on how good the account manager is, without addressing what happens structurally when that person is no longer there. “We have great people” is not a continuity plan.
What have you gotten wrong with a client in the last 12 months?
The final question, and the most revealing one.
There is no MSP operating at scale that has not made a meaningful mistake in the past year. Missed an SLA, underestimated a migration, made a tooling decision that caused downstream problems, failed to communicate during an incident. Something went wrong somewhere.
An MSP that cannot answer this question is either too small to have had the opportunity, too polished to be honest, or has a culture that does not acknowledge failure internally. None of those are ideal qualities in a long-term IT partner.
What you are looking for is not the absence of mistakes. You are looking for self-awareness, a clear account of what changed as a result, and the kind of operational maturity that treats problems as feedback rather than reputation risk.
What to listen for: A specific example, told without excessive qualification, followed by a concrete change they made because of it. That is the answer of a provider who will be honest with you when something goes wrong on your account too.
What the answers are really telling you
Reading between the lines of these conversations matters as much as the answers themselves.
A provider who answers every question confidently and specifically, without needing to check documents or defer to colleagues, has had these conversations before. They are either genuinely experienced, or they have prepared for exactly these questions because they know their operation can withstand scrutiny.
Watch for deflection patterns: pivoting from what happens when things go wrong to how rarely things go wrong. Pivoting from contract specifics to relationship values. Pivoting from real incidents to hypothetical frameworks. These are not signs of dishonesty necessarily, but they are signs that the answer to the question you asked is not one they are comfortable giving.
The best IT leaders who evaluate MSPs do not just score answers, they score the quality of thinking behind the answers. You are not just selecting a vendor. You are selecting a partner who will be inside your operational infrastructure during the moments that determine whether your business recovers quickly or slowly from the things that are going to go wrong.
Summary: Your MSP evaluation checklist
Knowing how to choose a managed service provider comes down to one thing: whether you asked the right questions before the contract was signed. Here is what that looks like in practice.
- SLA documents specify financial remedies, exclusions, and how downtime is calculated, not just uptime targets.
- After-hours helpdesk staffing model is explained in detail, including who has escalation authority and system access outside business hours.
- Onboarding friction points are acknowledged candidly, with a structured discovery process that surfaces problems before they become incidents.
- A real security incident has been described with timeline, cause, response decisions, and post-incident changes.
- Zero-day patch response has a named decision owner, a risk-assessment step, and a defined client communication threshold.
- The MSP has a transparent process for handling outages caused by their own tooling.
- Contract edge cases have been flagged proactively, including auto-renewal windows, liability caps, and device scope definitions.
- Pricing has been modelled across realistic growth scenarios, not just the current state.
- Compliance credentials apply to the MSP’s own internal environment, not just their client deliverables.
- Offboarding is a documented, time-bound process with defined data return and credential handover obligations.
- A named account manager has been identified, with a continuity plan that does not depend on that individual staying.
- A genuine mistake from the last 12 months has been shared, with a clear account of what changed afterward.
Use this MSP evaluation checklist as more than a pre-sales exercise. Bring it into your first quarterly review. Revisit it if service quality starts to slip. An MSP that answered these questions well before you signed should be able to answer them just as well twelve months in. When you find a provider that holds up to that standard, you have found the right partner.
Ready to see how Zazz can transform your IT operations? Schedule a consultation with our enterprise IT specialists today.
