CMMC ESP Requirements: When a Service Provider Becomes In-Scope

A service provider enters your CMMC scope once its systems process, store, or transmit CUI or Security Protection Data for you. DoD ties ESP status to that condition, not to a contract label or marketing term.

ESP and Security Protection Asset definitions

DoD defines an External Service Provider (ESP) in the CMMC final rule as external people, technology, or facilities that you use for provision and management of IT or cybersecurity services on your behalf. DoD defines Security Protection Assets (SPAs) in the Level 2 Scoping Guide as assets that provide security functions and capabilities for in-scope systems.

DoD places an ESP in scope when CUI or Security Protection Data (SPD) resides on the provider’s assets. SPD includes data that protects CUI systems, such as logs, alerts, authentication artifacts, configuration backups, and signatures. DoD treats SPAs as in scope regardless of where you place them, including security services that a third party hosts.

You do not treat a provider as an ESP under CMMC if the provider never processes, stores, or transmits CUI or SPD on its own assets. You still manage risk for that provider, but CMMC ESP scoping does not attach.

Threshold for in-scope ESP status

DoD sets a simple threshold. An ESP becomes in scope once its systems process, store, or transmit CUI or SPD for you. That threshold brings the provider’s service into your assessment boundary.

You document the ESP relationship in your System Security Plan (SSP). You describe the services provided, the data handled, the connection methods, and the boundaries. You also keep a Shared or Customer Responsibility Matrix that shows who performs each requirement.

Assessors will look for those artifacts. The CMMC Assessment Process and the Level 2 Scoping Guide direct assessors to review how you assign responsibilities and how you evidence each practice when a third party provides part of the control.

Two control families illustrate the split:

Access control: AC.L2-3.1.1 and AC.L2-3.1.3 often span your environment and an ESP’s platform or tool.
Audit and accountability: AU.L2-3.3.1 often depends on SIEM or monitoring services that hold SPD on non-contractor assets.

Network protection and supplier risk provide similar patterns:

System and communications protection: SC.L2-3.13.5 can involve segmentation and gateways that an ESP designs or operates.
Risk management: SR.L2-3.12.1 puts you in charge of supplier governance and risk decisions for each ESP.

Cloud providers and FedRAMP expectations

DoD uses Table 4 in the final rule to draw a line between cloud and non-cloud providers that handle CUI for you.

DFARS 252.204-7012 requires a cloud service that stores, processes, or transmits covered defense information, including CUI, to meet FedRAMP Moderate or an equivalent set of requirements that the DoD CIO approves.
DoD allows non-cloud ESP services that handle CUI or SPD to sit inside your CMMC assessment boundary. You can have the assessor evaluate those services as part of your scope instead of pointing to a separate CMMC certificate for the ESP.

That split does not shift accountability. You own your CMMC outcome. A FedRAMP authorization or a provider’s CMMC program status does not remove your need to configure, operate, and evidence the controls that remain in your column.

For deeper contract details on the cloud requirement, read our primer on DFARS 252.204-7012 requirements.

Documenting ESP relationships

You keep the paperwork that proves you control the relationship and the boundary. The Level 2 Scoping Guide directs you to document the ESP in your SSP and to describe service scope and responsibilities. Microsoft reinforces this shared responsibility model for its cloud offerings and advises customers to maintain a Shared Responsibility Matrix that covers all 110 NIST SP 800-171 requirements and the associated CMMC objectives.

Start with two core artifacts:

An SSP section and service description that name each ESP, outline service scope, and describe data flows and trust boundaries.
A Shared or Customer Responsibility Matrix that assigns each requirement to you, the ESP, or a cloud platform, and that points to specific evidence.

Then collect evidence that supports the assignments:

FedRAMP authorization package references for any cloud that hosts CUI under DFARS 252.204-7012, along with customer configuration evidence that shows your side of each control.
Operating procedures, tickets, and reports that show the ESP performing assigned tasks, plus your review and approval steps.

You can map these artifacts to the CAP expectations. Assessors will ask for traceable requirements, named owners, and repeatable proof. That path keeps you in control of the assessment conversation.

For structure and content of the SSP itself, review our guidance on System Security Plans. For allocation of practices to people, process, and technology, use our NIST 800-171 to CMMC Level 2 mapping.

Practical scoping patterns

Managed service providers and security providers often cross the ESP threshold through two routes. Each route drives scoping, documentation, and evidence.

Remote administration and tooling. An MSP that administers your tenants, servers, or endpoints often ingests logs and stores credentials, tokens, and configurations on its own systems. That data qualifies as SPD. You include the MSP’s service in scope, document the data and access paths, and show how you validate the MSP’s controls and work outputs.
Monitoring and response. A SIEM, MDR, or SOC provider that collects or processes your logs sits in scope as an SPA provider. You show how the provider receives, protects, and retains your data, and how your team consumes alerts and reports to close the loop.

Virtual Desktop Infrastructure creates a distinct pattern. DoD allows you to treat thin clients that never process, store, or transmit CUI as out of scope. The VDI infrastructure that hosts CUI remains in scope. An ESP that operates that infrastructure sits in scope. You document the boundary at the hypervisor or broker, assign practices across the split, and collect evidence for both sides.

Working with Microsoft environments

Microsoft states that its US Government clouds can support your CMMC obligations. Microsoft also states that your configuration, implementation, and operations determine your outcome. That position aligns with DoD’s scoping and CAP guidance.

Adopt a shared responsibility model that names Microsoft, your ESPs, and your internal teams. Use Microsoft guidance and the Public Sector blog post on CMMC to build a matrix that covers all 110 NIST SP 800-171 requirements and the set of CMMC objectives. Keep the matrix close to the SSP and keep it versioned with change control.

Treat the Microsoft Product Placemat for CMMC as informational mapping. The placemat does not create authorization or a guarantee. You still assign people to implement practices, set configurations, and operate controls every day.

Contractors that choose GCC or GCC High still own scoping and evidence. The platform choice can reduce data residency concerns and provide required features, but you still need to set boundaries, assign controls, and prove performance.

Action plan for scoping decisions

You can make the ESP call without guesswork.

Trace CUI and SPD to systems that a provider owns or operates. If that data sits on provider assets, bring the service into scope.
Decide whether the service is cloud or non-cloud. If cloud services host CUI, verify FedRAMP Moderate or an approved equivalent under DFARS 252.204-7012, then show your side of each control with configuration and operational evidence.

Then finalize the documentation set.

Update the SSP, the responsibility matrix, and data flow diagrams. Name owners, set review cycles, and link to evidence locations.
Align assessment evidence for the shared controls you pushed to an ESP. Pull SIEM reports, change records, access reviews, and incident records that show the service working and your team validating outcomes.

That approach withstands assessor review and internal scrutiny. It also gives you a clear vendor management path under SR.L2-3.12.1.