Vendor Risk Management for MSPs

This guide covers tiering, the assessment questions worth asking, the contract clauses that hold, monitoring cadence, and the metrics an auditor will accept. All of it sized for a team without a full-time risk analyst.

TL;DR

• Vendor risk management. Identifying, assessing, and monitoring the security and compliance risk that third-party vendors bring into your business.
• The MSP difference. You get assessed as a vendor and you assess your own, so one control set has to serve both directions.
• Start with tiering. Rank vendors by data access and client blast radius, not by invoice size.
• Contracts beat questionnaires. Notification windows and audit rights are enforceable, a spreadsheet answer isn't.

Why MSPs Sit on Both Sides of the Vendor Risk Equation

The numbers moved fast. Verizon's 2026 Data Breach Investigations Report found a third party involved in 48% of breaches, up from 30% the prior year and 15% the year before that. Third-party supply chain breaches grew 60% year over year. That's a category going from edge case to default in three reporting cycles.

MSPs carry that exposure twice. Every vendor in your stack can reach your clients through you, and every client contract you sign makes you somebody's critical vendor. One compromised remote access tool doesn't stop at your network. It travels down the same pipes you use to deliver service.

CyberSmart's 2026 MSP survey, built on responses from 350 MSP leaders across the UK and Ireland, found 43% had a cyber incident that originated with a supplier or third-party vendor in the previous 12 months. Of those incidents, 16% hit the MSP alone and 39% hit the MSP and the customer together, so more than half landed on the provider in some form.

The Kaseya VSA attack is the clearest illustration. In July 2021, attackers pushed a malicious update through the on-premises product, reaching between 50 and 60 MSPs and a far larger set of their downstream clients. CISA and the FBI issued joint guidance on July 4. The providers caught in that blast radius hadn't misconfigured anything on their own network. They'd trusted a vendor, which is what buying software is.

The same CyberSmart research found 55% of MSPs weren't monitoring for supply chain risk at all. Among those who do assess it, 37% run the check quarterly and 11% run it once a year. A quarterly cadence means a vendor can be breached in January and still carry a clean rating on your spreadsheet in March.

Vendor Risk Isn't Vendor Lock-In

These two get filed together and they're different problems with different fixes.

Lock-in is about economics. Multi-year commitments, per-endpoint pricing that punishes growth, data formats you can't export, renewal quotes that arrive 40% higher because migrating would cost more than paying. That's the subject of the vendor lock-in trap and the broader stack economics covered in the SaaSpocalypse. The question there is what leaving costs you.

Vendor risk management asks something else entirely: what happens to your clients if this vendor gets breached, goes down, or fails an audit while you're still using them. The question is what staying costs you when the vendor has a bad day.

They interact, which is why they get confused. A vendor you can't leave is a vendor whose risk you have to absorb rather than exit. Lock-in removes your best remediation option. But you fix them separately. Lock-in gets fixed at contract negotiation and architecture. Vendor risk gets fixed with tiering, assessment, monitoring, and incident planning.

The Four Risks Your Vendors Bring In

Risk registers get long and useless fast. Four categories cover what an MSP faces, and each one has a different owner and a different signal.

Concentration risk is the one that gets missed, because nothing reports on it. It only surfaces during an incident, when the answer to "what else does this vendor touch" turns out to be everything.

Tier Your Vendors by Blast Radius, Not Spend

The most common mistake in an early program is ranking vendors by annual invoice. Spend measures your exposure to a price increase. It says nothing about the damage a compromise does.

Rank by two things instead: what client data the vendor can reach, and how many clients it reaches at once. Your $180-per-month remote access tool has admin rights on every endpoint you manage. Your $40,000 line of business software touches one client's records. The cheap one is tier one.

Run this honestly and the tier one list usually lands somewhere between eight and twelve vendors. That's a workable number to review properly. Twenty-five is not, which is why the tiering step comes before the assessment step.

The Assessment Questions That Earn Their Time

A 200-question spreadsheet returns 200 answers nobody reads. Nine questions with evidence attached will tell you more, and they map to what your own clients' auditors ask you.

1. Do you hold a current SOC 2 Type II or ISO 27001 certificate, and will you provide the full report under NDA rather than a summary letter?
2. Who are your subprocessors, where do they store data, and how much notice do we get before that list changes?
3. What's your contractual breach notification window in hours, and does it start at detection or at confirmation?
4. Is MFA enforced on all administrative and support access to our tenant, including your own staff?
5. What access does your support team have to our environment, is it standing or just-in-time, and is it logged where we can see it?
6. What's your published RTO and RPO, and when did you last test a restore?
7. How do you handle vulnerability disclosure and what's your median time to patch a critical CVE in a customer-facing agent?
8. On termination, how is our data returned, in what format, and how long until it's deleted from your systems and backups?
9. Do you carry cyber liability insurance, and what's the coverage limit?

Question four matters more than its length suggests. Cyber insurers now treat enforced MFA, EDR or MDR coverage, tested offsite backups, and a written incident response plan as baseline requirements, and they're extending that expectation to your vendors, not just your own network.

Question eight is where lock-in and risk overlap. A vendor that can't describe its exit process in writing has told you something useful about both.

Contracts Do the Work a Questionnaire Can't

A questionnaire captures what a vendor said in March. A contract clause is what you can enforce in November. When something goes wrong, only one of those is worth anything.

The CyberSmart research bears this out. When MSPs named their biggest hurdles, managing and enforcing security requirements in contracts came first at 39%, ahead of risk assessment and monitoring at 37% and the cost of securing supply chains at 36%. The hard part isn't finding out about the risk. It's having the leverage to do something about it.

Five clauses carry most of the weight. A breach notification window stated in hours, starting at detection. Subprocessor change notice with a right to object. Delivery of the current audit report on request, not on the vendor's publishing schedule. Data return and deletion terms with a deadline. And a termination right that triggers on a material security failure, so a breach doesn't leave you stuck paying through the remainder of a 36-month term.

Regulators already expect the paper trail. DORA, FFIEC guidance, and GDPR Article 28 all require documented evidence of vendor due diligence, and a questionnaire with documented follow-up is what satisfies that. If you serve financial services, healthcare, or defense clients, your vendor file is part of their audit whether you built one or not.

There's a commercial edge here too. Compliance certification now gates deals: 61% of companies report it's required to win or renew contracts, and 38% have lost revenue or competitive bids without it. The vendor file you build to manage risk is the same artifact that answers a prospect's security review. Tools that automate that evidence collection are covered in the GRC compliance software comparison.

Continuous Monitoring Without a Full-Time Risk Analyst

Annual reassessment is a compliance activity. It's not a security control, because vendors don't break on your review schedule.

Continuous monitoring for a small provider doesn't mean a threat intelligence subscription. For tier one vendors, subscribe to every status page and security advisory feed and route them into a channel a human reads daily. Set alerts on the vendor names themselves, so a breach disclosure reaches you from the news before it reaches you from the vendor. Track the CVE feeds for any agent you deploy at scale, because an unpatched flaw in software running on 3,000 endpoints is your problem the moment it's public, not the moment the vendor emails.

Three events should trigger an off-cycle reassessment regardless of the calendar: the vendor gets acquired, the vendor discloses a breach, or the vendor changes its subprocessor list. Acquisition is the sleeper. It changes the security team, the data locations, and the roadmap all at once, and it rarely comes with a notification that frames any of that as a risk event.

Keep the record in one place your team already opens. A vendor register living in the PSA next to the client records beats a comprehensive one in a spreadsheet nobody has bookmarked. The best program is the one that still gets updated in month nine.

When the Vendor Is the Breach

Plan for the call you don't want. A tier one vendor discloses a compromise on a Friday afternoon, and every client you serve is potentially affected.

Three things have to be ready before that day. First, a current mapping of which vendors touch which clients, so scoping takes minutes rather than an afternoon of guessing. Second, a client notification template that says what happened, what you're doing, and what you need from them, drafted while nobody's panicking. Third, a decision made in advance about isolation: which tools you'll disconnect immediately on a credible compromise, and who's authorized to make that call at 6pm on a Friday.

The CISA and FBI guidance from the Kaseya incident is worth reading before you need it, because it documents the sequence providers had to run under pressure. Shut down the affected service, preserve evidence, notify clients, restore from known-good backups. Every hour spent deciding that sequence during an incident is an hour the attacker keeps.

Your clients will judge you on the response, not on the fact that a vendor failed. Vendors get breached. Providers who can say which clients were affected within two hours keep their contracts.

The Metrics That Prove the Program Works

A program without numbers is a folder of PDFs. Five metrics show whether it's real, and they're the ones that hold up when a client's auditor asks how you manage third-party risk.

• Tier 1 coverage. Percentage of tier one vendors with a current assessment on file. Target 100%, and treat anything below it as a finding.
• Assessment age. Median days since last review, by tier. If the tier one median passes 365, the cadence has quietly stopped working.
• Contract coverage. Percentage of tier one contracts containing a breach notification clause with a stated window.
• Time to scope. Hours from a vendor breach disclosure to a confirmed list of affected clients. Measure it in a tabletop exercise before an incident measures it for you.
• Concentration ratio. Share of clients dependent on your single largest vendor. This is the number that turns a security metric into a business one.

That last one tends to surprise people. When a single platform holds the RMM, the PSA, the documentation, and the backup for every client on the book, the concentration ratio reads 100%, and no amount of questionnaire diligence changes it.

Fewer Vendors, Smaller Attack Surface

Every vendor added to the stack is another set of credentials, another subprocessor list, another notification window, another assessment to keep current. Vendor risk management scales with vendor count, and the work grows faster than the stack does, because the integrations between tools carry risk that neither vendor owns.

Consolidation is a legitimate risk control, with a real tradeoff attached. Fewer vendors means fewer assessments, fewer breach notification paths, fewer places client data sits, and a much shorter answer when an auditor asks who touches what. It also raises the concentration ratio, which is why the tradeoff is only worth making when the platform you consolidate onto doesn't trap you.

That's the test worth applying. A consolidated platform that locks you into a 36-month term with no export path has converted your vendor risk into vendor lock-in, and you've lost the ability to leave a provider having a bad year. One you can exit keeps remediation on the table.

It's the reason we built OpenFrame as an AI-native all-in-one MSP and IT platform, with native PSA included rather than bolted on from a third party, priced so consolidation doesn't require a capital decision, and without the lock-in terms that make leaving expensive. Fewer vendors in the file, and an exit that stays open.

Vendor risk management for MSPs comes down to one uncomfortable fact: you're accountable for vendors you don't control, to clients who won't distinguish between your failure and your supplier's. Tier the list, put the clauses in writing, and know within two hours which clients are affected. That's the whole program.