The MSP & MSSP guide to vendor risk management

1. Why MSP/MSSP vendor risk is different

An enterprise security team manages the third parties of one company. An MSP or MSSP manages the third parties of dozens or hundreds - and is itself one of those third parties for every client it serves. That creates a specific shape of risk that generic TPRM guidance does not address.

The reason regulators keep singling MSPs out isn't hypothetical. The 2021 Kaseya VSA compromise reached roughly 1,500 downstream businesses through 50–60 MSPs. SolarWinds Orion inserted a nation-state backdoor into 18,000 customer environments through a single trusted update. The 2024 CDK Global outage stopped roughly 15,000 dealerships trading for three weeks. In each case one supplier's control failure became the operational failure of a long tail of customers who had no direct relationship with the attacker.

That concentration risk is why CISA, NCSC-UK, ACSC, CCCS, NSA and the FBI published the joint advisory Protecting Against Cyber Threats to Managed Service Providers and their Customers - and why every serious framework (CIS Controls v8.1, NIST CSF 2.0, ISO 27001:2022, DORA) has since promoted supplier and third-party risk to a first-class control domain.

For an MSP or MSSP the practical implications are:

• You inherit your clients' vendors. Every SaaS a client uses is now something you're implicitly on the hook for during an incident, whether or not you procured it.
• You are a vendor. Your own security posture is assessed by every client you serve. The programme you build for clients is also the one you'll be audited against.
• You have concentration exposure across the book. If 60% of your clients use the same finance SaaS and it breaches, your inbox lights up 60% at once. Portfolio-level visibility isn't a nice-to-have.
• Your buyers are increasingly regulated. A client in EU financial services (DORA), Australian critical infrastructure (SOCI Act), or UK healthcare (DSPT) will contractually push their third-party obligations onto you.

2. The regulatory floor

Before designing anything, know the floor. These are the sources that define "reasonable" vendor risk for an MSP or MSSP today. When a client's auditor, insurer or regulator asks you to defend a decision, this is the shelf they'll cite.

CISA joint MSP advisory (2022, still current)

The single most-cited document for MSP-specific controls. Six action areas: prevent initial compromise, enable monitoring and logging, secure remote access (with MFA the non-negotiable), develop incident response playbooks that include the customer, apply the principle of least privilege between MSP and customer, and manage supply-chain risk in your own tooling stack. If your programme cannot answer to this document line-by-line, start here.

NIST - the three that matter

• NIST CSF 2.0 added a full Govern (GV) function in 2024, and inside it the GV.SC - Cybersecurity Supply Chain Risk Management category. This is now the default framing for supplier risk in US-influenced markets.
• NIST SP 800-161r1 is the deep reference for supply-chain risk management - long, but the appendix control catalog is the source most other frameworks map back to.
• NIST SP 800-53r5 control families SR (Supply Chain Risk) and CA (Assessment) contain the concrete controls (SR-3, SR-5, SR-6, CA-2, CA-7) that a mature programme will map to.

NCSC-UK and the CAF

NCSC's Cyber Assessment Framework Principle A4 - Supply Chain - is the UK equivalent, and is what the Cyber Essentials Plus and DSPT assessments increasingly reference. NCSC also publishes MSP-specific guidance that mirrors the CISA advisory.

ISO/IEC 27001:2022 & SOC 2

ISO 27001's Annex A now dedicates four controls to supplier relationships: A.5.19 (Information security in supplier relationships), A.5.20 (Addressing information security within supplier agreements), A.5.21 (Managing information security in the ICT supply chain) and A.5.22 (Monitoring, review and change management of supplier services). SOC 2's CC9.2 criterion is the AICPA equivalent. If your clients hold either certification, these are the exact clauses your vendor process needs to satisfy.

DORA (EU 2022/2554)

Applicable from January 2025 across EU financial entities. If you serve one, DORA's ICT third-party risk chapter - the register of information, criticality classification, mandatory contractual provisions, exit strategies, and threat-led penetration testing - flows through the contract to you. The European Supervisory Authorities' Regulatory Technical Standards spell out the format.

Sector overlays worth knowing

• APRA CPS 230 - Australia's operational risk standard for APRA-regulated entities. Effective July 2025. Material service providers are named individually and monitored.
• ACSC Essential Eight - the maturity model most Australian government and enterprise buyers evaluate against.
• ENISA Threat Landscape for Supply Chain Attacks - the best current evidence base on attacker behaviour, useful when you need to justify a control to a sceptical client.
• CompTIA MSP+ / Trustmark - buyer-facing MSP-specific baselines. Worth aligning to for market signalling.

3. The 6-pillar operating model

Every framework above lands on a similar shape once you strip the language. This is the working model we recommend MSPs and MSSPs operationalise. Six pillars, each with a defined owner, artefact and cadence.

Pillar 1 - Vendor inventory & discovery

You can't manage what isn't listed. The inventory has to be per-client (not one master sheet across the firm) and it has to include shadow SaaS - the things procurement never saw. Discovery today means pulling from IdP sign-in logs (Google Workspace, Microsoft Entra), expense data where you have access, and MDM telemetry. Aim for a known-unknowns count in every monthly review: how many discovered apps are still un-triaged?

Pillar 2 - Tiering by criticality

Tier before you assess. Depth of assessment, cadence, evidence requirements and escalation paths all flow from the tier. The tiering criteria that hold up under audit are:

• Data sensitivity (personal data, financial data, regulated data, IP)
• Business criticality (would a 24-hour outage stop trading?)
• Access scope (customer environments, production systems, admin)
• Integration depth (SSO, SCIM, API keys, agents on endpoints)
• Volume of downstream dependency (used by how many other systems?)

A vendor that scores high on any two of the above is Tier 1. High on one, Tier 2. The rest is Tier 3.

Pillar 3 - Evidence collection

Evidence is what makes an assessment defensible. The standard set for a Tier 1 vendor is: current SOC 2 Type II report or ISO 27001 certificate with statement of applicability, a recent penetration test executive summary (last 12 months), a signed Data Processing Agreement with sub-processor list, and evidence of a live incident response and business continuity capability. Everything else (insurance certificates, product-specific security whitepapers, status page history) is nice to have.

A tiered evidence strength model is what separates a real programme from a checklist. A vendor-uploaded PDF is weaker than an auditor-issued attestation letter, which is weaker than an item you verified in a public registry (CSA STAR, the ISO 27001 IAF CertSearch database, the AICPA SOC report search). Reflect that difference in scoring.

Pillar 4 - Assessment cadence

Annual-for-everything is expensive and low-signal. Tie cadence to tier:

• Tier 1 - full assessment annually, continuous monitoring in between, mandatory review on any trigger event.
• Tier 2 - full assessment every 18–24 months, monitoring on breach and certification-lapse feeds only.
• Tier 3 - assess on renewal or on trigger. Otherwise leave alone.

Trigger events that should force an off-cycle review: publicly disclosed breach, change of sub-processor, change of hosting region, change of ownership, lapsed certification, material change to the product's data model, or a customer complaint.

Pillar 5 - Continuous monitoring

Between assessments you need signal. The cheap, high-value sources are: breach disclosure feeds (HIBP, national CERT feeds), certificate transparency logs for the vendor's domain, DNS/security-header posture monitoring, and sub-processor page diffing. Anything more expensive should be justified by tier count - dedicated continuous rating services only pay off on a large Tier 1 population.

Pillar 6 - Offboarding & contract lifecycle

This is the pillar MSPs most often skip. When a vendor is terminated, the contract obligations don't end - data return or destruction certificates, revocation of API keys and SSO connections, confirmation of backup deletion, and closure of any shared support channels. Track the offboarding as a workflow with a completion certificate, not an email. DORA and ISO 27001 A.5.22 both make this explicit.

4. Assessment depth by tier

A concrete matrix. Adjust the exact controls to the framework your client is audited against, but the shape should hold.

5. Questionnaire strategy

The single biggest determinant of assessor throughput is questionnaire discipline. Three rules:

Standardise where you can, customise where it counts. Use an off-the-shelf baseline for common ground - the Shared Assessments SIG Lite (about 130 questions) or the Cloud Security Alliance CAIQ (about 260) - then layer 5–15 client-specific questions for sector or data considerations. Don't hand-write a full questionnaire per vendor.

Map every question to a control. Every question needs to answer "if the answer is bad, which control fails?" If it doesn't, cut it. This is what makes the assessment output useful for the client's own audit rather than a curiosity.

Weight by outcome, not word count. "Do you have MFA enforced for all administrative access?" is worth more than "Describe your password rotation policy." The second question is a proxy for the first and shouldn't carry independent weight.

For short-form MSP work, a 25–30 question core covering identity, data protection, incident response, business continuity, and sub-processor governance will screen 80% of the risk of most SaaS. Reserve the full SIG or CAIQ for Tier 1.

6. Scoring & risk acceptance

A useful score is deterministic (two assessors produce the same number), transparent (the client can see how it was derived), and actionable (the number changes something).

We recommend a deduction model with fatal flaws: start at 100, deduct points for each failed control weighted by impact, and cap the score at a fatal-flaw ceiling if a non-negotiable is missing. Fatal flaws that should cap the score regardless of the rest of the assessment:

• No MFA enforced on administrative access
• No encryption at rest for the customer data
• No documented incident response process or breach SLA
• No sub-processor disclosure
• No evidence of a recent independent assessment (SOC 2, ISO, pen test)

Publish the scoring rubric to the client. A score that a client can't reproduce isn't a score, it's an opinion. Attach a letter grade (A–F) for executive reporting and keep the raw number for analyst work.

Risk acceptance is where a lot of programmes fall apart. Any residual risk above the client's stated threshold should be formally accepted, in writing, by a named individual on the client side, with an expiry date. "The CIO knows" is not risk acceptance.

7. The vCISO angle

A vCISO runs a portfolio version of this. The failure mode is spending 80% of billable hours on assessment mechanics for the same 15 SaaS vendors that appear across every client. Two rules keep the margin:

Amortise vendor assessments across the practice. A completed assessment of Microsoft 365, Google Workspace, or HubSpot is portable across clients. Store one canonical assessment per common vendor, expose it to each client with client-specific risk acceptance and data-flow context on top. Do the deep work once, deliver it many times.

Sell the programme, not the assessment. A per-client monthly retainer for vendor governance (inventory maintained, new-vendor triage within N business days, quarterly executive report, annual full reassessment of critical vendors) scales. Selling a fixed-fee assessment per vendor does not.

A vCISO practice serving 15 clients should be reusing at least 60% of vendor assessment content across clients within 12 months. Anything less means the amortisation isn't working.

8. The MSSP angle

For an MSSP, vendor risk is a product line, not a project. The packaging that works in market today:

• Base tier - inventory, tiering, monitoring, one Tier 1 assessment per quarter. Priced as a per-client monthly fee.
• Assessment credits - additional deep assessments (Tier 1 full, custom questionnaires, contract review) sold as a pack of credits, drawn down through the year.
• Incident response add-on - priority triage when a vendor in the client's inventory has a disclosed breach.

SLAs to publish: time-to-triage on newly discovered vendors, time-to-notify on a monitored breach event, and time-to-assessment for a client-requested vendor review. These are the numbers procurement will ask for.

Concentration reporting is a differentiator few MSSPs offer. A quarterly report to the client showing "these are the five vendors most of your critical dependencies terminate at, and here is their aggregated health score" turns technical assessment work into board-level narrative.

9. Common pitfalls

• Spreadsheet sprawl. A shared Excel of vendors is fine for the first 20. Past 50 it becomes the source of the risk, not the record of it. Move to a system with per-client isolation, evidence storage, and audit trails before you feel forced to.
• Stale evidence. A SOC 2 report from 2023 is not evidence in 2026. Every artefact needs an expiry date on the record and a mandatory refresh workflow.
• Ignoring 4th parties. Your vendor's vendors are where most breaches now originate. At Tier 1, require a current sub-processor list and treat it as part of the inventory.
• No exit plan. Most vendor contracts get signed without anyone asking how the data comes back. That's the DORA lever, and it's a good idea regardless of DORA.
• Assessment theatre. Long questionnaires, beautifully rendered, that don't map to a control and don't change a procurement decision. If nothing about the vendor relationship changes after an assessment, the assessment isn't earning its keep.
• Framework drift. Starting on NIST CSF, moving to ISO 27001, ending up somewhere bespoke. Pick one operating framework (we recommend CIS Controls v8.1 Control 15 or CSF 2.0's GV.SC) and map everything else back to it.

10. A 90-day rollout

A practical sequence for standing up the programme, either on your own firm or on a first-mover client.

Days 1–30: Inventory & tiering

1. Pull IdP sign-in logs (Entra, Google Workspace) for the last 90 days.
2. De-duplicate and normalise the vendor list.
3. Apply the tiering criteria above; every vendor gets a tier.
4. Assign an owner on the client side for each Tier 1 vendor.
5. Publish the inventory as the baseline. This is deliverable #1.

Days 31–60: Evidence & short-form assessments

1. Request current evidence for every Tier 1 vendor.
2. Run the short-form assessment on every Tier 2 vendor.
3. Log fatal flaws and quick wins; escalate the fatal flaws.
4. Stand up the monitoring feeds (breach, certificate expiry, sub-processor).

Days 61–90: Governance & reporting

1. Run the first full Tier 1 assessment (pick the highest-exposure vendor).
2. Produce the first executive report: risk distribution by tier, top five findings, aged remediation items, monitoring alerts closed.
3. Formalise risk acceptance for anything above threshold, in writing.
4. Set the recurring cadence - a monthly working review with the client operations lead, a quarterly executive review, an annual full reassessment cycle.

Ninety days in, the client has an evidenced inventory, a tiered population, a first executive report, and a live monitoring feed. That's a defensible programme. Depth comes with the next quarters.

Sources & further reading

Every claim in this guide traces back to one of these documents.

• CISA, NCSC-UK, ACSC, CCCS, NSA, FBI - Protecting Against Cyber Threats to Managed Service Providers and their Customers (AA22-131A)
• NIST - Cybersecurity Framework 2.0 (GV.SC - Supply Chain Risk Management)
• NIST SP 800-161r1 - Cybersecurity Supply Chain Risk Management Practices
• NIST SP 800-53r5 - Security and Privacy Controls, SR and CA families
• NCSC-UK - Cyber Assessment Framework, Principle A4 (Supply Chain)
• ISO/IEC 27001:2022 - Annex A.5.19 through A.5.22 (Supplier Relationships)
• AICPA SOC 2 (2017 TSC, revised 2022) - CC9.2 Vendor and Business Partner Risk
• CIS Controls v8.1 - Control 15: Service Provider Management, cisecurity.org/controls
• ENISA - Threat Landscape for Supply Chain Attacks
• EU Regulation 2022/2554 - Digital Operational Resilience Act (DORA)
• Cloud Security Alliance - STAR Registry and CAIQ
• Shared Assessments - SIG and SIG Lite Questionnaires
• APRA CPS 230 - Operational Risk Management (Australia, effective July 2025)
• ACSC - Essential Eight Maturity Model
• CompTIA - Cybersecurity Trustmark for MSPs