External Service Provider Management

External Service Providers (ESPs) represent one of the most consistent CMMC assessment failure points for defense contractors. The problem is rarely intentional: most organizations simply haven't mapped every cloud service, SaaS subscription, and managed service relationship against the question: does this system touch CUI, or does it support a security function that protects CUI? If the answer to either is yes, that service is an ESP and must be inventoried, assessed, and governed.

The CMMC Final Rule (32 CFR Part 170) establishes specific requirements for ESPs. CSPs handling CUI must meet the applicable FedRAMP Moderate or DoD equivalency requirements. Non-CSP services used to protect or handle CUI are assessed within the OSA's scope; privileged access alone does not create a blanket requirement for the MSP to hold a separate CMMC certification. Document the provider's actual services, data, and responsibilities.

ESP Categories

The following operational groupings help inventory providers. They are not three mutually exclusive regulatory categories: SaaS is commonly a cloud service, and the rule's assessment decision turns on CSP status and whether CUI or SPD is handled.

ESP Type	Definition	CMMC Requirement	Examples
Cloud Service Provider (CSP)	Hosts or processes CUI in a cloud environment	Must meet FedRAMP Moderate Authorized or equivalent	M365 GCC High, Azure Government, AWS GovCloud
Managed Service Provider (MSP)	Provides IT services within or connected to the OSC environment	Assess relevant services and assets within the OSA's scope; evaluate any separate contractual certification obligation	IT support vendors, NOC/SOC providers, co-managed IT firms
SaaS / Software ESP	Software-as-a-service accessed from within the CUI environment	Must be assessed for CUI exposure and security posture	DocuSign, Salesforce, Deltek, GitHub

A SaaS tool may require either FedRAMP verification or a contractual flow-down and access control review, depending on whether CUI is stored or transmitted through it.

---

What Triggers ESP Scope, and Whether It Needs Its Own Assessment

Not every vendor is an ESP, and not every ESP needs its own CMMC assessment. The CMMC Scoping Guide — Level 2 (32 CFR § 170.19(c)(2)) sets a precise threshold and a short decision tree.

The threshold: data must reside on the provider's assets. A provider is only an ESP if CUI or Security Protection Data (SPD) resides on its systems. SPD is security-relevant data that, if disclosed, could aid an attacker: logs, configuration data, vulnerability status, and credentials for the in-scope environment. This is the trap most inventories miss: a cloud SIEM that never touches CUI is still an ESP because your logs (SPD) live there. By the same logic, an HR or accounting SaaS that holds neither CUI nor SPD and provides no security function is typically not an ESP at all.

Does the ESP need its own assessment? Once a provider is an ESP, the answer turns on two questions, whether it is a Cloud Service Provider (CSP) and whether it processes, stores, or transmits CUI:

ESP	Handles CUI?	Requirement
CSP	Yes	Must meet FedRAMP (Moderate baseline or equivalent) per DFARS 252.204-7012
CSP	No (e.g., holds only SPD)	FedRAMP not required; the service is still in the OSA's assessment scope
Non-CSP (e.g., MSP)	Yes	The ESP's services require assessment within the OSA's scope; the ESP may pursue its own C3PAO assessment
Non-CSP	No	No separate CMMC assessment; the service is still in the OSA's scope

Two definitions settle most arguments: a CSP provides its own cloud platform; an MSP provides technical support and may use cloud tools without being a CSP (an ESP that merely manages a third-party cloud on your behalf is not a CSP). And pure staff augmentation, where the OSA provides all processes, technology, and facilities and the ESP supplies only people, does not require a CMMC assessment of the ESP.

Whichever path applies, the ESP's services land in the OSA's assessment scope and must be documented in the SSP with a Customer Responsibility Matrix (CRM) describing the split of responsibilities.

---

FedRAMP Moderate Equivalency

FedRAMP Moderate applies a tailored NIST SP 800-53 baseline. Use the current FedRAMP control reference and the DoD equivalency memorandum, rather than a control count or a vendor's general compliance claim, to evaluate a CSP handling CUI.

"Equivalency" is not self-declared and is not a SOC 2 or an ISO certificate. The DoD CIO memo of December 21, 2023 sets the bar: 100 percent of the current FedRAMP Moderate baseline, assessed by a FedRAMP-recognized 3PAO, with no POA&Ms arising from that assessment (operational POA&Ms from other sources are allowed), and a Body of Evidence (SSP, assessment plan and report, POA&M, penetration test and scan results, and continuous-monitoring data) that the contractor obtains from the CSP and holds for DIBCAC. The memo puts the burden on the contractor: it validates the Body of Evidence, hands the customer responsibility matrix to DIBCAC and the assessors, approves the use of the service, and reports incidents under the contract, not the CSP. Record who validates and retains it. Neither authorization nor equivalency removes the CSP's obligations under DFARS 252.204-7012 paragraphs (c) through (g); the contract must bind the CSP to them.

How to verify FedRAMP status: The FedRAMP Marketplace at marketplace.fedramp.gov is the authoritative source. Filter by "Authorized" status. "In Process" does not satisfy the CMMC requirement.

GCC High

Microsoft 365 GCC High is FedRAMP High Authorized: it exceeds the Moderate baseline requirement. Azure Government is also FedRAMP High authorized. Both are appropriate platforms for CUI handling under CMMC Level 2.

One important caveat: not all M365 services share the same authorization boundary. The core workloads (Exchange Online, SharePoint Online, Teams, OneDrive for Business) are covered under the M365 GCC High authorization. Some third-party add-ins, Power Platform connectors, and preview features may not be. Before enabling a new M365 service or connector in a GCC High tenant, verify it falls within the authorization boundary documented in the M365 GCC High FedRAMP System Security Plan.

The FedRAMP authorization for M365 GCC High and Azure Government can be viewed in the FedRAMP Marketplace under Microsoft as the CSP. Authorization packages are available to agencies and their contractors via FedRAMP's secure repository.

Commercial

Commercial Microsoft 365 (non-GCC) is FedRAMP Moderate authorized for specific plans (primarily E3 and E5) under a shared responsibility model. The authorization covers the platform infrastructure and core workloads, but the tenant configuration and data handling responsibilities fall on the customer.

For NIST SP 800-171 compliance using commercial M365, verify that your specific subscription plan is covered by the current FedRAMP authorization, that your tenant is configured to meet the relevant NIST 800-171 controls, and that you have reviewed the Microsoft Customer Responsibility Matrix for the applicable services. Commercial M365 does not provide the same boundary isolation as GCC High: data residency, personnel screening, and government-only logical separation are not guaranteed.

---

Building the ESP Inventory

An ESP inventory is not a one-time exercise. It must be maintained as a living document and referenced in the System Security Plan (SSP). Build the initial inventory using the following process:

1. Start with the data flow diagram. Every external service that appears in the data flow (Chapter 1) is a candidate ESP. If CUI flows to it, through it, or it provides a service that protects CUI, add it to the inventory.

2. Interview business units. Ask: what cloud tools do you use for work? What do you log into that isn't on the domain? What SaaS tools do you use for proposals, contracts, engineering, or project management? Business units routinely use tools that IT has never reviewed.

3. Review network egress logs and DNS. Shadow IT is real in every organization. Review firewall egress logs and DNS query logs for destinations that are not part of the authorized cloud environment. Recurring SaaS hostnames (e.g., *.slack.com, *.notion.so, *.dropbox.com) indicate tools that must be assessed or blocked.

4. Pull the Entra ID Enterprise Application list. Authorized OAuth applications registered in Entra ID represent SaaS tools that users have connected to their M365 identity. Review the full list for applications with access to mail, files, or calendar data: these have a CUI exposure path.

5. Interview the IT team. Identify every SaaS subscription the organization pays for. Finance or procurement may have a more complete list than IT, particularly for department-level software purchases.

Once the initial list is compiled, document each ESP in a structured inventory table. The minimum columns are:

ESP Name	Service Type	CUI Exposure	FedRAMP Status	Contractual CUI Handling	Risk Disposition
(provider name)	CSP / MSP / SaaS	Direct / Indirect / None	Authorized / In Process / None	Yes / No / Pending	Accept / Mitigate / Eliminate

The "Risk Disposition" column drives action. CSPs handling CUI without the required authorization or documented DoD equivalency must be remediated, replaced, or removed from the CUI workflow. Do not apply the CSP authorization test indiscriminately to every non-cloud ESP.

---

Common ESP Scenarios

The following table covers ESP types that appear in most DIB environments, with assessment guidance for each:

ESP	CUI Exposure Risk	Acceptable Posture	Notes
Microsoft 365 GCC High	Direct: primary CUI storage and communication	FedRAMP High Authorized	Primary CUI platform; verify specific service coverage
Azure Government	Infrastructure: session hosts, storage, VMs	FedRAMP High Authorized	Used for AVD session hosts and supplemental storage
Deltek Costpoint (cloud)	Indirect: contract financials and labor data	Verify FedRAMP or third-party equivalent	ERP systems often contain contract data with CUI elements; confirm authorization scope
DocuSign	Potential: contracts may carry CUI markings	FedRAMP Moderate Authorized (Government Cloud plan)	Limit use to non-CUI signature workflows or confirm Government Cloud plan is in use
Zoom	High if used for CUI discussions	Commercial Zoom plans hold no authorization that covers CUI. Zoom for Government (zoomgov.com) holds FedRAMP Moderate and a DoD IL4 provisional authorization; only accounts provisioned on that instance are inside its boundary	Confirm the zoomgov.com instance and the DFARS 7012 (c)-(g) terms in the contract; a commercial account gains nothing from the government offering
Slack	High if CUI is shared in channels	Slack Enterprise Grid holds FedRAMP Moderate (agency ATO, 2020); GovSlack, a separate instance on AWS GovCloud, holds FedRAMP High. Pro and Business+ plans are outside both	Confirm which instance the workspace runs on; the brand name says nothing
GitHub	High if source code is CUI or export-controlled	GitHub Enterprise Cloud holds FedRAMP Tailored LI-SaaS (Low), which does not meet the Moderate bar; there is no GovCloud edition. Keep CUI and export-controlled source in GitHub Enterprise Server hosted inside the enclave, or out of GitHub	Check the marketplace entry before relying on a Moderate authorization GitHub has announced it is pursuing
Salesforce Government Cloud	Indirect: CRM with contract and customer data	FedRAMP Moderate Authorized (Government Cloud plan)	Verify the Government Cloud plan is in use, not commercial Salesforce

Commercial Zoom and Slack plans are not authorized for CUI

Commercial Zoom plans and Slack Pro and Business+ workspaces hold no FedRAMP authorization and are not inside the Zoom for Government or GovSlack boundaries. If personnel discuss, share, or review CUI in them, including contract deliverables, technical data, or export-controlled information, the organization has an active DFARS 7012 gap, not a scoping question. A government instance from the same vendor fixes nothing until the accounts are moved onto it and the contract carries the 7012 (c) through (g) terms.

Teams in the GCC High tenant is this guide's communication baseline for meetings and persistent chat; Office 365 U.S. Government Defense sits inside a FedRAMP High boundary with a DoD IL5 provisional authorization. Block commercial Zoom and Slack for devices in the CUI boundary (the Defender for Cloud Apps unsanctioned-app list in Threat Defense and the Azure Firewall allowlist in the AVD scenario are the two levers this book configures) and write Teams into the approved-services list in the SSP. Tenant membership is not authorization: an external attendee or a federated chat partner receives CUI only if the contract and the CUI marking allow it.

---

MSP Assessment Requirements

Managed Service Providers with privileged access to your CUI environment represent a significant and often underestimated risk. Privileged access means administrative rights: specifically the ability to read, modify, or delete CUI-related configurations, data, or security controls. Examples include: Global Administrator or Security Administrator access to the M365 GCC High tenant, administrative access to Entra ID, and remote management access to CUI endpoints.

An MSP with this level of access is, for CMMC purposes, operating within the CUI boundary. Their personnel, processes, and tooling are in scope for assessment.

Assessment treatment for MSPs: Apply the CSP/non-CSP and CUI/SPD decision tree above under 32 CFR 170.19(c)(2). For a non-CSP, the relevant services are assessed as part of the OSA's scope; the provider may pursue its own assessment. A separately applicable contract or flow-down can still require a CMMC status. Document that basis rather than equating security administration with a universal standalone-certification mandate.

Contractual flow-down requirements: DFARS 252.204-7012 (Safeguarding Covered Defense Information) must flow down to subcontractors and service providers that handle covered defense information. This includes MSPs. The flow-down must be contractual: verbal agreements are not sufficient. At minimum, the MSP contract must include:

• A definition of CUI and covered defense information as used in the engagement
• An obligation for the MSP to comply with DFARS 7012 requirements
• Incident notification obligations (72-hour reporting requirement to DoD)
• Rights for the OSC to audit the MSP's compliance posture

Practical minimum requirements for MSPs that do not yet hold CMMC certification:

• Written CUI handling procedures specific to the OSC engagement
• Documented access control policy covering the OSC environment (including MFA enforcement and privileged access management)
• Background screening policy for personnel with access to the CUI environment
• An incident notification SLA short enough for the OSC to investigate and meet its own 72-hour DoD reporting deadline; do not give a provider the entire reporting window by default
• Annual review of access rights and security controls

Document all MSP relationships in the SSP, including the access scope, contractual protections in place, and the MSP's assessed compliance posture.

---

External Service Providers: Compliance Control Mapping

GCC High

The following CMMC Level 2 practices apply directly to ESP management:

CMMC Practice	Requirement	ESP Management Artifact
CA.L2-3.12.1	Periodically assess the security controls in organizational systems to determine if the controls are effective	ESP assessments documented and dated; FedRAMP verification records retained
CA.L2-3.12.4	Develop, document, and periodically update system security plans	ESP inventory included in the SSP; external systems section completed
AC.L2-3.1.20	Verify and control connections to and use of external systems	Authorized external-service inventory and connection controls
RA.L2-3.11.1	Assess risk to organizational operations, assets, and individuals	Provider risk assessments and documented treatment

Assessors reviewing these practices will expect to see: a current ESP inventory, evidence of FedRAMP verification (screenshots or URLs from marketplace.fedramp.gov), signed contracts with CUI flow-down language, and documented risk dispositions for all material ESPs.

Commercial

For organizations using commercial M365 and pursuing NIST SP 800-171 Rev. 3 compliance, the relevant controls are:

NIST 800-171 Rev. 3 Control	Requirement	ESP Management Artifact
3.17.1	Supply Chain Risk Management Plan	Documented supplier risk-management plan and review ownership
3.17.2	Acquisition Strategies, Tools, and Methods	Acquisition controls addressing identified supply-chain risks
3.17.3	Supply Chain Requirements and Processes	Contractual requirements and supplier responsibilities
3.15.2	System Security Plan	SSP external systems section documents ESPs, access scope, and data flows

In addition, the NIST SP 800-161 (Supply Chain Risk Management Practices) publication provides detailed implementation guidance for the 3.17.x controls and is referenced by NIST 800-171 assessors.