How to Review a CMMC Customer Responsibility Matrix for MSPs and Cloud Providers

Start with the information and service, not the vendor label

Before reviewing a customer responsibility matrix (CRM), document what the provider actually does. Trace whether its people, technology, or facilities process, store, or transmit Controlled Unclassified Information (CUI) or Security Protection Data such as logs and configuration data. Also identify the service components your organization operates, including endpoints, identity services, network connections, and administrative accounts.

As reviewed on October 26, 2026, 32 CFR 170.19 requires the organization seeking assessment to consider whether an external service provider is a cloud service provider and whether it handles CUI, Security Protection Data, both, or neither. Those facts affect scope. The provider's marketing label—MSP, MSSP, SaaS platform, help desk, or cloud host—does not decide the result by itself.

Confirm the information involved against contract instructions and the relevant NARA CUI Registry category. When the designation or authorized handling is unclear, seek clarification from the prime contractor or Government customer. A CRM can allocate responsibilities only after the parties understand the service and information flow.

Separate cloud-provider conditions from other ESP responsibilities

For a Level 2 environment, do not treat every provider relationship as interchangeable. Under 32 CFR 170.16 and 170.17, a cloud service provider that processes, stores, or transmits CUI must satisfy the applicable FedRAMP Moderate or FedRAMP Moderate-equivalent conditions described in those sections. The organization's connecting infrastructure remains part of the assessment scope, and the CRM responsibilities must be documented in or referenced by the SSP.

For a non-cloud external service provider that processes, stores, or transmits CUI, the rule calls for the provider relationship and services to be documented in the organization's SSP and described in the provider's service description and CRM. The relevant provider services are assessed within the organization's scope against the applicable Level 2 requirements. DoD's Level 2 Scoping Guide also directs organizations to evaluate the CRM assignments between the provider and the customer.

A provider's certification, authorization, or product statement does not automatically cover your configuration, users, endpoints, procedures, or retained evidence. Verify the exact service offering, boundary, assessment or authorization status, and customer-operated responsibilities rather than relying on the provider's company-wide claim.

Build rows that can be operated and demonstrated

A useful CRM is more than a two-column list marked provider and customer. For each applicable requirement or assessment objective, describe the operational activity and assign the person who performs it, the person who verifies it, and the evidence each party will retain. The fields below are practical suggestions, not a government-mandated template.

• Requirement reference and service component: identify the applicable baseline and the part of the service involved.
• Responsibility assignment: mark provider, customer, or shared, then state the exact task each party performs.
• Configuration and approval: record who sets the control, who authorizes changes, and which customer options must remain enabled.
• Evidence and access: name the report, log, ticket, configuration export, interview contact, or demonstration and explain how the customer obtains it.
• Timing and triggers: state the review cadence and events such as onboarding, provider changes, incidents, or material architecture changes that require revalidation.
• Gap status: identify missing coverage, the accountable owner, the corrective action, and the evidence needed for closure.

Test the contract and evidence behind every shared assignment

Compare the CRM with the signed contract, service description, support model, and service-level terms. If the CRM says the provider reviews security alerts, determine which alerts are covered, the monitoring hours, escalation path, response expectations, and records the customer can retrieve. If the customer must review privileged access, confirm that the service exposes the necessary accounts and activity records.

Where DFARS 252.204-7012 applies and an external cloud service will store, process, or transmit covered defense information, paragraph (b)(2)(ii)(D) includes FedRAMP Moderate-equivalent and incident-related obligations. Review the current clause incorporated into the contract and ensure the provider arrangement supports those duties. A responsibility matrix cannot repair contract terms that do not provide needed capabilities, evidence, preservation, or access.

Validate a sample of high-risk rows by examination, interview, and testing appropriate to the applicable assessment method. Ask the provider to produce one recent record and have the customer owner demonstrate the corresponding internal step. Record limitations accurately; do not mark a shared responsibility complete when neither party owns the handoff.

Connect the CRM to the SSP and controlled evidence

NIST SP 800-171 Revision 2 requirement 3.12.4 calls for an SSP that describes the system boundary, environment, implementation of security requirements, and relationships or connections to other systems. Requirement 3.1.20 addresses verifying and controlling connections to and use of external systems. Use the CRM as controlled supporting documentation and reference the relevant assignments from the SSP instead of copying inconsistent descriptions into several files.

Maintain the CRM version, effective date, provider service version, reviewer, and approval. Link each row to evidence stored in an appropriately protected repository; do not send CUI, credentials, sensitive diagrams, or security artifacts through public forms. When the provider service or responsibility changes, review the affected SSP sections, diagrams, procedures, and evidence index.

Preserve which SSP and CRM versions supported an assessment. The SPRS NIST SP 800-171 information page identifies SSP name, version, and date among the stored assessment fields. That does not mean every routine CRM edit requires a new assessment submission, but it does make version traceability important when explaining what environment and documentation supported a recorded result.

Run a focused review before the next provider renewal

Start with one provider that handles CUI or security data. Map the service, classify its role, obtain the current service description and CRM, and test five responsibilities that are critical to your environment. Prioritize identity administration, logging and alert response, vulnerability handling, backups, encryption, and incident support based on the services actually purchased.

Hypothetical example: a 120-person engineering subcontractor uses an MSP for endpoint management and a cloud platform for CUI collaboration. The review finds that the MSP deploys patches but the contractor must approve maintenance windows and verify exceptions. The cloud provider protects the platform, while the contractor controls accounts, sharing, endpoint access, and several evidence exports. Writing those handoffs into the CRM exposes two missing owners before assessment preparation begins.

Review the CRM at provider onboarding, contract renewal, significant service or architecture change, and during your defined compliance-review rhythm. Continuum can help map provider responsibilities, align the CRM and SSP, and organize evidence and remediation actions. Schedule a compliance readiness consultation to review your environment and priorities.