The MSP Shared Responsibility Matrix for CMMC, Worked Example
What a customer responsibility matrix between a defense contractor and its MSP actually looks like: who performs each Level 2 family, why ownership flips inside a single requirement, and where these matrices usually break.
If you use a managed service provider, the CMMC rule expects your system security plan (SSP) to document the relationship, and the MSP’s service description and customer responsibility matrix (CRM) to describe it (32 CFR § 170.19(c)(2)(ii)). Our MSP checklist tells you to ask for that matrix. This post shows what a good one looks like.
The thing most matrices get wrong is a single word. A matrix should say who performs each piece of work. Who owns the decisions behind it is a different question, and the answer to that one is almost always you.
A starting model, family by family
Here is the starting point our readiness team uses for a contractor whose IT is fully outsourced to an MSP. It assigns each of the 320 Level 2 assessment objectives to whoever performs the work.
- ACAccess Control70
- ATAwareness and Training9
- AUAudit and Accountability29
- CASecurity Assessment14
- CMConfiguration Management44
- IAIdentification and Authentication25
- IRIncident Response14
- MAMaintenance10
- MPMedia Protection15
- PSPersonnel Security4
- PEPhysical Protection16
- RARisk Assessment9
- SCSystem and Communications Protection41
- SISystem and Information Integrity20
Three patterns stand out. Some families barely leave your hands: awareness and training, physical protection and the security assessment work sit almost entirely with you, because they’re about your people, your buildings and your own plan. Personnel security splits down the middle, because the MSP’s administrators need screening too. Others are mostly the MSP’s, like maintenance, where every objective is performed by the MSP or shared. And media protection is the most shared family of all, because handling media touches both your staff and the MSP’s systems.
Ownership flips inside a single requirement
A family-level view hides the most useful detail. Inside one requirement, the work often alternates between you and the MSP, objective by objective. System auditing is the clearest case:
AU.L2-3.3.1 System Auditing · six objectives, two owners- Event typesYou define[a] Which events get logged is specifiedMSP performs[c] Audit records are created
- Record contentYou define[b] What each record must contain is definedMSP performs[d] Records actually contain it
- RetentionYou define[e] How long records are kept is definedMSP performs[f] Records are retained that long
The pattern is define, then perform. You decide which events to log, what each record must contain and how long to keep it; the MSP’s platform does the logging. If the matrix just says “AU.L2-3.3.1: MSP,” the three decisions have no owner, and an assessor will find that out at objective [a].
Retention is a good example of why the decision has to be yours. CMMC sets no number, but your contract does: DFARS 252.204-7012(e) requires you to preserve images of affected systems and relevant monitoring data for at least 90 days from the date you submit an incident report. A log platform’s default retention is a licensing setting, not that decision.
The same split runs through the rest of the matrix. Every organization-defined value in Level 2, how often you scan, how quickly you patch, when sessions lock, is yours to adopt even when the MSP drafts it, because the affirmation your senior official signs is yours.
Where these matrices usually break
Here’s what an assessor’s pen does to a typical matrix. The rows are illustrative, and each mark is a pattern we see again and again:
IR.L2-3.6.2 Incident ReportingShared 1PS.L2-3.9.1 Screen IndividualsYouBackground checks at hire2SI.L2-3.14.2 Malicious Code ProtectionMSPManaged endpoint serviceCA.L2-3.12.4 System Security PlanYou“See MSP matrix v1”4- 1Shared, but nobody owns it. “Shared” is honest, but it isn’t an assignment. The MSP may detect and contain an incident, but reporting it to DoD within 72 hours is your obligation under DFARS 252.204-7012(c). Every shared row needs a sentence saying which part is whose.
- 2The MSP’s own people are missing. Its administrators can reach your environment, so screening (PS.L2-3.9.1), multifactor authentication on remote maintenance sessions (MA.L2-3.7.5) and their accounts all fall under your requirements too.
- 3The tools aren’t in it. Remote monitoring, endpoint protection and log platforms hold your logs, configurations and credentials. Services that handle that security data are in your scope and assessed as Security Protection Assets, so list each tool, not just the service.
- 4It never meets the SSP. The rule says the requirements from the CRM “must be documented or referred to in the OSA’s SSP” (§ 170.17(c)(6)(ii)). An SSP pointing at an old version gives the assessor two answers to the same question.
Building yours
- Start from the MSP’s actual services, not its marketing. Which systems does it run, which tools does it use, and which of your accounts can its people reach?
- Work at the objective level for every requirement you share. A requirement-level “shared” hides the define-and-perform split.
- Name the decision owner for every defined value, and make it you.
- Write the evidence into each row. For the MSP’s rows, say what it will hand you at assessment time: records, reports, screenshots, or a person to interview.
- Reference the matrix from your SSP, requirement by requirement, and review both whenever the MSP changes a tool or a service.
The model above is a starting point, not an answer. Your matrix should reflect the services your MSP actually delivers, and the best test of it is whether an assessor could pick any objective, find its owner, and see the evidence.
Sources: 32 CFR Part 170, § 170.17(c)(6)(ii) and § 170.19(c)(2); NIST SP 800-171A (June 2018), 3.3.1; DFARS 252.204-7012(c) and (e). Family model: 1st Defense readiness reference model for a fully outsourced IT environment, objective level.