An MSP does not become 'CMMC compliant for the client' by signing a questionnaire. Defense-contractor clients need the MSP to explain which services touch CUI assets, which MSP tools provide security protection, who has administrative access, and what evidence the MSP can supply.
For a resource-constrained defense contractor, the practical test is not whether a policy exists on paper, but whether the requirement is implemented inside the defined FCI/CUI boundary, assigned to an owner, and backed by current, checkable evidence.
The rule in plain English
CMMC scoping can include external service providers and security-protection assets depending on how services are delivered. The MSP should know which remote-management, backup, logging, identity, ticketing, and security systems interact with the client's environment.
The client's assessment still evaluates the client's scoped environment, but the MSP may hold essential evidence and operate controls the client relies on.
How to implement it without overbuilding
Build a client-specific service map listing tools, access paths, data handled, administrator roles, support locations, logs, and contractual responsibilities.
Create exportable evidence packages rather than forcing assessors to rely on live vendor portals or marketing attestations.
What evidence to keep
Keep technician-access records, privileged-role lists, tool architecture, logging/monitoring records, change tickets, incident procedures, personnel controls, and provider information relevant to the service.
Be ready to distinguish MSP corporate systems from client-dedicated components.
Where teams get into trouble
The biggest problem is saying 'our stack is CMMC compliant' without defining scope. Another is using one multi-tenant admin platform with broad access and no client-specific access evidence.
Small-contractor walkthrough
An MSP administers endpoints, backups, firewalls, identity, and security monitoring for several defense clients. Each client will need a clear map of which MSP tools and technicians can reach its environment and which client-specific evidence the MSP can produce.
- Map every tool touching the client.
- Minimize MSP admin access.
- Create client-specific logging.
- Document shared responsibility.
An MSP becomes an ESP based on what its systems actually handle
Under 32 CFR Part 170, an External Service Provider relationship depends on external IT or cybersecurity services where provider assets process, store, or transmit CUI or Security Protection Data. For an MSP, SPD can include logs, configurations, alerts, and other data used to protect the client's CUI system. This means an MSP can be relevant to client scope even when technicians are told never to place obvious CUI in a ticket.
Inventory provider-owned platforms used for each defense client: RMM, PSA/ticketing, documentation vaults, password managers, backup consoles, EDR/MDR, SIEM/SOC, identity administration, vulnerability tools, remote support, network management, email security, and technician administration systems. For each, determine whether CUI or SPD is processed, stored, or transmitted and whether the service is a CSP or non-CSP under the rule.
Clients will expect a service description and a usable CRM
32 CFR 170.19 requires the ESP relationship and services to be documented in the contractor's SSP and described through the service description and Customer Responsibility Matrix. The CRM should explain who implements each relevant requirement or objective, which responsibilities are shared, what evidence the MSP provides, and what remains with the client. 'MSP handles IT' is not enough.
Build an evidence package before a client requests it: service architecture, client-specific admin roles, technician access process, security configuration, change records, monitoring records, backup tests, patch/vulnerability records, incident workflow, personnel/access controls, and a repeatable client-specific export from multi-tenant systems. A provider that cannot separate one client's evidence from another creates assessment and privacy problems.
The MSP contract should support the evidence model
Put operating responsibilities into the agreement: who approves privileged access, who receives alerts, who authorizes firewall changes, who owns vulnerability remediation, how HR events reach the MSP, what data may enter tickets, how quickly evidence can be supplied, how provider changes are communicated, and what happens at termination. Keep the service description and CRM maintained as living service artifacts.
An MSP does not need to make a vague company-wide claim that it is 'CMMC compliant.' It needs to describe the actual service boundary and produce evidence for the controls and data it handles. If the provider voluntarily obtains its own CMMC status for an applicable scope, document exactly which services and systems that status covers.
Test the contract operationally. Pick a termination, firewall change, security alert, restore request, and privileged support case from the last period and verify the actual handoff matches the CRM and service agreement. Rewrite the responsibility model when practice and contract differ.
A short working check
- ✓Map every tool touching the client.
- ✓Minimize MSP admin access.
- ✓Create client-specific logging.
- ✓Document shared responsibility.
- ✓Prepare evidence exports.
- ✓Review subprocessors.
Common questions
Does an MSP need its own CMMC certificate?
That depends on contractual and scoping facts. Analyze what systems process, store, transmit, or protect the client's FCI/CUI.
Will assessors interview MSP staff?
They may need evidence or explanations from people operating controls relied on by the client.
Are RMM tools relevant?
Yes. They can provide privileged access and security-protection functions.
What should the MSP contract say?
Clearly describe services, responsibilities, data handling, incident notification, access, evidence support, and limitations.
Does an MSP become an ESP just because it has a defense client?
Not automatically. Under the CMMC definition, the provider becomes an ESP when its assets process, store, or transmit CUI or Security Protection Data while providing IT/cybersecurity services.
Official sources used for this guide
Open the primary source before making a contract-specific decision. Regulations and program implementation can change.
