MSPs, MSSPs, and External Service Providers in CMMC Scope

Decompose the service before classifying it

Create one row for each provider function: endpoint management, help desk, identity administration, vulnerability scanning, EDR, SIEM, backup, firewall management, cloud administration, or incident response. For each row, identify assets reached, permissions, data collected, management path, storage location, and provider personnel involved.

This prevents the scope analysis from being driven by the vendor's company name. One MSP may provide both a low-risk ticketing service and highly privileged endpoint management. Those functions can have different scoping and evidence implications even though they come from the same contract.

The Department's 2026 CMMC FAQ adds an important nuance: an MSP that is not itself a cloud offering does not automatically need its own separate CMMC certification, but relevant MSP/MSSP/ESP services can still be assessed as part of the OSA's scope. A provider that handles security-protection functions or data can matter even when it never receives a business document labeled CUI. Scope the service relationship by function and access, not by whether the vendor owns a certificate.

Build a shared-responsibility matrix at requirement level

Map applicable security requirements to the party that implements, operates, monitors, and evidences them. Some controls may be entirely contractor-owned, some provider-owned, and many shared. The matrix should identify a named evidence source rather than a vague note that says 'MSP responsibility.'

Review the matrix with the provider. If the provider believes the contractor owns a task that your SSP assigns to the MSP, resolve the disagreement before an assessment. Shared-responsibility gaps are often documentation gaps first and technical gaps second.

Contract terms should support the technical story

Security requirements are difficult to prove if the service agreement does not give the contractor access to evidence or timely incident information. Address incident notification, after-hours escalation, log retention, privileged-personnel controls, subcontractors, data location, forensic cooperation, audit or evidence access, and termination obligations.

Do not wait until an assessor asks for a log sample to discover that the provider treats all evidence as confidential and will take 30 days to release it. Procurement and security should agree on evidence needs before renewal or onboarding.

Provider marketing language is not your assessment result

Claims such as 'CMMC ready,' 'NIST compliant,' or 'FedRAMP aligned' can be useful starting points for diligence, but they do not describe your full system boundary. Ask what exact service and evidence the claim covers, then map that to the requirements and architecture you are responsible for.

Avoid copying provider claims into the SSP without qualification. A stronger statement explains what the provider does, which service boundary is involved, what evidence supports the function, and what responsibilities remain with the contractor.

Privileged access deserves separate scrutiny

List all provider-administered accounts, remote-management tools, service accounts, API tokens, and break-glass methods that can change the CUI environment. Review MFA, device restrictions, session logging, approval, account lifecycle, and how provider personnel are authorized. Privilege often matters more than whether the provider stores CUI files.

Run a sample access review with the provider at least quarterly. Confirm that departed technicians, obsolete tools, and old emergency accounts are removed. Keep the evidence. This one process supports both security and a clearer assessment story.

Treat provider replacement as an architecture change

Offboarding an MSP can change agents, identities, logging, backup, firewall administration, help-desk workflows, and incident contacts at the same time. Plan credential revocation, tool removal, data and log return, deletion confirmation, knowledge transfer, and evidence preservation before the final day of service.

Update the SSP, diagrams, asset inventory, responsibility matrix, and incident runbook as part of the transition. A provider change that is handled only as a procurement event can leave the documented CMMC environment several months behind the system that actually exists.

Questions to ask an MSP before the assessor does

Ask the provider to show which privileged accounts can reach the CUI environment, how those accounts are approved and removed, what MFA and device controls protect them, and what logs exist for remote sessions. Then ask where management telemetry and support data are stored and whether subcontractors can access those systems.

Ask how quickly the provider will notify you of a suspected incident that might affect the environment. Compare that answer with your own 72-hour reporting obligations where DFARS 252.204-7012 applies. A standard SLA written for ordinary IT outages may be far too slow for cybersecurity escalation.

Ask how you will obtain evidence during an assessment. Can the provider produce configuration exports, account lists, log-retention settings, change records, vulnerability results, and incident-test records within a few business days? If evidence access requires executive approval at the provider, build that path before assessment week.

Finally, ask what happens at termination. You should know how accounts and agents are removed, how logs and tickets are returned or retained, how data is deleted, and who confirms the transition. Provider exit is part of scope management, not merely procurement paperwork.

Maintain a provider evidence calendar. Some artifacts arrive annually, some quarterly, and some only on request. Track contract renewal, independent assessment reports, penetration or vulnerability summaries where available, incident-contact tests, privileged-access reviews, and service changes. This prevents assessment preparation from becoming a scramble to ask the provider for documents that its own review cycle will not produce for months.

When the provider uses its own subcontractors or tooling, record what is material to your environment. You do not need to map the provider's entire corporate ecosystem, but you should understand relevant sub-processors, remote-support platforms, and data locations when they can affect privileged access, telemetry, incident response, or evidence. Contract notification of material changes can help keep this dependency current.

Include provider changes in annual affirmation preparation. Ask whether privileged technicians, tools, service locations, sub-processors, evidence sources, or incident contacts changed since the last review. A stable contract name can hide a materially different service. The contractor's SSP and responsibility matrix should describe the current delivery model, not the provider relationship as it looked when the agreement was first signed.

During renewal, ask for one real evidence retrieval before signing. Choose an artifact the contractor would reasonably need during an assessment—such as a privileged-account list or relevant configuration record—and have the provider produce it through the normal support process. The exercise reveals lead time, approval barriers, format limitations, and data-sharing restrictions while there is still leverage to fix the contract. A responsibility matrix is stronger when the promised evidence can actually be obtained.

Official sources used for this guide

Open the primary source before making a contract-specific decision. Regulations and program implementation can change.