MSP Vendor Risk Assessment Template: Tier, Question, and Score Every Vendor

A vendor risk assessment tells a client which outside companies can reach their data or systems, how well each one protects it, and what the client will do about the weak ones.
Most clients never write that down. The payroll provider, the line-of-business app, the billing portal, and the cloud file share all got signed by whoever needed them that year. Then an insurer's renewal form asks how vendors are reviewed, or a breach notice lands from a vendor nobody remembers approving, and the owner asks the MSP for "a vendor risk template."
This template is built for the vCIO or account lead who gets that ask. It covers four steps: list the vendors, tier them, send a short questionnaire, and score the answers. It ends with turning each weak score into a decision the client owns. It also works in the other direction, because to every client you support, your MSP is a critical vendor too.
If a vendor has already reported an incident, start with the MSP vendor breach response playbook instead. This page is the work you do before that call.
Why clients now get asked about vendors
Vendor oversight has moved from good practice into written requirements that clients feel through regulators, insurers, and their own customers.
- FTC Safeguards Rule. Section 314.4(f) of 16 CFR 314.4 tells covered financial institutions to oversee service providers in three ways: select providers capable of appropriate safeguards, require those safeguards by contract, and periodically assess providers based on the risk they present. Section 314.4(i) adds service provider arrangements to the annual written report. If the client already has a written program, the MSP WISP template shows where this section sits.
- NIST Cybersecurity Framework 2.0. The supply chain category in CSF 2.0 asks organizations to know and prioritize suppliers by criticality (GV.SC-04), do due diligence before a relationship starts (GV.SC-06), keep supplier risk recorded and monitored over the relationship (GV.SC-07), and plan for what happens when it ends (GV.SC-10).
- CIS Controls. CIS Control 15 asks for a process to evaluate service providers who hold sensitive data or run critical IT platforms or processes.
- HIPAA. A covered entity needs a business associate agreement with any vendor that creates, receives, maintains, or transmits protected health information on its behalf.
- Cyber insurance. Many renewal applications ask how third-party access is reviewed and whether it requires MFA. The cyber insurance requirements guide covers the controls insurers ask about most.
None of these sources hands you a questionnaire. They describe outcomes. The template below turns those outcomes into a list a client can finish in one working session.
Step 1: Build the vendor list
Start with a plain inventory. You cannot tier or question a vendor nobody has written down.
Pull candidates from the places vendors leave tracks: the accounting system's recurring payments, the identity provider's enterprise app list, OAuth consents in the client's productivity suite, the firewall's allowed remote access rules, and the client's contract folder. A SaaS audit is a fast way to surface the apps nobody approved.
Capture one row per vendor:
| Field | What to record |
|---|---|
| Vendor | Legal name and the product the client uses |
| Business owner | The person at the client who approves renewal |
| Service | What the vendor does for the client, in one line |
| Data | Types of client data the vendor stores or processes |
| Access | Accounts, agents, API connections, or network paths into client systems |
| Contract | Renewal date, notice period, and where the signed copy lives |
| Tier | Critical, important, or low (Step 2) |
| Last reviewed | Date of the last completed questionnaire |
Leave the tier blank until every row has a data and access answer. Those two columns drive everything after.
Step 2: Tier each vendor by what it can reach
Tiering decides how much effort each vendor gets. A client with dozens of vendors cannot send every one a long questionnaire, and should not try.
Use the data and access columns to place each vendor:
| Tier | Rule | Examples of the kind of service |
|---|---|---|
| Critical | Holds regulated or sensitive client data, has admin or standing access to client systems, or the business stops when it goes down | Payroll, practice management or line-of-business systems, cloud hosting, the MSP itself |
| Important | Holds internal business data or has limited, user-level access, and the client could work around an outage for a few days | Project tools, marketing platforms, scheduling, e-signature |
| Low | No client data beyond contact details, no access to client systems, easy to replace | Office supplies portal, public webinar tool |
When a vendor sits between two tiers, put it in the higher one. Moving a vendor down after a clean review is easy. Explaining why a payroll provider got the short form after it leaked records is not.
Step 3: Send the 12-question review
Critical vendors answer all 12 questions with evidence. Important vendors answer questions 1 through 6 and 11. Low vendors only need questions 1 and 2 recorded at onboarding.
| # | Question | Evidence to ask for |
|---|---|---|
| 1 | What client data do you store or process, and in which countries? | Data inventory or data processing addendum |
| 2 | What access do you have to client systems, and through which accounts, agents, or API connections? | List of service accounts and permissions |
| 3 | Is MFA enforced for your staff and available for client logins? Do you support single sign-on? | Policy excerpt or admin setting screenshot |
| 4 | What independent assurance can you share, and what period and scope does it cover? | SOC 2 Type II report, ISO 27001 certificate and statement of applicability |
| 5 | Which subprocessors touch client data? | Current subprocessor list |
| 6 | How fast will you notify us of a breach that affects our data, and is that in the contract? | Contract clause with the notification window |
| 7 | Is client data encrypted in transit and at rest? | Security documentation |
| 8 | How do you back up client data, and how fast can we get it back? | Recovery objectives in writing |
| 9 | What audit logs can we see, and for how long? | Log retention setting or documentation |
| 10 | Does the contract include security requirements and a right to review them? | Contract section reference |
| 11 | If we leave, how do we export our data, and how do you confirm deletion? | Export format and deletion process |
| 12 | Who at your company owns security questions, and how do we reach them? | Named contact or security page |
Send the questionnaire from the client's address, with the business owner copied. The vendor's contract is with the client, so the request should come from the client too.
Step 4: Score the answers
Score each answered question from 0 to 2:
- 0: No answer, no control, or "we are working on it."
- 1: A control exists, but the evidence is self-attested or out of date.
- 2: A control exists and the vendor sent current evidence.
Then apply the decision rule for the vendor's tier:
| Tier | Must-pass questions | Decision rule |
|---|---|---|
| Critical | 2, 3, 6, 11 | Any 0 on a must-pass question becomes a finding. Two or more 1s on must-pass questions become a finding. |
| Important | 2, 3 | Any 0 on a must-pass question becomes a finding. |
| Low | None | Record it. Revisit only if the data or access answer changes. |
These thresholds are a starting point. Adjust them to the client's framework and risk tolerance, and write the version you used next to the score so next year's review compares like with like.
A total score is useful for sorting a long vendor list. The decision rule is what the client acts on, so lead with findings in the summary and keep the totals in the appendix.
Put vendor findings on the same record as the roadmap
Track each vendor gap with its severity, then turn it into a roadmap item, an accepted risk, or a scoped project the client can approve. Free plan, no credit card.
Turn every finding into a decision
A finding with no decision is a spreadsheet cell. Each one should end in one of four outcomes, recorded with the client's name next to it:
| Outcome | When it fits | What the MSP delivers |
|---|---|---|
| Fix with the vendor | The vendor offers the control and the client has not turned it on, such as SSO or MFA enforcement | A small scoped task, or included work if the agreement covers it |
| Roadmap item | The fix needs budget or timing, such as moving to a plan tier with audit logs | A dated roadmap entry with an owner and a cost range |
| Accepted risk | The client chooses to keep the vendor as it is | A written acceptance with the reason, the owner, and a review date |
| Replace the vendor | The vendor cannot meet a must-pass control | A scoped migration project with its own quote |
Accepted risk is a legitimate answer. It protects the MSP only when it is written down and signed by someone at the client who has the authority to accept it. A shared responsibility matrix makes it clear which side owns the vendor relationship and which side owns the technical fix.
Replacement projects deserve their own scope. Data migration, user retraining, integration rework, and running two systems in parallel all take hours that a "just switch vendors" line item will hide.
Run the same template on your own stack
Your MSP is a critical vendor to every client. You hold admin access, run agents on their endpoints, and store their passwords and network diagrams. A client who completes this review honestly will put you at the top of the list.
CISA's joint advisory on protecting against cyber threats to managed service providers and their customers tells MSP customers to make sure their contracts with the MSP cover security measures and controls. Expect that question to show up in client questionnaires, insurer forms, and procurement reviews.
Run the 12 questions against your own tools first. The categories that usually land in the critical tier:
- Remote monitoring and management
- Remote access and support tools
- Your PSA and ticketing system
- Backup and disaster recovery
- IT documentation and password management
- Email security and identity tooling
Answer each question for each tool, collect the evidence once, and keep it current. When a client sends their own vendor review, you answer from documents you already keep current. The same packet answers most of an insurer's third-party questions about your shop.
The review also shows which of your tools would sink a client if they failed. Those belong in your incident response plan, with a line for who calls each client and what they will be told.
Set the review cadence
Section 314.4(f)(3) of the Safeguards Rule ties reassessment to risk. Tiers give you that schedule:
- Critical: Full review every year, at contract renewal, and after any breach notice or major change in the service.
- Important: Questions 1 through 6 and 11 every two years, and at renewal.
- Low: Confirm the data and access answers at onboarding, and again if either changes.
Tie the cycle to the business review calendar. Review one slice of the vendor list each quarter so no single meeting turns into a vendor marathon, and bring new vendors to the next review instead of waiting for the annual pass.
New vendors are where the list drifts. Add one line to the client's onboarding or purchasing process: before anyone signs, the business owner records the data and access answers. That is the due diligence GV.SC-06 describes, done before the contract is signed.
If the vendor review sits inside a broader MSP risk assessment, use the same severity scale for both. A vendor finding and an internal finding should compete for the same budget on the same roadmap.
Copy the vendor review record
Paste this block into the client record for each critical or important vendor:
Vendor:
Product or service:
Business owner at client:
Tier: Critical / Important / Low
Data held:
Access to client systems:
Contract renewal date and notice period:
Questionnaire sent (date):
Answers received (date):
Scores (Q1 to Q12):
Must-pass results:
Findings:
Decision per finding: Fix with vendor / Roadmap item / Accepted risk / Replace
Decision owner and date:
Next review date:
Evidence location:
The evidence location line matters most. When the insurer or auditor asks how vendors are reviewed, the answer should be a folder path and a date.
Where Scopable fits
Scopable keeps the vendor review inside the same client record as the rest of your advisory work. The compliance area of a client includes Frameworks, Risks, Gaps, Action Plans, and a Vendor Register, and you can save filtered views of those tables and reuse them across clients.
Scopable's GRC workflow lets you attach a framework to a client, track gaps with severity, and turn a finding into a roadmap item, accepted risk, scoped remediation project, or quote. Legal and audit judgment stays with the client's counsel and auditor. The vendor decisions, the evidence trail, and the follow-up work stay in one place, so next year's review starts from what changed.
Frequently Asked Questions
What should an MSP vendor risk assessment include?
List each vendor with its business owner, the client data it holds, and its access to client systems. Tier it as critical, important, or low, ask a short questionnaire covering access, MFA, independent assurance, subprocessors, breach notification, and exit, then score the answers and record a decision for every weak one.
How should an MSP tier a client's vendors?
Tier by what the vendor can reach. Critical vendors hold regulated or sensitive data, have admin or standing access, or stop the business when they go down. Important vendors hold internal data or user-level access. Low vendors hold no client data beyond contact details. When a vendor sits between two tiers, use the higher one.
How often should an MSP reassess client vendors?
Base the cadence on risk, which is also how the FTC Safeguards Rule frames periodic assessment. A workable schedule is a full review of critical vendors every year and at renewal, a shorter review of important vendors every two years, and a data and access check for low vendors at onboarding.


