MSP, Vendor, and CSP Oversight

Why Vendor Oversight Matters

Most contractors have no internal IT department large enough to handle every aspect of compliance themselves. The MSP administers the network. A cloud provider hosts the email. A SaaS vendor handles the engineering CAD repository. A support contractor manages the ticketing system. Every one of those relationships extends your authorization boundary outward — and the controls those vendors implement (or fail to implement) become part of your compliance posture.

From an assessor's perspective, there is no distinction between "things you control directly" and "things your vendors control." If a vendor's failure causes your environment to be non-compliant, the finding lands on you. The vendor isn't certified — you are. The contract is between you and the government; the vendor is your problem.

Vendor oversight under CMMC is therefore not a procurement exercise. It is a security exercise: knowing which vendors handle in-scope assets, what their security posture is, what controls they're responsible for, and what evidence supports their compliance. The work happens before the assessment, not during.

Three Vendor Types

The distinctions matter because the compliance obligations differ. An MSP with persistent privileged access to your in-scope environment is fundamentally different from a payroll vendor that processes employee names and hours. Treating them the same way over-invests in oversight of low-risk vendors and under-invests in high-risk ones.

When Vendors Are In Scope

A vendor relationship pulls into CMMC scope when any of the following is true:

• The vendor stores, processes, or transmits CUI. A cloud-hosted CUI repository, a secure file-transfer service that handles CUI exchange, an encrypted communication platform that carries CUI — all in scope.
• The vendor has access to systems that handle CUI. An MSP with administrative access to your CUI server is in scope, regardless of whether the MSP technicians ever read the actual CUI files. The access alone creates the scope.
• The vendor's services are part of your CUI workflow. A CAD tool used to work with CUI drawings, a PLM system that manages CUI engineering data, an analytics tool that processes CUI as input — all in scope as part of the workflow that handles CUI.
• The vendor is contractually a subcontractor handling CDI. See the DFARS flow-down guide; a sub handling CDI must comply with all 7012 obligations.

A vendor relationship is generally out of scope when the vendor:

• Has no access to in-scope systems
• Does not handle CUI
• Provides a service that does not involve in-scope data flows (e.g., a public-facing marketing website hosted on commercial cloud, with no CUI in the workflow)

The boundary determination must be made vendor-by-vendor. A vendor inventory listing each vendor, the service provided, the in-scope/out-of-scope determination, and the rationale is a worthwhile artifact for the assessment.

External Service Providers (ESPs)

The CMMC Final Rule introduces the concept of an "External Service Provider" — an entity that provides specific services to the contractor that affect the contractor's ability to meet CMMC requirements. The rule places obligations on contractors with respect to their ESPs:

• The contractor must identify ESPs in the SSP. The SSP must list ESPs whose services affect compliance, with the specific controls each ESP supports.
• ESPs that handle CUI may themselves require CMMC certification. An MSP whose technicians have privileged access to a contractor's CUI environment is, under the rule, an ESP — and depending on how the rule is interpreted in practice, may need to be CMMC certified at the appropriate level. The interpretive guidance is still evolving; track the CMMC PMO's published clarifications.
• The contractor remains responsible for the ESP's controls. Even where the ESP has its own certification, the contractor's SSP must document the relationship and the contractor must verify the ESP's compliance through evidence.

The practical implication: when you select MSPs and CSPs going forward, the question "is this vendor itself CMMC certified?" matters. An MSP that is CMMC Level 2 certified is operationally and contractually easier to work with than one that is not. The available pool of CMMC-certified MSPs is small but growing rapidly.

Contractual Requirements

Every in-scope vendor relationship needs contractual terms that bind the vendor to security obligations consistent with the contractor's CMMC posture. The specifics vary by vendor type, but the categories below should appear in some form:

The Customer Responsibility Matrix

For every CSP in your authorization boundary, the Customer Responsibility Matrix (CRM) is the document that defines who is responsible for which controls. The CRM is published by the CSP and varies by service. Microsoft publishes CRMs through the Service Trust Portal; AWS publishes them through Artifact; PreVeil and Kiteworks publish CRMs through their respective compliance documentation pages.

Each control in the CRM is categorized as:

• Inherited (or "Provider-Provided"): The CSP fully implements the control; the customer relies on the CSP's implementation
• Shared: Both the CSP and customer have responsibilities (the CSP provides the capability; the customer must configure it correctly)
• Customer-Responsible: The CSP provides no implementation of this control; the customer must implement it independently

For CMMC purposes, you must document in your SSP which controls you inherit, which are shared, and which you implement directly. The shared controls are where most operational findings cluster, because they require the customer to actually configure the platform correctly — and the most common failure is leaving the platform at default settings.

Reading the CRM is not optional. A common assessor question is "show me your CRM for [CSP] — and show me how you've implemented the customer-responsible controls." Not having the CRM (or having it but not having internalized it) is a common finding.

Evidence to Collect

For each in-scope vendor, your evidence package should include:

• Contract or master service agreement incorporating the security clauses described above
• Customer Responsibility Matrix (for CSPs) — current version, with the customer-responsible controls mapped to your SSP
• FedRAMP authorization confirmation (for CSPs handling CUI) — Marketplace listing screenshot or equivalent
• SOC 2 Type II report or equivalent from the vendor (annual)
• Vendor security questionnaire response documenting the vendor's relevant security posture
• For MSPs: list of named technicians with US-person status (if relevant) and date of last background check
• For MSPs: privileged access logs showing what vendor personnel accessed, when
• Vendor incident notifications (any incidents reported by the vendor, the response taken, the lessons learned)
• Records of vendor access reviews — periodic confirmation that the vendor's access is still appropriate and limited to the named personnel
• Vendor offboarding records for any vendor relationships that have ended — confirmation that data was returned or destroyed and access was revoked

The vendor evidence is part of your overall evidence library. Treat it with the same freshness discipline — vendor questionnaires from three years ago are not useful; current ones are.

MSP Selection Questions

If you're selecting an MSP for the first time, or evaluating an existing MSP for CUI work, the questions below cover the relevant ground. Treat as an initial filter; expect detailed follow-up on the answers that matter most.

Sample Vendor Contract Clause

Below is a plain-language sample clause for a CUI-handling vendor (MSP, software vendor with system access, etc.). Adapt for your specific situation; have legal counsel confirm before use.

Authoritative References