Vendor Management for MSPs

You sell your clients on knowing who has access to their data. Then you hand a dozen vendors administrative access to every endpoint you manage and never write any of it down.

That is the gap. Most MSPs in the 10 to 20 employee range carry 40 to 80 active vendor relationships. Almost none of them have a list. When a vendor gets breached you find out from the news, then spend two days working out whether it touched you.

Every one of those vendors is a door into your business. Some of them are doors into every client you have.

This page adapts the Third-Party Vendor Management guidebook published by GTIA, written by Nett Lynch, MBA, for shops your size. It covers the five TPVM controls of the GTIA Cybersecurity Trustmark, and the control numbers stay mapped throughout so anyone chasing certification can follow along. The original is a reference manual written for organizations of any size. I cut the parts that assume you have a Change Advisory Board and put the copy-paste material back in.

Why this lands differently for you

Three things make vendor risk worse for an MSP than for a normal company of the same headcount.

Your vendors have admin. Your RMM agent runs as SYSTEM on a few thousand endpoints. Your documentation platform holds every client's credentials, network diagram, and recovery procedure. Your remote access tool bypasses the front door by design. Nobody else in your market carries that blast radius.

Your clients hold you responsible. Read your own MSA. Most of them make you accountable for the tools you selected, whether or not you built them. When a vendor gets breached, your client does not call the vendor. They call you.

Regulators are catching up. HIPAA covered entities have to document business associate relationships. PCI-DSS requires vendor management controls. CMMC mandates supply chain risk management. If you serve anyone in those lanes, your vendor program is already in scope whether you built one or not.

GTIA cites industry research putting roughly 29 percent of data breaches as involving a third party. For most businesses that is a statistic. For you it is the delivery mechanism. One compromised RMM vendor hits every client you manage at the same time.

Step 1: Find every vendor (VENDOR.1)

Start with discovery, not documentation. Every shop I work with underestimates their vendor count by 40 percent or more on the first pass.

Pull from five sources. Do all five. Any one alone misses things.

Twelve months of credit card and bank statements. Highest yield source and the one owners skip because it is tedious. Every recurring charge is a vendor. Sort by amount, then read every line under $50, because that is where the surprises live.

Your identity provider. Export applications with OAuth grants or SAML connections in Entra ID or Google Workspace. Anything a user consented to is a vendor holding your data. Most owners have never opened this list. It is usually longer than the statement list.

Your PSA and RMM integration menus. Whatever is connected and authenticated is a vendor with access. Include the ones turned on for a trial two years ago and never disconnected.

Your DNS and email records. SPF includes and DKIM selectors tell you who sends mail on your behalf. Each one is a vendor holding your domain reputation.

Ask your team. Ten minutes in a team meeting. What tools do you use to get your job done that we might not know about. Frame it as amnesty and mean it. Punish the first disclosure and you will never get another one.

Expect to find personal LLM accounts, note takers recording client calls, file transfer services, and at least one thing that makes you say out loud "we pay for that?"

What counts as a vendor

Any outside company whose failure hurts you or your clients. SaaS applications including the ones a single tech signed up for. Cloud infrastructure and hosting. PSA, RMM, documentation platform, backup. Security vendors, SOC providers, anyone doing MDR for you. AI and LLM providers, including any tool connected to your PSA, RMM, or documentation platform. Telecom. Payroll, HR, accounting, legal. Distributors with an ongoing service relationship.

The AI ones matter more than most owners think. Connect a model to your documentation platform and that vendor reads every password note, network diagram, and client procedure you have ever written. Connect it to your PSA and it reads every ticket. That is higher access than most of your traditional vendors hold, and it usually shows up on nobody's list because a tech set it up in an afternoon.

Personal AI accounts count too. If your techs paste client configs into a free ChatGPT account, you have an undocumented vendor relationship with terms you never read, holding data you are contractually obligated to protect.

Step 2: Write them down (VENDOR.1)

A spreadsheet is fine. It stays fine well past 20 employees. Do not buy a GRC platform to solve a problem a shared sheet solves, and do not let a tool selection stall the project for two months.

Build these columns. This is the whole spec.

Two columns earn their keep faster than the rest. Account structure surfaces every shared login you have, and shared logins on vendor portals are the most common way small shops fail an assessment and, separately, get burned. Cancellation notice window saves you real money the first time you catch a 60 day notice requirement 45 days out.

Assign one owner for the sheet. One person whose name is on it. Programs without a dedicated owner stagnate, because vendor management becomes everyone's responsibility and nobody's priority. In a shop your size that person is usually the ops lead, sometimes the owner. It is rarely the most technical person on staff, and that is on purpose.

Review the whole sheet annually. Update it the day something changes.

Step 3: Rank them (VENDOR.3)

Your EDR vendor and your stock photo subscription do not belong in the same conversation. Three tiers. More than three creates overhead you will abandon by month four.

Rank on four questions.

1. Can they reach client environments?
2. Do they hold client data?
3. How long can you deliver service without them?
4. Do they touch regulated data?

Any yes on question one puts a vendor in Tier 1. No exceptions, no debate.

Tier 1: Critical

These vendors can reach your clients. A compromise here is a compromise everywhere.

RMM. PSA. Documentation platform. EDR or MDR. Backup and BCDR. Your Microsoft CSP tenant and any partner level access you hold. Remote access and screen sharing tools. Password manager or PAM. Email security gateway. Any LLM platform connected to client systems.

Treatment: annual security documentation review, MFA required with no exceptions, named owner, breach notification language in the contract, quarterly access review, and a written answer to "what do we do if this vendor goes dark for a week."

Tier 2: Important

These vendors hold your business data or your clients' business data, but cannot reach client environments.

Quoting and CPQ. VoIP. Accounting and invoicing. Payroll and HR. CRM. Security awareness training. File sync and share. Marketing automation. Any LLM account your team uses for client adjacent work that is not connected to client systems.

Treatment: SOC 2 or equivalent requested at signing and at renewal, MFA required, named owner, annual review, standard security terms in the contract.

Tier 3: Low

These vendors hold nothing that hurts you.

Website hosting for your marketing site. Design tools. Stock imagery. Scheduling links. Swag and print. Office supplies. The coffee service.

Treatment: on the list, has an owner, reviewed annually with the rest of the sheet. That is it. Do not spend a security questionnaire here.

Classify on access, not storage

A vendor that stores nothing but holds admin credentials to your tenant is Tier 1. Attackers do not care what sits in the vendor's database. They care what the vendor can reach.

This is exactly why AI integrations get miscategorized. Owners look at an LLM provider and think it is just a chat tool that stores nothing. Then they check the configuration and find a service account with write access to the PSA. That is Tier 1, and it should have been Tier 1 from day one.

Read only credentials on dedicated service accounts. Never a shared admin login. Never write or delete permissions. I watched a shop lose two days of ticket history because someone gave an AI agent write access to test something. It worked exactly as designed. That was the problem.

Make the tier mean something

If Tier 1 and Tier 3 vendors get treated identically, you built a column, not a control. Tier drives review frequency, what you require in the contract, and who has to approve it. Re-tier when something changes. A vendor that adds an integration, gets acquired, or expands into your client environments moves up.

Step 4: Fix the contracts (VENDOR.4)

Without contract language, every security promise a vendor made during the sales process is just something a rep said on a call.

Here is the uncomfortable part. You will not negotiate with Microsoft. You will not negotiate with your RMM vendor either, most likely. Large vendors hand you standard terms and the answer is no.

That does not make this step pointless. It changes what the step is. For vendors who will negotiate, use the language below. For vendors who will not, do three things: document that you asked, record the compensating control you accepted instead, usually their SOC 2 report, and get the owner to sign off on carrying that risk. A one paragraph note in your vendor sheet satisfies this. Assessors want to see you made a decision, not that you won every negotiation.

For smaller vendors, negotiate. Regional providers, your MDR partner, contractors, and niche software companies will often take your terms because your contract matters to them.

Copy-paste contract language

Run these past your attorney before you use them. They are a starting point, not legal advice, and I am not a lawyer.

Breach notification

Vendor shall notify Client in writing within twenty-four (24) hours of discovering any actual or reasonably suspected security incident affecting Client data or Client systems. Notification shall include the nature and scope of the incident, the data or systems affected, the steps Vendor has taken to contain it, and a named point of contact. Vendor shall cooperate with Client's incident response activities and shall provide reasonable access to logs, forensic findings, and personnel throughout the investigation.

Twenty four hours is the ask for Tier 1. Seventy two is a reasonable floor if they push back. Anything vaguer than a number is not a term.

Security program

Vendor shall maintain an information security program appropriate to the sensitivity and volume of data accessed, consistent with recognized industry frameworks including SOC 2, ISO 27001, or the NIST Cybersecurity Framework. Vendor shall provide Client with current third-party audit reports or attestations upon request, and at minimum annually.

Data protection

Vendor shall encrypt Client data at rest and in transit using current industry-standard methods. Vendor shall restrict access to Client data to personnel with a documented business need, shall enforce multi-factor authentication for all administrative and remote access to systems containing Client data, and shall not use Client data for any purpose other than delivering the contracted service.

Subcontractors and sub-processors

Vendor shall provide Client with written notice at least thirty (30) days prior to engaging any subcontractor or sub-processor that will access Client data. Vendor shall impose security obligations on such parties no less protective than those in this agreement and remains responsible for their performance.

Data return and destruction

Upon termination or expiration of this agreement, Vendor shall return all Client data in a commonly readable format within thirty (30) days of written request, and shall thereafter securely destroy all copies in its possession, including copies held in backups and by subcontractors, within ninety (90) days. Vendor shall provide written certification of destruction upon completion.

AI and model training

Vendor shall not use Client data to train, fine-tune, or otherwise improve any machine learning or artificial intelligence model, whether Vendor's own or a third party's, without Client's prior written consent. Vendor shall disclose any AI or machine learning components used in delivering the contracted service and shall identify any third-party model providers who process Client data.

That last one is not in the GTIA guidebook. Add it anyway. Your vendors are shipping AI features on top of your client data right now and most of their standard terms let them.

The two clauses to check first

If you only audit your existing contracts for two things, check the breach notification window and the data return terms. A vendor with no notification obligation can sit on a breach for weeks while your clients stay exposed. A vendor with no return obligation can hold your data hostage during a migration.

Review contracts annually at renewal. Renewal is the only moment you have leverage, and the only moment most vendors will take the call.

Step 5: Control the changes (VENDOR.5)

New vendors get added between reviews. That is how the sheet you just built goes stale in seven months.

You do not need a Change Advisory Board. You need one rule and six questions.

The rule: no new vendor gets credentials, an integration, or client data until someone answers the six questions and the owner approves it. Put the questions in a PSA ticket template so it takes four minutes, not a meeting.

The six questions

1. What data will this vendor access, and does any of it belong to clients?
2. What level of access do they need, and is read only sufficient?
3. Will this connect to the RMM, PSA, documentation platform, or a client tenant?
4. Does any regulated data flow through it? HIPAA, CUI, PCI, CJIS?
5. What tier does this land in, and what does that tier require?
6. Do we have their SOC 2 or security documentation, and who owns this relationship?

Question two matters most. Read only is sufficient far more often than the vendor's setup guide suggests. Their documentation asks for global admin because it is easier for them to support, not because the product needs it. Push back. If they will not scope it down, that goes in your risk acceptance note.

The same six questions apply when an existing vendor expands scope. New integration, new module, new access level, run the questions again and re-tier if the answers changed.

Keep the approval fast. If getting a tool approved takes two weeks, your team stops asking and starts expensing. Make Tier 3 approval a five minute conversation and save the real scrutiny for Tier 1.

Termination

Ending a vendor relationship is a change too, and it is the one everybody botches. Go check right now how many former vendors still have live credentials in your environment. For most shops the answer is uncomfortable.

Revoke access on the last day, not the renewal date. Revoke every credential and API key, including the ones living in your automation scripts. Those are the ones people miss. A vendor gets replaced, the portal account gets disabled, and an API key keeps working for another eighteen months because it lives in a script nobody opened. Pull the OAuth grant, not just the license. Request your data back in writing before you cancel, because your leverage disappears the moment the account lapses. Confirm destruction. Cancel the billing so you stop paying for access you thought you removed. Update the sheet.

Emergency changes

You will sometimes need a vendor fast during an incident. Fine. Do it. Then document it within a week and run it through the normal review after the fire is out. Skipping the paperwork permanently is how undocumented vendors accumulate.

Step 6: Write the policy last (VENDOR.2)

Most guides put policy first. I put it last on purpose.

A policy written before you have done the work describes a program you do not have. Assessors catch that immediately, and so does reality the first time someone needs to make a decision. Write down what you actually do after you are doing it, and the document takes an hour instead of a month.

Six sections. Two pages is plenty at your size. Here is language you can copy and adapt.

[COMPANY NAME] Third-Party Vendor Management Policy

Scope and definitions. This policy covers any external organization providing products, services, or capabilities we rely on to operate the business or deliver client services. This includes software subscriptions, cloud services, AI and language model providers, infrastructure, and outsourced business functions. One-time hardware purchases with no ongoing service relationship fall outside this policy.

Roles. [ROLE] owns this policy and the vendor inventory. [ROLE] reviews and approves new vendors before purchase. [ROLE] reviews security documentation for Tier 1 vendors. No employee purchases or signs up for a service that touches company or client data without approval. This applies to free tiers and trials. Free does not mean low risk.

Tiers and treatment. We assign every vendor to Tier 1, Tier 2, or Tier 3 based on whether they can reach client environments, whether they hold client data, how long we can deliver service without them, and whether regulated data flows through them. Any vendor that can reach client environments is Tier 1. [Paste your three tiers and what each one requires here. This section does the most work of the six.]

Lifecycle. Selection, onboarding, ongoing review, offboarding. Before approval, the requester answers the six intake questions in [DOCUMENT/LOCATION]. Before any vendor gets access we create a dedicated service account, never a shared one, and add them to the inventory before the first login. Before connecting any AI tool to our PSA, RMM, documentation platform, or client environments, we confirm the vendor's data retention and training terms in writing and grant read only access through a dedicated service account. We do not grant write or delete permissions. At termination, [ROLE] revokes all access and API keys, confirms data return or deletion, cancels billing, and updates the inventory within [NUMBER] business days.

Risk acceptance. When a vendor refuses a security requirement, we document the request, the refusal, the compensating control we accepted, and who approved carrying the risk. [ROLE] approves risk acceptance. In a shop this size that is the owner.

Review. [ROLE] reviews this policy annually in [MONTH], and after any vendor security incident that affects us.

Approved by: [NAME], [TITLE], [DATE]

Get it signed and dated. Send it to everyone with vendor responsibilities and keep the email. Both of those are evidence, and both take five minutes.

What this actually takes at your size

The GTIA guidebook estimates one person spending 10 to 15 hours weekly for three to six months to build a program. That is written for organizations with a compliance function. You do not have one and you do not need to spend 200 hours on this.

Realistic version for a shop your size:

• Week one, 8 hours. The discovery pass. Bank statements, OAuth grants, integration menus, DNS records, team conversation. This is the bulk of the whole project.
• Week two, 4 hours. Build the sheet. Assign tiers.
• Week three, 4 to 6 hours. Pull security documentation and contract terms for Tier 1 only. Usually eight to twelve vendors. Write the policy from the template above and get it signed.
• Ongoing, 2 hours per quarter. Review the inventory, check renewals, remove dead vendors.

Call it 15 to 20 hours up front and eight hours a year after. You will spend more than that on a single Teams migration.

What good enough looks like

GTIA uses a three level maturity model, Ready, Aware, and Resilient, and puts most organizations at 12 to 18 months to progress through it. That timeline is real for a 400 person company. For a shop your size it reads as a reason not to start, so ignore the calendar and use this instead.

You are in decent shape when all six are true:

1. Every vendor is on one sheet with a named owner
2. Every Tier 1 vendor has MFA enforced and no shared logins
3. Every Tier 1 vendor has current security documentation on file
4. No new vendor gets access without someone answering the six questions
5. Contracts have breach notification and data return language, or a written note saying why they do not
6. Somebody reviews the whole thing once a year and the date is on the sheet

Consistency beats perfection here. Systematically covering 80 percent of your vendors puts you further along than exhaustively assessing your top three.

The failures I see most

Shared vendor portal logins. One set of credentials for the RMM console, in a shared vault entry, used by six people. When someone leaves you cannot revoke access without breaking everyone. Most common finding, easiest to fix.

Nobody owns the sheet. Built during a compliance push, abandoned by month four. One name, on the sheet, with the annual review on their calendar. Tie the update to something already on a schedule, like your monthly ops meeting.

Access that was never scoped down. Global admin granted during onboarding two years ago because the setup guide asked for it. Nobody revisited. Audit your Tier 1 vendors for this specifically.

Auto renewals nobody tracks. You find out about the 60 day notice window on day 45. That column exists for a reason.

Trial integrations still connected. Turned on, evaluated, rejected, never disconnected. The OAuth grant is still live and the vendor still has a token.

AI tools skipping the process entirely. They arrive as experiments, get connected to production systems, and never get treated as vendor relationships. They hold more access than almost anything else on your list.

Delegating the whole thing to the most technical person. They will build a beautiful automated system and never finish it. This is an operations job with a security outcome, not an engineering project.

If you are pursuing the Trustmark

The six steps above map to VENDOR.1 through VENDOR.5. Assessors want evidence, not documents. They want your inventory with review dates, your signed policy, your classification criteria and the tiers you actually assigned, sample contracts with security terms, and records of vendor changes going through your process.

The gap between having a policy and passing an assessment is proof that you follow it. Keep the artifacts as you go. Screenshots of approval conversations, dated inventory exports, emails confirming data deletion. Reconstructing a year of evidence the week before an assessment is miserable, and assessors can tell.

Where this goes next

Do your own house first. Everything above is internal. That is the right order, and not just for integrity. You cannot sell a vendor risk assessment credibly while your own RMM console runs on a shared login.

Once your program holds together, the same work packages for clients. That is the companion page on client facing vendor risk services.

Start with the credit card statements. Twelve months. That one afternoon tells you how big this actually is at your shop, and it is almost always bigger than the number in your head.

Talk it through

Building the sheet is the easy part. Where owners get stuck is tiering 60 vendors when half of them are ambiguous, and deciding which contract fights are worth having when you have leverage with about four of your vendors.

Everything above is a template. Run it yourself this week and never talk to me. What I will not do is hand you a system and tell you your shop is wrong for not matching it.

Not sure this is your actual constraint? Take the MSP Owner Reality Check. Five questions, nine minutes, and it names the two or three things quietly capping your growth. https://themsphero.com/resources/msp-owner-reality-check-assessment

If you already know what is broken, book a 30 minute fit call at https://letschat.themsphero.com

Mike Kolb The MSP Hero

Adapted from Third-Party Vendor Management: A Guidebook for IT Solution Providers, published by the Global Technology Industry Association and written by Nett Lynch, MBA. The five TPVM controls and the Ready, Aware, and Resilient maturity model are GTIA's. The tiering examples, contract language, discovery method, sequencing, and everything I got wrong are mine.