By William Price, Certified CMMC Assessor (CCA) — A³ Vallum CMMC Advisory
The Customer Responsibility Matrix is possibly the single most important document in the relationship between an MSP and a CMMC client. It is also the document many do badly. The reason is not laziness. The CRM most MSPs are familiar with — the marketing-grade two-column table that says “vendor maintains compliance” and “customer is responsible for configuration” — does not survive contact with a CMMC Level 2 assessor.
If you are an MSP delivering CMMC services, the CRM is the artifact that determines whether the assessment is a calm conversation or a forensic exercise. It is worth getting right.
What is a CMMC Customer Responsibility Matrix?
A CMMC Customer Responsibility Matrix is a structured document that maps each CMMC Level 2 assessment objective to the party responsible for implementing it — the client, the MSP, or shared between them. It is referenced from the client’s System Security Plan and reviewed by the C3PAO as part of the assessment, per 32 CFR § 170.19(c)(2).
It is an evidence document. The assessor uses it to decide which controls to test against the client’s environment and which to test against the MSP’s.
Why does this differ from a generic shared responsibility model?
A traditional cloud shared responsibility model talks at the level of layers — physical security here, network here, OS here, application here. A CMMC CRM has to operate at the level of the roughly 320 individual assessment objectives in NIST SP 800-171A. Two clicks deeper than most MSPs are used to.
The CMMC Level 2 Scoping Guide explicitly requires a CRM for External Service Providers. “Vendor maintains FedRAMP compliance” is a true sentence but an inadequate CRM entry. The assessor needs to know exactly which assessment objective that statement is meant to address, what evidence the MSP can produce for it, and what residual responsibility falls back to the client.
What does a defensible CRM look like?
Three columns at minimum. Five is better. The minimum are the assessment objective identifier and text, the responsible party, and the implementation summary. The fuller version adds an evidence reference column pointing to the artifact the assessor would review, and a notes column for shared-responsibility controls explaining where the handoff happens.
Every row should be specific enough that an assessor reading it cold would know who to ask, what to ask for, and where to find the evidence. “MSP enforces multi-factor authentication” is a row a marketer would write. “MSP enforces FIDO2-based MFA on all privileged Microsoft 365 admin accounts via Conditional Access policy [Policy Name], evidence in Tenant Audit Log export, owned by [MSP role]” is a row an assessor would accept. That is the difference between IA.L2-3.5.3 [a] being clearly met and IA.L2-3.5.3 [a] becoming a finding.
What are the most common CRM failures?
These show up over and over.
The first is the “marketing” CRM. Vague claims with no evidence references. An assessor will not reject this on sight. They will treat the entire CRM as untested and re-derive every responsibility from interviews. That could turn a four-week assessment into a six-week assessment and the MSP into the bottleneck.
The second is the over-claimed CRM. The MSP marks themselves as fully responsible for objectives they cannot fully implement. A common one is access control for client-managed accounts, where the MSP technically configures the policy but the client provisions and de-provisions users. When the assessor tests it, the MSP cannot produce all the required evidence. The residual gap becomes a finding against the client.
The third is the under-claimed CRM. The MSP, fearing assessor scrutiny, marks the client as responsible for objectives the MSP actually owns. The client cannot produce the evidence. The assessor walks the trail back to the MSP anyway. Now the MSP is being assessed on objectives they did not document or prepare for.
How granular should each row be?
As granular as the assessment objective itself. CMMC Level 2 has 110 controls and roughly 320 assessment objectives in NIST SP 800-171A. A CRM with 110 rows is a CRM that is going to fail at least one objective per control on assessment day. The right number of rows is roughly 320.
This is the part most MSPs balk at. It is also the part that separates the MSPs running real CMMC practices from the MSPs running adapted IT practices.
DIBFI for MSPs
A 320-row CRM, mapped to NIST SP 800-171A objectives, with evidence references and per-client tailoring — and built to update as your environment changes — is exactly what DIBFI’s MSP edition produces. Not a spreadsheet. An audit-grade artifact.
Who should own the CRM document?
The MSP should draft it. The client should review and own it. The C3PAO will assess against it.
Practically, that means the MSP produces the first version because the MSP knows the technical implementation details. The client’s compliance lead — whether that is a CCP, an internal compliance manager, or an RPO — reviews every row and either accepts the responsibility allocation or pushes back. Once it is accepted, the CRM becomes part of the client’s SSP. It changes only with version control.
The MSP that hands the client a CRM template and asks them to fill it ends up with a CRM that does not match reality. The client does not know what the MSP is actually doing under the hood. The client that accepts a CRM without review with have their SSP collapse on assessment day.
What does a healthy CRM cadence look like?
An initial CRM during scoping. A revision after the readiness phase, once technical controls are implemented and the MSP knows what they actually do versus what they planned to do. A pre-assessment review with the client thirty days before the C3PAO arrives. An annual refresh tied to the client’s policy review cycle.
If the CRM has not been opened in a year, it is almost certainly out of date.
Frequently Asked Questions
Is a Customer Responsibility Matrix required for CMMC Level 2? Yes. The CMMC Scoping Guide – Level 2, implementing 32 CFR § 170.19(c)(2), requires a CRM for any External Service Provider, including MSPs, that supports the client’s CUI environment.
Can we use the FedRAMP shared responsibility matrix for our CMMC client? No. A FedRAMP CRM is not granular enough for CMMC Level 2 assessment. CMMC requires mapping to the NIST SP 800-171A assessment objectives, which is two layers deeper than the FedRAMP shared responsibility model operates at.
Do MSPs that are CMMC certified themselves still need a CRM with their clients? Yes. Certification does not eliminate the need to document which party owns which assessment objective in a given client’s environment. The CRM is the client’s artifact, not the MSP’s.
Can we use a templated CRM across clients? The starting structure can be templated. The actual content should be tailored per client. Every client’s environment, scoping decisions, and shared-responsibility breakpoints are different. A copy-pasted CRM is a finding waiting to happen.
What happens if the CRM is wrong on assessment day? The assessor reconstructs the responsibility allocation by interview and observation. Any gap surfaces as either a finding against the client or a request for additional evidence from the MSP. Both paths cost time. The second one tends to expose unrelated weaknesses in the MSP’s documentation discipline.
Closing thought
The MSPs that pass their clients’ CMMC assessments cleanly are not the ones with the most polished “marketing” CRMs. They are the ones whose 320-row CRMs match what their clients’ environments actually do. A vague CRM is a deferred assessment finding. A precise CRM is a faster assessment. When did you last open the CRM for your largest CMMC client, and how confident are you that it still describes reality?
A³ Vallum builds and maintains CMMC Customer Responsibility Matrices for MSPs supporting defense contractor clients, and provides a white-label CMMC backend where the CRM is built into the service from day one.
About DIBFI for MSPs
DIBFI is a guided CMMC readiness platform built for how assessors evaluate. The MSP edition is white-label, multi-client, and built to absorb the operational compliance load while you keep the customer relationship.
Sources
- 32 CFR Part 170 — CMMC Program rule, particularly § 170.19(c)(2)
- CMMC Assessment Scope – Level 2, v2.13 (September 2024), DoD CIO (DoD-CIO-00006)
- CMMC Assessment Guide – Level 2, v2.13 (September 2024), DoD CIO (DoD-CIO-00003)
- NIST SP 800-171 Revision 2
- NIST SP 800-171A — assessment objectives (320 lettered objectives across 110 requirements)
