HOW TO USE THIS GUIDE.
Hiring a managed IT services provider (MSP) is not like buying a laptop. It's closer to hiring a department head — a multi-year operational dependency that will shape the security posture, productivity, and resilience of your business until you replace them. Most small-business owners interview their MSP candidates with the same rigor they'd apply to a software subscription, which is to say almost none, and then live with the consequences for three to five years. This guide is designed to fix that.
The eight questions below are not trick questions. They are the questions a sophisticated IT buyer would ask, and the questions a good MSP would actually welcome — because the right answers separate the firm from its weaker competitors. The whole point of going through this interview is to make the buying decision in the conference room, not in the middle of a ransomware incident eight months later when you discover the things you should have asked.
Score each answer on a simple three-point scale: green (specific, documented, in-writing, named owner), yellow (verbal-only, partial, “we're working on it” with a date), red (deflection, marketing language, “trust us”, refuses to put it in writing). Any single red on questions 4 (compliance), 5 (SLA), 7 (offboarding), or 8 (their own security posture) is a walk-away signal. Yellows are negotiation points if everything else looks strong.
Who should be in the room from your side: the owner (because budget, signature authority, and final accountability rest with you), and the person who actually deals with IT day-to-day (often the office manager or operations lead). The second person matters because they will catch the operational red flags the owner won't — the lived experience of “how does this MSP actually behave when something breaks at 4pm on a Friday” is the most important variable, and the office manager is the one who will live it.
Q1: WHAT WILL YOU SPECIFICALLY DO IN OUR FIRST 90 DAYS?
The first 90 days of a new MSP relationship determine almost everything that happens after. This is when documentation gets built (or doesn't), when MFA gets enforced (or doesn't), when EDR gets deployed (or doesn't), when the backup actually gets tested (or doesn't), and when the relationship's working rhythm gets established. An MSP that hand-waves through the onboarding question is an MSP that's going to hand-wave through everything else.
A good MSP has a documented onboarding playbook they will share with you, on paper or PDF, before you sign the contract. The playbook should specify named milestones with dates: network discovery and asset inventory by day 14, MFA enforcement across all email and admin accounts by day 21, EDR agent deployment on every endpoint by day 30, backup verification and first tested restore by day 45, documentation library populated by day 60, first vCIO strategy meeting by day 90. Real MSPs run this same playbook at every new client; it is not improvised per engagement.
A good answer sounds like: “Here's our written onboarding playbook. Week one we run discovery and document the environment. By week three, MFA is enforced on every account. By week four to five, EDR is on every endpoint. By week six to seven, we've tested a restore from your backup. By day ninety, we've held a vCIO meeting with you and produced a written 12-month roadmap. Your named primary technician is X, your account manager is Y, and you'll meet both during onboarding.” That answer is concrete, falsifiable, and accountable.
Red flags: “We'll just take over and figure it out as we go.” “Every client is different so we don't have a standard process.” “Onboarding usually takes about a month.” No written document offered. No named technician. No specific milestones. These answers reveal that the MSP either doesn't have a real onboarding process, or doesn't value it enough to systematize it — either way, you're going to be onboarded badly. The single most common reason a 90-day-old MSP relationship is already in trouble is that onboarding was treated as a casual hand-off rather than a structured project.
Q2: SHOW ME YOUR DOCUMENTED INCIDENT RESPONSE PROCESS.
It is 3am on a Saturday in February. Your front-desk staff member tries to log in Monday morning and sees a ransomware splash screen on every workstation. The phones go to your office manager, who calls you, who calls the MSP. What happens next is determined entirely by whether the MSP has thought this through in advance — in writing — or whether they're going to figure it out under pressure with your business on the line.
A real incident response (IR) process is a written document, usually one to three pages, that names the after-hours contact, defines the first-60-minute containment playbook, specifies how the cyber insurance breach coach gets engaged (and in what order — the breach coach should be called before forensics, to preserve attorney-client privilege over the investigation), names the MSP's forensic partner, and walks through the decision tree for ransom-pay-or-not, regulatory notification, client communication, and recovery. The document exists before the incident, not after.
A good answer sounds like: “Here is our written IR plan. Our after-hours number is X, answered by an on-call technician within 15 minutes. Our breach-coach coordination process is to call your cyber carrier's 24/7 hotline first, before we touch anything — this preserves privilege. Our forensic partner is [named firm]. Here's our containment playbook: disconnect, do not power off, document timestamps, preserve evidence. We've run this playbook at [N] incidents in the last [period].” That answer is operational, not theoretical.
Red flags: “We'll handle it — don't worry.” No document exists, or one exists but they won't share it before you sign. Can't name their forensic partner. Doesn't mention cyber insurance breach coach coordination at all. Suggests they'd start “cleaning up” before forensics arrives (this destroys evidence and may invalidate your cyber insurance claim). Has never run an actual incident in production. The IR process is the one place where “we'll figure it out” is a disqualifier — you are paying an MSP precisely so that someone has already figured it out.
Q3: WHICH SPECIFIC TOOLS DO YOU RUN ON OUR NETWORK?
The tooling stack an MSP runs on your network is not a trivia question — it dictates what is operationally possible. The RMM (remote monitoring and management) platform determines how patching and remote access work. The EDR (endpoint detection and response) tool determines what threats get caught and what gets through. The email security gateway determines how phishing is filtered. The backup platform determines how recoverable you actually are. The monitoring stack determines what gets seen at 2am. These are not interchangeable; the choices matter.
A good MSP has thought carefully about its stack, can defend each choice, and will list it for you on request. The list usually includes: an RMM platform (e.g. Datto RMM, NinjaOne, ConnectWise Automate, Kaseya VSA), an EDR product (SentinelOne, CrowdStrike Falcon, Microsoft Defender for Business, Sophos Intercept X), an email security layer (Microsoft Defender for Office 365 Plan 1/2, Proofpoint, Mimecast, Avanan), a BCDR backup platform (Datto BCDR, Veeam, Cove, Axcient), a productivity suite (Microsoft 365 Business Premium or Google Workspace), and a documentation platform (IT Glue, Hudu, ITBoost). Some MSPs add SIEM/SOC overlays (Huntress, Blackpoint, Arctic Wolf) for higher tiers.
A good answer sounds like: “On managed clients we run [specific RMM], [specific EDR], Microsoft 365 Business Premium with Defender for Office 365, [specific BCDR], and Huntress for managed detection and response. We chose [EDR] over [alternative] because [specific operational reason]. Here's our published stack document. We don't deploy ‘whatever the customer already has’ — we standardize, because it's how we get good at responding fast.”
Red flags: “Our stack is proprietary — we don't share that.” (Why not?) “We use whatever tools are best for the client.” (Translation: no standardization, no operational excellence.) Cheapest possible commodity stack with no EDR, no email security beyond M365 defaults, and no real backup platform — just file sync. An MSP that refuses to disclose the stack is either embarrassed by it or has never been pushed hard enough on the question to articulate a defense. Both are problems.
Q4: WILL YOU SIGN A BAA / ACKNOWLEDGE FTC SAFEGUARDS / MEET MY INDUSTRY COMPLIANCE OBLIGATION?
Every regulated industry has a compliance scheme that pulls the IT provider in as a contractual party. Healthcare practices need a Business Associate Agreement (BAA) under HIPAA — required by 45 CFR 164.502(e) and 164.504(e) for any vendor with access to PHI. Accounting and tax firms need an IT partner who understands the FTC Safeguards Rule (16 CFR Part 314) and can serve as or coordinate with the firm's Qualified Individual. Law firms in Florida operate under Florida Bar Rule 4-1.6 confidentiality obligations and the ABA's Formal Opinion 477R / 483 cybersecurity guidance. Investment advisors and broker-dealers operate under SEC Regulation S-P. Each of these creates direct obligations on the IT provider as a contracted vendor.
An MSP that's serious about your industry knows the rule by name, knows what its obligations are as your vendor, and has standard contract language ready to go. The MSP doesn't need to be a compliance auditor — that's a different role — but it needs to understand its own scope within the framework: what data it has access to, what controls it's contractually committing to maintain, what its breach-notification obligations are back to you, and what happens to your data when the relationship ends.
A good answer sounds like: “Yes, here's our standard BAA — we sign one with every healthcare client as part of onboarding, not as an extra.” Or: “Yes, for accounting firms we either serve as your Qualified Individual under FTC Safeguards or coordinate directly with the named QI you've appointed — here's how that division of responsibility works in our standard MSA.” Or: “Yes, for Florida law firms we align our handling of client-confidential data with Rule 4-1.6 and ABA Formal Opinion 477R — here's the specific contract language we use.” Specifics, by name, in writing.
Red flags: “What's a BAA?” (Disqualifier for healthcare engagement.) “We're not the compliance experts — that's your problem.” (True in part, but if they don't understand their own scope within the regime, they will become your problem.) Signs the BAA but won't acknowledge in writing that they are a Business Associate (this is bad-faith and unenforceable). “We can be compliant with anything — just let us know what you need.” (Marketing answer, not an operational one.) The compliance question is where many regional MSPs reveal that they've never seriously engaged with regulated-industry clients before, even when their pitch deck claims they have.
Q5: WHAT ARE YOUR DOCUMENTED RESPONSE SLAs AND WHERE ARE THEY WRITTEN?
A Service Level Agreement is only real if it's in the Master Services Agreement. The phrase “we respond quickly” in a sales meeting is not an SLA. The graphic on the website that says “15-minute response” is not an SLA. The verbal assurance from the salesperson is not an SLA. The SLA is the specific, severity-tiered, contractually-binding response and resolution target written into the body of the MSA you sign.
A real SLA structure has three tiers. Priority 1 (P1) is “everything is down, business is stopped” — ransomware in progress, no internet at the office, mail server down. Response target is measured in minutes (15-30 minutes is the modern standard). Priority 2 (P2) is “significant impact, partial outage” — one critical user can't print, one application is broken for several people. Response target is measured in hours (1-2 hours). Priority 3 (P3) is “single user, single issue, workaround exists” — the request queue. Response target is measured in business hours (4-8 hours). Each tier should also have a resolution-target window, not just an initial-response window.
A good answer sounds like: “Our SLAs are in Section 4 of the MSA. P1: 15-minute initial response, 4-hour resolution target, 24/7. P2: 1-hour response, 8-hour resolution, business hours plus on-call. P3: 4-hour response, 2-business-day resolution. If we miss P1 or P2 in a calendar month more than [X] percent of the time, you get a [Y] percent service credit on that month's invoice. We measure this against our ticket system — you can audit it.” The remedy clause is the real test — an SLA without a remedy is a promise without consequences.
Red flags: “We respond as fast as we can.” SLA exists in the brochure but not in the MSA. SLA exists in the MSA but has no remedy clause if missed. SLA exists but has no measurement methodology (whose stopwatch starts when?). SLA only covers initial response, not resolution. A real MSP has put this through the spreadsheet, knows what its actual SLA-attainment rate is, and will commit to it in writing. An MSP that wiggles on the SLA question is going to wiggle on every other commitment too.
Q6: CAN I TALK TO 3 CLIENTS IN MY INDUSTRY — INCLUDING ONE YOU NO LONGER WORK WITH?
References are easy to cherry-pick. Any MSP — even a mediocre one — can produce three happy current clients who will give a glowing 5-minute phone call. The reference question that actually separates the honest MSP from the polished one is the second half: “Can I talk to one client you no longer work with, and tell me, honestly, why the relationship ended?”
Every MSP that has been in business for more than three years has former clients. The reasons vary: the client got acquired and absorbed into the buyer's IT contract. The client grew large enough to hire an in-house IT team. The client wanted a service the MSP doesn't offer. The client cut costs and went to a cheaper provider. The relationship had a disagreement that ended it. Some of those endings are entirely fine — growth, acquisitions, scope changes — and good MSPs will gladly share those references. The willingness to share is the test.
A good answer sounds like: “Yes — I'll give you three current clients in your industry, plus two former clients. One former client we lost when they got acquired by a larger group last year; the previous IT manager will tell you the story. One former client we lost when they decided to bring IT in-house at the 25-employee mark; that owner will give you an honest debrief. Here are five phone numbers, give them all a call.” That answer is the signal of an MSP that operates in the open.
Red flags: “All our clients are currently active — we don't lose clients.” (Statistically improbable for any MSP older than two years.) “We don't share former-client information.” (Why not? If the ending was respectful, the former client is the best reference you have.) Refuses to provide any references for your specific industry. The references are all from companies a fraction of your size or in unrelated industries (signals you'd be a stretch engagement). Be especially skeptical of MSPs that can only produce written testimonials with no live phone references — written testimonials are written for marketing, phone references are for buyers.
Q7: WHAT HAPPENS IF WE WANT TO LEAVE YOU? SHOW ME YOUR OFFBOARDING PROCESS.
Any MSP whose business model depends on retention through friction rather than retention through service will make leaving harder than it should be. The offboarding question is therefore one of the most diagnostic in the entire interview — it surfaces whether the MSP has aligned itself with the client's interests or against them. Ask it at the sales stage, before you sign anything, and listen carefully to whether the answer is rehearsed or improvised.
A healthy offboarding process is written down and includes: a defined notice period (typically 30 or 60 days), no large early-termination fees beyond the notice window, full handover of Microsoft 365 / Google Workspace tenant global admin credentials back to the client (or to the incoming provider), uninstall of the outgoing MSP's RMM and EDR agents, transfer of the client's IT documentation library (IT Glue / Hudu / similar export), reasonable overlap with the incoming provider (30 days is typical and should not be billed twice), and a written confirmation that no “leave-behind” persistence remains on the network. Crucially, the client always retains ownership of its own data, domains, and Microsoft licenses — the MSP is a custodian, not an owner.
A good answer sounds like: “Here's our written offboarding process. 30-day written notice from either side ends the agreement — no early-termination fees beyond that month's invoice. During those 30 days we transfer all M365 global admin credentials to your designated administrator or to the incoming provider. We uninstall our RMM and EDR agents, export and hand over your documentation, and confirm in writing that we have no remaining access to your environment. We'll overlap with your incoming MSP at no extra charge so the handover is smooth. We've done this many times — we'd rather have a respectful exit than a captive client.”
Red flags: “We've never had a client leave so we don't have a documented process.” (Improbable; if true, it means the few who tried hit so much friction they didn't finish leaving.) Multi-year contracts with stiff early-termination penalties (six months of fees, “remaining contract value”, etc.). Refuses to commit in writing to handing back M365 tenant admin access (this is the “ransom your tenant” trick — it happens). Charges “deboarding fees” or “data extraction fees” not specified at signing. Refuses to allow overlap with an incoming provider. Any of these, by themselves, is reason enough to walk away — an MSP that has structured its contract to make leaving expensive is an MSP that doesn't need to deliver to keep you.
Q8: SHOW ME YOUR OWN SECURITY POSTURE — SOC 2, CYBER INSURANCE, INTERNAL CONTROLS.
An MSP with weak internal security is the supply-chain attack vector for every one of its clients. This is not a theoretical concern. In July 2021, the Kaseya VSA breach allowed REvil ransomware to propagate through MSP RMM tooling to roughly 1,500 downstream small-business clients in a single weekend. In December 2020, the SolarWinds Orion compromise hit thousands of organizations through a trusted vendor's software update. The MSP you hire holds privileged remote access to your environment; their security posture is your security posture, whether you've thought about it that way or not.
The interview question is straightforward: tell me, in writing, about your own internal security. Four sub-questions to ask: (1) Are you SOC 2 Type II attested, or on a documented path to it with named dates? (2) Who is your cyber insurance carrier and what are your liability limits? (3) Do you enforce MFA, EDR, and tested encrypted backup on your own internal systems and admin accounts — the same controls you're selling to me? (4) Who is your named security lead (CISO, vCISO, or equivalent), and what is the reporting line for an internal security incident at the MSP itself?
A good answer sounds like: “We are SOC 2 Type II attested as of [date] — here's a summary, the full report is available under NDA. Our cyber insurance carrier is [named carrier], with $X million per-occurrence and $Y million aggregate limits. Internally we enforce MFA on every employee account, EDR on every workstation, and tested backups on every system that holds client data. Our security lead is [named person]. If we had an internal incident affecting clients, our policy is to notify affected clients within 24 hours of discovery, and we have a written client-notification template ready.”
Red flags: “We're working on SOC 2” with no specific date or auditor named (working toward it is acceptable; doing it forever is not). “We're too small to need SOC 2.” (You are exactly the size where it matters most — you handle privileged access to many small businesses.) Declines to disclose cyber insurance carrier or limits. Cannot articulate whether MFA is enforced on its own internal admin accounts. Cannot name a security lead. Becomes defensive when asked. An MSP that won't answer this question honestly should not be trusted with the keys to your environment, full stop.
THE SIMPLY IT POSITION IN ONE PARAGRAPH.
Simply IT is a veteran-owned managed IT provider headquartered in Ocala, FL, serving small and mid-sized businesses across North Central Florida — medical and dental practices, accounting and tax firms, law firms, and operating businesses across construction, manufacturing, and professional services. We answer every one of the eight questions above with specific, in-writing, named-owner commitments — not because we're unusual, but because the buyer's guide we wrote is the buyer's guide we run.
How we answer the eight: (1) Documented 90-day onboarding playbook with named milestones (network discovery and inventory by day 14, MFA enforced by day 21, EDR deployed by day 30, tested backup by day 45, vCIO meeting by day 90). (2) Written incident response plan, named after-hours technician, named cyber insurance breach-coach coordination process, written containment playbook. (3) Published tooling stack on request — RMM, SentinelOne or Defender for Business EDR, Microsoft 365 Business Premium with Defender for Office 365, BCDR backup with immutable retention, Huntress for managed detection. (4) BAA signed as standard for every healthcare client, FTC Safeguards alignment and Qualified-Individual coordination available for accounting clients, Florida Bar Rule 4-1.6 alignment for legal clients. (5) Severity-tiered SLAs — 15-minute response for P1, 1-hour for P2, 4-hour for P3 — written into the MSA. (6) Industry references available, including former clients with context. (7) Documented offboarding process — 30-day overlap allowed, full tenant admin handover, no exit fees beyond contracted notice. (8) Internal MFA / EDR / tested backup posture, named cyber insurance carrier, SOC 2 on a documented path, named security lead.
Pricing is published, transparent, and on the website. Simply Managed is $75 per user per month — the foundational tier with proactive monitoring, patching, helpdesk, and Microsoft 365 administration. Simply Secure is $125 per user per month — adds EDR, email security, security awareness training, encrypted backup, and 24/7 SOC monitoring. Simply Compliant is $150 per user per month — adds BAA, written risk analysis, compliance documentation, advanced backup retention, and the controls a regulated practice needs. Every engagement is month-to-month, no long-term contracts. We earn the renewal every month, not at the contract anniversary.
How to start: schedule a free IT assessment. No obligation. We'll review your current environment, run the eight questions back at your incumbent provider so you can score the answers, and give you an honest written gap-and-fix report. If we're the right fit, the onboarding playbook starts the next month. If we're not, you have a written assessment you can use anyway. That's the deal.