CMMC External Service Providers: Scope and Evidence

CMMC external service providers do not enter scope because procurement calls them critical. They enter through a real CUI or security protection path.

That path is where most provider scope decisions go wrong. One team marks every supplier in scope and creates an impossible evidence burden. Another team checks only who stores CUI and misses the security service that holds logs, configuration, vulnerability detail, and privileged access. A third team collects a provider certificate and assumes all customer duties disappeared.

CMMC external service providers are not a vendor inventory problem. They are a service boundary problem. Trace what the service does, where the data resides, which identities and settings the customer controls, which records prove operation, and who can answer or test the implementation. Then decide the required provider state.

This guide belongs to the CMMC compliance hub and supports the secure AI and regulated automation service. Use it with the CMMC scoping guide, the assessment evidence guide, the CMMC enclave architecture guide, the guide to secure cloud architecture for CUI, and the CMMC assessment findings guide.

CMMC External Service Providers: The Short Answer

Start with the service, not the supplier name. Record its people, assets, interfaces, privileges, data stores, transfers, security functions, and customer settings. Test whether CUI or security protection data resides on provider assets. Classify the service as a cloud service, another provider type, or staff working in the contractor environment. Then map every in scope requirement to the company, provider, shared, or not applicable treatment and identify the proof.

A provider can matter without storing CUI. A security monitoring service, identity service, endpoint tool, or vulnerability platform may store data that protects the assessed environment. The provider may not need its own CMMC status, yet its functions and evidence can still be assessed as part of the organization seeking assessment.

Current Program Timing Does Not Remove Provider Risk

The current DoD CMMC program page states that Phase II requirements were suspended on July 13, 2026, while Phase I self assessments remain active. Current enforcement focuses on NIST SP 800-171 Revision 2 self assessments and selected government led assessments. Confirm the live solicitation, award, required level, assessment type, and current DoD direction before demanding a provider certification for a date that no longer applies.

The pause does not change an applicable DFARS safeguarding duty. It does not make a cloud service acceptable for CUI merely because a planned certification assessment moved. It does not make an undocumented provider dependency disappear from the system security plan or self assessment. Prepare the service evidence now, but let the contract and current program instruction decide the formal status path.

The Two Provider Scope Entry Paths

The DoD CMMC Level 2 Scoping Guide Version 2.13 says an external provider is in scope when CUI or security protection data resides on provider assets. Both words matter. The guide does not say every supplier is an ESP. It does not limit the analysis to CUI.

CUI is the contract information being protected. Security protection data is information used to protect the assessed environment. The guide gives examples that include log data, configuration data, vulnerability information, and passwords. A managed security service can therefore enter the assessment scope through the protective service even when the service is designed not to store CUI.

Data must actually reside on the provider assets for the official ESP entry test. A person employed by a service firm who uses only the contractor's processes, technology, and facilities may be staff augmentation rather than a separate provider assessment path. Document the facts. A job title cannot settle the boundary.

CSP, MSP, MSSP, and Staff Are Not Interchangeable

A cloud service provider supplies on demand network access to a shared pool of configurable computing resources. A managed service provider operates or administers technology for the contractor. A managed security service provider performs security functions such as monitoring, endpoint protection, identity administration, vulnerability management, or incident support. One supplier can occupy more than one role.

The current DoD CMMC Frequently Asked Questions adds needed nuance. An MSP or MSSP that does not process, store, or transmit CUI but does handle security protection data can be assessed as part of the customer scope without its own CMMC status. A provider employee using the customer's licensed tenant does not automatically turn the provider into the cloud service provider. The facts can change if the provider contracts for and modifies the cloud service as its own offering.

There is also a point that deserves a written decision. The Level 2 Scoping Guide decision table says a noncloud ESP with CUI requires a CMMC assessment. The current FAQ says a noncloud MSP that stores CUI is not required to hold its own CMMC assessment, though it may elect one, and the service remains part of the customer scope. These statements should not be flattened into a universal rule. Apply the current FAQ, guide, contract, provider role, and service facts together. When the result affects bid eligibility, get the interpretation in writing from the appropriate contract or program authority.

GS CMMC Provider Scope and Evidence Pressure Index

GS Consulting built a derived planning model to compare twelve common service patterns. Each pattern receives a one to five analyst rating for CUI contact, security function, privileged reach, data persistence, and provider evidence dependency. Base weights are 30, 25, 20, 15, and 10 percent. The weighted result is scaled from zero to 100.

The alternate model moves five points from CUI contact to security function. A managed enclave provider with CUI scores 100. A cloud service provider hosting CUI scores 91. A managed security service with security protection data and a backup service holding CUI both score 82. The top two positions do not change, and no score moves by more than three points.

The score is not an official scope or assurance result. Low scoring patterns still require factual review. A business application that holds no CUI or protection data can move into scope after a workflow change, integration, support practice, or new report. The model helps sequence provider reviews. It does not replace them.

Use the Official Branches, Then Resolve the Details

For a cloud service that processes, stores, or transmits CUI, start with the contract cloud requirement and the accepted FedRAMP Moderate path. For a cloud service without CUI, the FedRAMP trigger tied to CUI may not apply, yet the service can remain in the customer assessment scope when it provides a protection function.

For another provider type with CUI, resolve the guide, current FAQ, contract, and exact service role. Do not accept a sales claim that the service is simply out of scope. For another provider without CUI but with security protection data, its own CMMC status may not be required, but the relevant functions are assessed as part of the customer system.

A current provider certificate or assessment state can validate a portion of the provider implementation. The Cyber AB assessment process still expects the team to confirm that the covered scope matches the service and that the assessed state has been maintained. A certificate is evidence. It is not a substitute for the service map.

Decide Scope in Five Stages

Start with one service description. Name the business purpose, provider people, provider assets, contractor assets, interfaces, identities, privileges, data stores, transfers, and customer settings. Draw the path. If the diagram cannot show where CUI and protection data go, the scope decision is not ready.

Classify the provider role next. Then test both data paths. Assign every relevant requirement in a current customer responsibility matrix. Finally, prove the implementation with documents, knowledgeable interviews, and repeatable tests. The Cyber AB process says an ESP interview respondent should demonstrate knowledge and ownership of the implemented requirement. A sales contact who can only forward a certificate is not enough.

Cloud and FedRAMP Need a Precise Statement

DFARS 252.204 7012 sets cloud service requirements when the clause and covered defense information apply. The current DoD FAQ says a cloud service processing, storing, or transmitting CUI must meet FedRAMP Moderate or an accepted equivalency path. It also says a cloud service that is not FedRAMP authorized cannot store CUI merely because the contractor encrypts the data.

FedRAMP does not configure the customer's tenant, assign its users, review its privileged roles, set its retention, investigate its alerts, or prove that the contractor used the service as designed. A FedRAMP package covers a defined cloud service boundary and control allocation. The contractor still needs its own configuration, responsibility, operation, and evidence record.

Ask five questions before approving the service: Does the authorization or equivalency cover the exact product and service boundary? Does it cover the deployment model and region? Which CMMC requirements remain customer owned? Which provider artifacts can the contractor legally access and share? What happens if the provider changes the service or loses the required assurance state?

Build a Provider Evidence Packet

The customer responsibility matrix is the spine of the packet. The Cyber AB process says a current matrix should name all parties and address all in scope requirements. Use four states: company, provider, shared, or not applicable. Every shared row needs a customer action, provider action, evidence source, owner, and test.

Cross reference the matrix to the system security plan. Name the service and dependency in the scope, diagram, data flow, inventory, requirement implementation, and status. Keep provider assurance records with their scope and currency. Add the customer's current settings and operating records. Preserve provider interview and test arrangements before an assessment begins.

Evidence access is a design condition. If the provider cannot supply the required record, cannot explain the control, will not support a test, or contractually bars the necessary review, record that limitation before the service is approved for the path.

Contract for Evidence, Change, and Exit

A generic requirement to maintain security is not enough. It does not name the implementation, record, owner, or response time. Shared responsibility is useful only when both sides can point to their action and proof.

Six Provider Scope Failures

Do not mark every vendor in scope without testing a CUI or protection path. Do not test only for CUI and ignore the data that protects the environment. Do not treat FedRAMP as proof of customer configuration. Do not copy a provider certificate without checking the covered service and current state. Do not accept a contract that says responsibilities are shared but names no action or evidence. Do not let a material service change bypass scope review.

Change is the quiet failure. A provider can add a region, subprocessor, identity path, support tool, backup store, log source, feature, or integration without changing the supplier name. Monitor the service design, not merely the annual vendor record.

A 30 Day Provider Scope Plan

Thirty days is a control design sprint, not a promise that every provider gap will be closed. If the service cannot provide essential evidence or the required assurance path, stop expanding use while the business chooses a replacement, containment, or documented authority decision.

Sources and Research Package

The GS model is built from official public sources checked on August 24, 2026:

• DoD CMMC Level 2 Scoping Guide Version 2.13 for ESP entry paths, provider branches, data examples, and scope records.
• DoD CMMC Frequently Asked Questions for current cloud, MSP, MSSP, provider status, and program timing explanations.
• DoD About CMMC for current Phase I and Phase II status.
• Cyber AB CMMC Assessment Process Version 2.0 for responsibility matrix, provider participation, and evidence expectations.
• DFARS 252.204 7012 and FedRAMP baselines for the contract cloud context.
• NIST SP 800-171A Revision 2 for examine, interview, and test methods.

The research package includes the source register, public signals, model inputs, derived scores, sensitivity analysis, figure data, data dictionary, methodology, editable SVG figures, browser rendered PNG files, and a formula driven workbook. The GS CMMC Provider Scope and Evidence Pressure Index is a derived planning tool. It is not an official scope, legal, contract, FedRAMP, assessment, audit, certification, DoD, Cyber AB, NIST, or compliance determination.

CMMC External Service Provider FAQ

Is an identity provider a CMMC ESP?

It can be. If identity records, configuration, security logs, credentials, or other security protection data resides on provider assets and the service protects the assessed environment, the provider functions can enter scope. Document the precise service, data, responsibility, and evidence path.

Does an MSSP need CMMC certification?

Not always. The current DoD FAQ says an MSSP without CUI but with security protection data can be assessed as part of the organization seeking assessment and does not require its own certification. If CUI resides on the provider service, or if the supplier also operates as a cloud service provider, the analysis changes. Apply the current sources and contract to the actual design.

Can a provider responsibility matrix be supplied after the assessment starts?

That is a poor operating choice. The matrix should already match the current service and system security plan. It drives evidence ownership, provider interview preparation, test access, and gap discovery. Building it during review is likely to expose stale scope and missing proof.

What is the operating standard?

Every in scope provider gets one current service map, one documented CUI and protection data decision, one requirement responsibility matrix, one evidence packet, and one change trigger. No mapped duty and proof, no approved service path.