CMMC Shared Responsibility Matrix: Who Owns Each Control?

Verified June 16, 2026 against 32 CFR § 170.19, the DoD CMMC Level 2 Scoping Guide (v2.13) and Assessment Guide (Level 2), DFARS 252.204-7012, NIST SP 800-171 Rev. 2, and the Cyber AB Code of Professional Conduct v2.0.

The Defense Compliance Report is an independent trade publication on CMMC 2.0 and DIB compliance. We are not affiliated with, endorsed by, or acting on behalf of the U.S. Department of Defense, the CMMC Program Management Office, the Cyber AB, CAICO, DCMA DIBCAC, or any C3PAO. This is editorial compliance research, not legal, contractual, or compliance advice.

Provider-matching forms on this site may generate referral or lead-routing compensation. This page does not currently contain named provider rankings, endorsements, or "best provider" awards. If named provider reviews are published later, sponsored, affiliate, partner, or referral relationships will be labeled on the relevant provider card or review. See our Methodology and Editorial & Advertising Policy for details.

A CMMC shared responsibility matrixis the who-owns-what map between your company and any outside provider whose people, technology, or services process, store, or transmit your CUI or Security Protection Data—or that provide a security function for your assessment scope. It assigns each NIST SP 800-171 Revision 2 security requirement, and ideally each assessment objective beneath it, to you, your provider, or both, so nothing is left unowned when a Certified Third-Party Assessment Organization (C3PAO) walks in the door.

The document is officially called a Customer Responsibility Matrix (CRM) in 32 CFR § 170.19 and the current DoD Level 2 Scoping Guide. “Shared responsibility matrix” is the common market and search term for the same thing, borrowed from cloud computing. Below we use both interchangeably, clarify the difference where it matters, and explain exactly what assessors check.

That last sentence—exactly what assessors check—is the whole game, and it’s where we’ll spend most of our time. First, the fast version.

The 60-second answer

What is a CMMC shared responsibility matrix?

A CMMC shared responsibility matrix is a control-ownership document that maps each NIST SP 800-171 Revision 2 security requirement—and its assessment objectives—to a responsible party: your organization, an external service provider, or both. Its purpose is to prove, before an assessment, that every one of the 110 requirements (broken into 320 assessment objectives) has an owner and a source of evidence. It is the bridge between “our provider handles that” and “here is the final-form evidence that proves it.”

It is not a marketing chart. It is not your provider’s SOC 2 report. It is not a slide that says “the cloud handles security.” A real matrix connects four things: the requirement, who implements it, what evidence proves it, and where that lands in your SSP.

The document exists because outsourcing is now the norm in the Defense Industrial Base (DIB—the companies that supply the U.S. military). Small and mid-tier contractors move email, file storage, identity, monitoring, and patching to outside specialists. But CMMC accountability does not move with the work. The matrix is how you keep track of who is actually doing what—and how you avoid the worst assessment-day surprise: a control nobody owned.

One framing to keep handy as you read:

Same document. Two names. The question isn’t “do I have a matrix?” It’s “does every requirement my providers touch have a named owner and final-form evidence behind it?”

Is a CMMC shared responsibility matrix required?

The exact phrase “shared responsibility matrix” is not a named, standalone mandate in the rule—but the underlying documentation is effectively required whenever you use an outside provider. 32 CFR § 170.19 states that an external service provider’s use, relationship, and services must be documented in your SSP and described in the provider’s service description and customer responsibility matrix (CRM).

The DoD CMMC Level 2 Assessment Guide is blunt about the standard: all applicable assessment objectives must be MET or not applicable. Draft evidence is unacceptable. If an objective is marked MET, the evidence must be final-form and tied to a named responsible party. Without the matrix, an assessor cannot confirm the responsible party. Without a named party, the objective cannot be scored MET.

When you may genuinely not need one:if you run your CUI environment entirely in-house and no external provider processes, stores, or transmits CUI or Security Protection Data—and none provides a security function for your scope—you don’t produce an external responsibility matrix. You still document who internally owns each control in your SSP. If that’s you, the CMMC System Security Plan guide is the better starting point, and you don’t need the template on this page.

SRM, CRM, or RACI—what should you actually call it?

For how buyers and assessors talk, “shared responsibility matrix” (SRM) and “customer responsibility matrix” (CRM) describe the same practical artifact: a map of who owns which security responsibility between you and a provider. The distinction worth knowing is directional. A CRM is authored by the provider and is one-directional—it tells you what youmust do for their service to support your compliance. An SRM is built collaboratively and is bidirectional—it shows what each party does for each requirement.

Which term is “official”? We read both primary sources to be sure. The rule uses CRM: 32 CFR § 170.19(c)(2)(ii) requires that an ESP relationship be documented in your SSP and “described in the ESP’s service description and customer responsibility matrix (CRM).” The current DoD Level 2 Scoping Guide (v2.13, September 2024) consistently uses “customer responsibility matrix.”

So why is “shared responsibility matrix” everywhere? Partly because it’s borrowed from cloud computing—and partly because DoD’s earlier (2021) Level 2 scoping guide actually used the phrase “shared responsibility matrix” before the Final Rule. The term stuck in the market even though the current rule and guidance both say CRM. Bottom line: CRM is the official CMMC term; SRM is the practical and search term for the same document.

Here’s the clean way to hold all of it:

Naming convention we recommend for the document itself: title it CMMC Level 2 Customer / Shared Responsibility Matrix. That matches the rule’s language and the buyer’s language, so it survives both an SSP review and a search.

When does a provider become an “external service provider” (ESP) under CMMC?

Under 32 CFR § 170.4, an external service provider (ESP) is external people, technology, or facilities you use for IT or cybersecurity services where CUI or Security Protection Data (SPD) is processed, stored, or transmitted on the provider’s assets. Two questions decide how the provider is treated: Is it a Cloud Service Provider (CSP)? And does it handle CUI, SPD, or neither? A provider that touches neither CUI nor SPD does not meet the CMMC definition of an ESP.

This is the most consequential page in the whole exercise, because scope determines everything downstream. Run every provider through the same gate. The rule’s scoping table—Table 4 to § 170.19(c)(2)(i)—lays it out:

A quick decision path you can run in your head:

1. Does the provider process, store, or transmit CUI?
2. Does it process, store, or transmit Security Protection Data? The Scoping Guide defines SPD as security-relevant information that could help an attacker—explicitly including configuration data for a security tool, log files, data on the configuration or vulnerability status of in-scope assets, and passwords that grant access to your environment.
3. Is it a CSP (a cloud service offering), or a non-CSP MSP / MSSP / SOC / cybersecurity-as-a-service provider?
4. Does it provide a security function for your CMMC scope?
5. Does your SSP rely on it to satisfy any requirement?

If the answer to 1 or 2 is yes, the provider is in your matrix. If the answer to both is a clean, documented no—backed by a data-flow diagram and the service description, not a guess—it’s likely out.

The Scoping Guide gives concrete examples of both. Out: cloud-based HR and accounting SaaS that don’t contribute to your security and don’t touch CUI or SPD typically aren’t ESPs. In:a SIEM service that never touches your CUI is still in scope, because it contributes to meeting your requirements—and the guide lists firewalls, SIEM, EDR, hosted VPN, co-located data centers, and SOCs among Security Protection Assets. The difference is the data and the function, not the vendor’s logo.

The DCR scoping matrix: who owns what, by provider situation

The hardest part of building a shared responsibility matrix isn’t the spreadsheet—it’s knowing how each kind of provider is treated under the rule, what to request, and where it goes in your SSP. We built the table below by cross-reading 32 CFR § 170.19 (including Table 4), the DoD Level 2 Scoping Guide, DFARS 252.204-7012, and the Cyber AB conflict-of-interest rules into one operational worksheet.

Two things to notice. First, the “no CUI” answer rarely ends the analysis—Security Protection Data brings many security providers back into scope. Second, the same analysis applies to a sister company in your own corporate family if it’s external to the entity being assessed; the Scoping Guide is explicit that an ESP can sit inside the broader corporate structure yet still be external to the assessed organization.

Who builds the matrix—you, your MSP, or your cloud provider?

You—the Organization Seeking Assessment (OSA)—are accountable for the matrix and for keeping it current, but it’s assembled from inputs your providers supply. Your provider authors a CRM describing what you must do; your cloud provider supplies its FedRAMP customer responsibility documentation; you stitch those into one matrix covering all 110 requirements and reconcile it with your SSP. In practice, a capable MSP or MSSP will fill out most of a shared matrix for the services it runs—often under NDA—and hand it back for you to integrate.

Think of it as artifacts versus evidence: different parties own different pieces.

A practical note on the NDA reality: detailed provider matrices and evidence are frequently shared under non-disclosure agreement, and some providers restrict what an assessor can see. Sort that out early—confirming that the CRM is available and that ESP personnel will participate in the assessment is something a C3PAO expects you to have arranged before the assessment, not something to negotiate on assessment day.

Where do you get the Microsoft, AWS, FedRAMP, or MSP/MSSP CRM?

Start with each provider’s official compliance channel: the FedRAMP package access path for a cloud platform, the provider’s service description and customer responsibility documentation for an MSP/MSSP, and the vendor’s compliance portal for a security tool. For cloud, verify the exact in-scope services; for MSPs and MSSPs, ask for a CMMC-specific CRM mapped to your services and the NIST SP 800-171 Rev. 2 objectives—not a generic one-pager.

• Microsoft (GCC, GCC High, Azure Government): Validate the exact cloud service offering and its status on the FedRAMP Marketplace, then request Microsoft’s customer responsibility documentation for the services you use. Different Microsoft offerings carry different authorizations—confirm the one that applies to your tenant and workloads. See also our GCC High for CMMC guide.
• AWS (GovCloud):AWS states it publishes a CMMC customer package, responsibility matrices, and customer implementation guidance through AWS Artifact, and tells customers to confirm which services are in scope via its “Services in Scope by Compliance Program” list. Treat those as provider-stated resources to verify, not as a DCR endorsement.
• MSP / MSSP:Ask for a CMMC-specific CRM mapped at the objective level. Quality varies widely—some providers hand over a clean, objective-level matrix; others can’t produce one at all, which is itself a signal (see the FAQ below on what to do when a provider refuses).
• Security tools (SIEM, EDR, GRC):Request the customer responsibility documentation and confirm what data the tool stores. One watch-out worth knowing: if a security product can ingest your files for analysis, that feature can pull CUI into the tool’s boundary and turn it into a CUI asset—which raises the bar to FedRAMP. Confirm and configure accordingly.

What goes in a CMMC shared responsibility matrix?

A useful matrix records, for each requirement and ideally each assessment objective: the control ID, the control family, the owner (you, provider, shared, inherited, or not applicable), an implementation summary, the evidence source, the SSP reference, the asset or service in scope, the CUI/SPD status, and a last-verified date. The point is not a tidy spreadsheet—it’s a document an assessor can use to confirm that every objective has an owner and final-form evidence.

Minimum columns that make a matrix assessment-ready:

If your matrix exposed a provider gap, don’t book an assessment until you know whether the fix is readiness help, MSP/MSSP support, cloud/enclave work, GRC evidence workflow, or a C3PAO path. That’s the decision this page exists to make easier.

How we verified this guide

This guide is built from primary CMMC and DoD sources, then structured around the friction we see real buyers describe. Every regulatory claim was checked against the eCFR, the Federal Register, Acquisition.gov, the DoD CMMC guides, NIST publications, and Cyber AB documents. Forum and community language was used only to understand buyer questions—never as regulatory authority.

On June 16, 2026, we:

• Read 32 CFR § 170.19 in the eCFR and confirmed the customer-responsibility-matrix language in § 170.19(c)(2)(ii) and the ESP scoping rules in Table 4;
• Confirmed the current DoD CMMC Level 2 Scoping Guide (v2.13, Sept 2024) uses “customer responsibility matrix (CRM),” defines Security Protection Data, and gives the HR/accounting-SaaS and SIEM scope examples—and noted that the earlier 2021 scoping guide used “shared responsibility matrix,” which is why the term persists;
• Confirmed the DoD CMMC Level 2 Assessment Guide scoring rule—all applicable objectives must be MET or not applicable, and draft evidence is unacceptable;
• Verified the FedRAMP requirement for CUI clouds in DFARS 252.204-7012 and the December 2023 DoD CIO equivalency guidance;
• Confirmed CMMC Level 2 still maps to NIST SP 800-171 Rev. 2 (110 requirements, 320 objectives), not Rev. 3;
• Confirmed the phase dates on DoD’s CMMC program pages; and
• Read the Cyber AB Code of Professional Conduct v2.0 to confirm the three-year consultant-assessor independence prohibition.

What we did notdo: claim Cyber AB or DoD endorsement, verify any named provider’s private matrix, treat vendor marketing as authority, or offer legal advice. This is editorial compliance research from an independent trade publication—confirm contract obligations, assessment strategy, and legal questions with qualified counsel, your contracting officer, and appropriate CMMC professionals.

Frequently asked questions

The Defense Compliance Report is an independent trade publication on CMMC 2.0 and DIB compliance. We are not affiliated with, endorsed by, or acting on behalf of the U.S. Department of Defense, the CMMC Program Management Office, the Cyber AB, CAICO, DCMA DIBCAC, or any C3PAO.