As more Defense Industrial Base (DIB) organizations move workloads to the cloud and outsource IT management to managed service providers, a dangerous assumption has taken hold: that using a reputable CSP or MSP transfers compliance obligations along with the service. It does not. Understanding exactly where your provider’s responsibility ends and yours begins is one of the most consequential compliance decisions your organization will make.

This nugget clarifies the shared responsibility model in the CMMC context, explains the critical distinctions between CSPs and MSPs, and gives you the specific questions and requirements assessors will evaluate.

CSPs and MSPs Are Not the Same Thing in CMMC

Cloud Service Providers (CSPs) host, process, or store data on infrastructure they own and operate. Examples include Microsoft Azure, AWS, Google Cloud, and SaaS platforms like Microsoft 365. When a CSP stores, processes, or transmits CUI on your behalf, that CSP must meet a specific regulatory standard.

Managed Service Providers (MSPs) and External Service Providers (ESPs) provide IT management services and often have privileged access to your systems and CUI environment. They do not typically host your data but they may administer, monitor, or support the systems that do.

The compliance implications are fundamentally different and are addressed separately below.

Cloud Service Providers: The FedRAMP Requirement

The Hard Requirement Most Organizations Miss

If your organization uses a CSP to store, process, or transmit CUI, that CSP must meet FedRAMP Moderate authorization or have a FedRAMP Moderate equivalency from a FedRamp 3PAO. This is not a best practice recommendation. It is a hard requirement under 32 CFR Part 170 and DFARS 252.204-7012.

A CSP that is not FedRAMP Moderate authorized or equivalent cannot be used for CUI without creating a significant compliance gap regardless of how reputable or technically capable the provider is. Before your assessment, verify the FedRAMP authorization status of every CSP in your environment at:

fedramp.gov/marketplace

Assessor Reality Check: One of the most common findings in CMMC assessments is CUI stored in cloud environments that have not been verified as FedRAMP Moderate authorized or equivalent. This includes widely used commercial collaboration and productivity platforms that organizations assume are compliant because they are reputable or because they were previously authorized. FedRAMP authorization status changes because products are added, versions change, and authorizations can lapse. Verify the current authorization or equivalency status of every CSP in your environment on the FedRAMP marketplace before your assessment and build that verification into your annual review process. “We use a reputable provider” is not a compliant answer, and neither is “the CUI is encrypted.” Encrypted CUI is still CUI, and the CSP hosting it must still meet FedRAMP Moderate authorization or equivalency.

What FedRAMP Authorization Does and Does Not Do For You

FedRAMP authorization means the CSP’s infrastructure controls have been assessed and authorized. It does not mean your organization is compliant. This is where the shared responsibility model becomes critical.

Inherited Controls

Inherited controls are security requirements that the CSP fully satisfies on your behalf. You do not need to implement them independently. Common examples:

  • Physical and environmental protection of the data center (PE controls)
  • Hardware maintenance and availability
  • Media protection for physical storage media within the data center
  • Facility access controls

Shared Controls

Shared controls are requirements where both the CSP and your organization each implement a portion. The CSP handles the infrastructure layer and your organization handles the configuration and use layer. Common examples:

  • Access control: the CSP provides the access control mechanism, your organization configures it and manages user accounts
  • Audit logging: the CSP generates logs, your organization must review and retain them
  • Incident response: the CSP handles infrastructure-level incidents, your organization handles incidents within your tenant

Customer Responsibility Controls

These are controls your organization must implement entirely within the CSP environment. The CSP provides no coverage. Common examples:

  • How you configure user permissions and roles
  • What data you store and how it is classified
  • How you manage encryption keys for data you own
  • Your organization’s security policies governing use of the platform

The Customer Responsibility Matrix (CRM)

Most FedRAMP-authorized CSPs provide a Customer Responsibility Matrix documenting which controls are inherited, shared, and your responsibility. Obtaining and reviewing the CRM from every CSP in your environment is not optional, it is the evidence basis for how you document those controls in your SSP.

Assessor Reality Check: Assessors will ask to see the matrix for each CSP you use and will compare it to your SSP control entries. If your SSP claims a control is fully satisfied but the CRM shows it is a customer responsibility, that is a finding.

Managed Service Providers and External Service Providers

MSPs Are Not Just Vendors, They May Be in Scope

Privileged access alone does not make an MSP an External Service Provider (ESP). Under 32 CFR Part 170, an MSP is an ESP when it processes, stores, or transmits Controlled Unclassified Information (CUI) and/or Security Protection Data (SPD) on your behalf. An MSP that administers a system but never touches CUI or SPD is not an ESP, even if its access is broad.

The distinction between CUI and SPD also determines how the MSP is assessed. An ESP that processes, stores, or transmits CUI is assessed as part of your own CMMC assessment scope, and its role must be fully documented in your SSP. An ESP that only processes or stores SPD, such as an MSP running a SIEM, logging platform, or endpoint monitoring tool that never handles CUI directly, is instead assessed as a Security Protection Asset, evaluated against the security requirements relevant to the capabilities it provides rather than the full control set applied to CUI Assets. This is a scoping determination your organization must make and document for every MSP, not an assumption to make in either direction.

When an MSP does process, store, or transmit CUI and/or SPD and is therefore an ESP, this means:

  • The MSP’s personnel who access your CUI environment must meet screening requirements consistent with PS.L2-3.9.1
  • The MSP’s access must be controlled, monitored, and logged consistent with your AC and AU controls
  • The MSP must use MFA to access your systems consistent with IA.L2-3.5.3 and MA.L2-3.7.5
  • The MSP cannot simply be listed as a vendor and excluded from your SSP, their access and role must be documented

Critical point: Outsourcing IT management to an MSP that qualifies as an ESP does not move controls outside your assessment boundary. It means you are responsible for ensuring the MSP implements those controls correctly on your behalf and that you have the documentation, including your CUI versus SPD scoping determination, to prove it.

What Your MSP Agreement Must Address

Your contractual agreement with any MSP that has access to your CUI environment must specifically address:

  • The scope of the MSP’s access including which systems and what level of privilege
  • The security requirements the MSP must meet as a condition of access
  • The MSP’s obligation to use MFA for all remote access sessions
  • Immediate notification requirements if the MSP experiences a security incident that may affect your environment
  • The MSP’s obligation to terminate access immediately upon contract termination
  • How the MSP’s access will be logged and made available to you for review
  • The MSP’s acknowledgment of and compliance with DFARS 252.204-7012 flow-down requirements

A standard IT services agreement that does not address these points is not sufficient for a CUI environment. Assessors will ask to see your MSP agreements and will look for these provisions specifically.

MSP’s Must Not Be Confused With C3PAOs

A managed service provider helping you implement and maintain your CMMC controls is not the same as a C3PAO assessing your compliance. As covered in Nugget #3, the conflict-of-interest rules prevent a C3PAO from both consulting and assessing the same organization within the same three-year period, not merely within the same certification cycle. If your MSP is also an authorized C3PAO, the consulting versus assessment conflict rule applies. Use an RPO or a separate C3PAO for assessment.

Documenting Shared Responsibility in Your SSP

Your SSP must clearly document how each control is implemented, including the role of any CSP or MSP in that implementation. For each control where a provider contributes:

  • Identify the provider and the specific service
  • State whether the control is inherited, shared, or customer responsibility per the CRM
  • For shared controls, describe both the provider’s portion and your organization’s portion
  • Reference the CRM or service agreement as supporting documentation
  • For MSP-administered controls, describe what the MSP does and how you verify they are doing it

A common SSP failure in this domain: describing a control as fully implemented by referencing the CSP’s FedRAMP authorization without identifying whether the specific control is inherited or customer responsibility. Assessors will challenge this.

Common failures in this domain include:

  • Using a commercial cloud platform for CUI without first verifying its current FedRAMP Moderate authorization status at fedramp.gov/marketplace
  • Assuming that a platform’s previous authorization status is still current. Authorization status changes and must be verified periodically
  • Deploying a newer version of a product without verifying that the specific version is FedRAMP authorized. FedRAMP validation is version-specific and a newer release may not yet be authorized even if a prior version was.
  • Assuming FedRAMP authorization means full compliance. It covers the CSP’s infrastructure only. Customer responsibility controls still require your implementation
  • No Customer Responsibility Matrix obtained or reviewed. Without it assessors cannot verify how you determined which controls are inherited vs. your responsibility
  • Assuming any MSP with system access is automatically an ESP, or conversely assuming no MSP is in scope, without evaluating whether it actually processes, stores, or transmits CUI and/or SPD
  • MSP that is an ESP not documented in the SSP, or documented without distinguishing whether it handles CUI or only SPD
  • MSP agreement does not address CMMC security requirements. Standard IT agreements are insufficient
  • MSP not required to use MFA. MA.L2-3.7.5 and IA.L2-3.5.3 apply to ESP access without vendor exemptions
  • CUI stored in standard commercial SaaS tools without verifying FedRAMP authorization status

SSP Mapping Note

Shared responsibility affects controls across every family in your SSP, not just a single section. For each control where a CSP or MSP plays a role, the relevant SSP section must document that role explicitly. In addition, your SSP should include a dedicated section or appendix listing every external provider, their FedRAMP authorization status, the services they provide, and the controls they contribute to. Assessors will use this as a roadmap for evaluating your provider relationships.

For assistance evaluating your CSP and MSP relationships, obtaining and reviewing Customer Responsibility Matrices, or documenting shared responsibility in your SSP, contact DTC’s C3PAO team.

If your organization is working toward CMMC compliance or has questions about the process, we’re here to help. Schedule a free consultation now.