Customer Responsibility Matrix Template for CMMC

At assessment, the document that says who owns each control gets read out loud. The room finds out whether anyone has updated it in eighteen months.

That moment is where most Customer Responsibility Matrices fall apart. The contractor’s IT lead points to a row that says the MSP handles audit log review. The MSP rep says they generate the logs but don’t review them. The assessor writes a finding. Nobody is lying. The CRM is stale, vague, or both.

The CRM is one of the few documents in a CMMC package that has to describe two organizations at once. It is also one of the most neglected. We’ve seen contractors arrive at assessment with a CRM that still references a SIEM the MSP retired a year ago, a role eliminated in a reorg, and a tool name the team no longer recognizes. The signature page is intact. Nothing else is.

This piece walks through what a CRM is, why generic templates fail, the four deployment patterns, the five control families where ownership gets disputed, and the boundary language that survives.

What a CRM Actually Is

The Customer Responsibility Matrix is the document that defines who owns each CMMC control between an Organization Seeking Certification and its external service providers. The OSC holds the certification. The provider operates some portion of the assessed environment. The CRM names which party implements, documents, and evidences each applicable control.

It is not a contract. It is not an SLA. It is not a statement of work. Those documents describe what services are delivered and at what level. The CRM describes who is responsible for satisfying each of the 110 NIST 800-171 security requirements when those requirements involve systems the provider operates.

A contract can say the MSP delivers managed identity services. The CRM has to say the MSP configures and maintains the identity platform, defines and enforces password complexity rules, generates access reports on request, and notifies the OSC of platform changes within five business days, while the OSC defines who gets access, approves access requests, conducts quarterly access reviews, and notifies the MSP of personnel changes within 24 hours. Two different documents. Two different jobs.

If the contract goes deeper than that, fine. The CRM still has to exist as a standalone artifact, because the assessor reads it as a standalone artifact. They aren’t going to reconstruct your control ownership from a 60-page MSA appendix. They’re going to ask for the CRM.

For the broader concept and the role of External Service Providers in scoping, see Shared Responsibility in CMMC.

Why Generic Templates Fail

Most CRMs we see started as a template the MSP downloaded, populated once at onboarding, and never touched again. The most common failure pattern is a column labeled “MSP” or “Customer” with a single X marking which side owns each row. No detail. No division of labor. No evidence reference.

The phrase that doesn’t survive assessment is “we handle that.” When an MSP rep tells an assessor “we handle access control,” the assessor asks which specific objectives they satisfy. Account creation? Account review? Access enforcement? Least privilege? Separation of duties? Most MSPs handle some of those and not others. The CRM has to say which.

The second failure pattern is templates built on the assumption that one MSP touches the whole environment. Real environments are layered. The contractor uses GCC High for CUI work, an on-premises ERP for production data, a SaaS engineering tool for design files, and a separate cloud platform for backups. Each layer has different control owners. A CRM that flattens that into one ownership column is wrong on its face.

The third pattern is the worst. The CRM was written when the MSP onboarded, three CIOs and two acquisitions ago. The MSP changed their SIEM. The contractor added a CUI-bearing system. The IT director retired. Nobody updated the document. By assessment time, the CRM describes an organization that doesn’t exist.

The Four CRM Patterns by Deployment Model

CRMs follow the deployment model, not the other way around. Before writing one, identify which pattern applies. The shape of the document changes meaningfully across these four.

MSP-Managed Enclave

The MSP operates a dedicated CUI enclave for the OSC. Identity, endpoint management, logging, backup, and security tooling all live inside the MSP’s environment. OSC users authenticate into MSP-managed systems. This is the cleanest pattern because the boundary is sharp. The MSP owns most technical controls. The OSC owns governance, policy, and personnel-driven controls.

GCC High Partnership

Microsoft GCC High provides the platform. The MSP configures and operates within it. The OSC consumes it. Three parties touch the environment, and the CRM has to reflect that. Microsoft handles the platform layer. The MSP handles tenant configuration, policy enforcement, and ongoing administration. The OSC handles data classification, user management decisions, and policy ownership. Don’t write this as a two-column document. It is at least three columns, and the cloud platform’s role is assessor-relevant even when it’s implicit.

Hybrid Environment

The OSC runs some systems in-house and outsources others. Maybe the MSP handles identity and endpoint, but the OSC operates an on-prem manufacturing system that processes CUI drawings. Configuration management, audit logging, and access control split unevenly across that boundary. The CRM has to be written control by control, with no assumption that one column owns the whole family. This is the pattern that produces the most assessment findings because the seams are the hardest to document cleanly.

SaaS Layered

The OSC uses multiple SaaS providers for CUI workflows. A FedRAMP Moderate document management platform. A separately-hosted PDM system. A managed email security gateway. Each one has its own responsibility model. The CRM has to incorporate each provider’s published shared responsibility documentation by reference, then layer the OSC’s own operational responsibilities on top. The MSP, if there is one, sits across all of it. This pattern requires the most cross-referencing and the most documentation discipline.

Control-by-Control Through the Five Most-Disputed Families

Five control families generate most of the ownership disputes we see in CRMs. The walkthrough below uses NIST 800-171 control identifiers as they map to CMMC Level 2. Verify each ownership statement against your specific contractual relationship before publishing your CRM. An RPO or assessor review is the right finishing step.

Access Control (AC.L2-3.1.x)

Access control is where the “shared” cell gets used most often, usually without enough detail. The technical platform that enforces access is typically the MSP’s. The business decisions about who should have access are the OSC’s. The CRM needs to spell that out.

The MSP owns configuration of the identity platform, enforcement of MFA, generation of audit reports, and technical implementation of session lock and termination. The OSC owns access policy, approval of access requests, the timing of access reviews, notification of personnel changes, and review of the MSP’s reports. Joint responsibilities, like the quarterly review meeting, name both parties with a designated owner from each side.

A common failure is AC.L2-3.1.7 (Privileged Functions). The MSP often has privileged access to the platform but the OSC’s named admin owns the function within the OSC’s tenant. Both have to be documented.

Audit and Accountability (AU.L2-3.3.x)

Audit logging is commonly disputed because generating logs and reviewing logs are different jobs. The MSP usually generates and stores them. The OSC is responsible for ensuring they’re reviewed and that anomalies get investigated.

The CRM has to name who reviews what, on what cadence, and what triggers escalation. If the MSP delivers a weekly anomaly report and the OSC has 48 hours to review and escalate, write it down. If the MSP runs 24x7 monitoring and only escalates confirmed incidents, write that down differently. When the document is silent, the default assessor assumption is that nobody is reviewing.

Retention is the other common gap. NIST 800-171 doesn’t specify a retention period, but DFARS 7012 and contractual requirements often do. The CRM has to state the retention period, where logs are stored, and who confirms retention is being honored.

Configuration Management (CM.L2-3.4.x)

Configuration management is the family most affected by MSP tool changes. If the MSP swaps endpoint management platforms, the OSC’s SSP probably says the wrong tool name. The CRM has to address how baseline configurations are maintained, who approves changes, and how the OSC is notified when the MSP changes anything affecting the security baseline.

A working pattern. The MSP maintains baseline configurations for managed endpoints and provides them on request. The MSP notifies the OSC of baseline changes within a defined window, typically five business days, before implementation. The OSC reviews proposed changes for compliance impact and approves or rejects them. Both parties retain the change history.

The trap is the silent change. The MSP rolls out a new agent across managed endpoints in a maintenance window. The OSC’s SSP still describes the old agent. If the CRM says nothing, the OSC carries the finding.

Maintenance (MA.L2-3.7.x)

Maintenance gets ignored until an assessor asks about it. Who performs maintenance? Where do maintenance tools live? Who supervises remote sessions? Who sanitizes media before maintenance? Who handles maintenance personnel that aren’t U.S. persons?

The MSP usually performs most technical maintenance, but the OSC has to maintain awareness of when it happens, what was touched, and whether the maintenance personnel meet the access requirements. Remote maintenance sessions need to be authorized, supervised, and logged. The CRM has to name how. “The MSP handles maintenance” is not enough.

For systems processing CUI, MA.L2-3.7.5 (Nonlocal Maintenance) is a frequent finding when nobody can produce evidence of how multifactor authentication was enforced on nonlocal maintenance sessions through the MSP’s tools. The CRM should reference the specific evidence path.

System and Communications Protection (SC.L2-3.13.x)

SC is the family most affected by deployment model. Boundary protection, encryption in transit, encryption at rest, and key management are mostly platform-level responsibilities, but the OSC still has obligations.

In a GCC High deployment, Microsoft handles a meaningful portion of SC controls at the platform layer. The MSP handles tenant configuration that enforces those controls (Conditional Access policies, DLP rules, encryption settings). The OSC handles policy decisions and exceptions. The CRM has to reflect all three. Treating Microsoft’s shared responsibility model as if it eliminates the OSC’s role is a common mistake. It does not. The OSC still owns the policy decisions the platform’s controls enforce.

For hybrid environments, the seams between cloud and on-prem are where assessors look. SC.L2-3.13.8 (Data in Transit) often fails at the seam because nobody specified how data crossing between the MSP-managed cloud and the OSC’s on-prem system is encrypted.

For the broader 110-control context, see The 110 Controls That Decide Your Future.

Boundary Language That Holds Up

The language in a CRM matters. Vague language creates findings. Specific language survives. Here are the patterns we’ve seen hold up.

Instead of “MSP handles,” use the verb structure that names what the MSP does and what artifact proves it. “The MSP configures and operates the identity platform, generates monthly access reports stored at [location], and notifies the OSC of platform changes within five business days.” The verb tells the assessor what to look for. The artifact tells the assessor where to find evidence.

Instead of “shared,” name the division explicitly. “MSP configures MFA enforcement. OSC defines user enrollment scope. Joint quarterly review with OSC security officer as designated reviewer.” The word “shared” alone tells the assessor nothing. The division statement gives them the structure they’re going to validate.

Instead of “as needed,” name the cadence. Quarterly. Within 24 hours of personnel change. Within five business days of any baseline modification. The assessor can verify a cadence. They cannot verify “as needed.”

Instead of standalone responsibility statements, include the evidence pointer. “MSP retains audit log review records for one year, accessible via the MSP portal at [URL] or by ticket request.” The assessor reads the CRM and immediately knows where the evidence lives. They don’t ask three follow-up questions to find it.

Cross-reference to specific NIST 800-171 control identifiers and CMMC Level 2 objectives. The CRM should be readable alongside the SSP and POA&M without translation. If your CRM uses your own internal taxonomy and your SSP uses NIST language, the assessor has to map between them. That mapping is your job, not theirs.

The CRM Review Cadence

Our position on cadence is quarterly minimum, with mandatory updates triggered by specific events. Annual review is too slow. Updating only at assessment time means the CRM is wrong for most of the time between assessments. By the time you notice, the MSP has retired a tool, the team has restructured, and the document describes an organization that doesn’t exist.

Quarterly works because it matches the rhythm of access reviews, vulnerability cycles, and most security committee schedules. The CRM review can ride alongside one of those existing meetings. It needs a designated owner, a documented scope (whose responsibilities changed in the last 90 days), and a sign-off.

Trigger-based updates supplement the quarterly review. Force an off-cycle update on any of these events. A change in MSP tools or platforms that affects a control mapping. A change in personnel with named CRM responsibilities. A new system added to the CUI boundary. A contract amendment that changes MSP scope. A finding from an internal audit or assessor walkthrough that surfaces a CRM gap.

Hold this position when an MSP pushes back. Some MSPs treat the CRM as a one-time deliverable they wrote during onboarding. That posture is a liability. The contractor signs an SSP attesting to a CRM nobody has read in eighteen months. If your MSP doesn’t have a cadence for keeping the CRM current, you need one. If they’re unwilling to participate, that tells you something about whether they’re equipped to support your CMMC obligations. For more on whether your MSP needs to be CMMC-aligned, see Does My MSP Need to Be CMMC Compliant and MSP Guide to CMMC Compliance Services. For underlying DFARS context, see DFARS 252.204-7012.

Closing

A CRM that gets reviewed quarterly is a living document. A CRM that gets signed once and shelved is a finding waiting to happen.

The work isn’t writing the first version. The work is keeping it true. Build the cadence, name the owner, define the triggers, and treat it as part of how the compliance program operates. The document that describes who owns what shouldn’t describe an organization that no longer exists.

Verify your CRM with your RPO, your MSP, and an assessor familiar with your environment before treating it as final. Templates are starting points. The document that holds up at assessment is the one that matches operating reality on the day the assessor opens it.