The safest CMMC shared-responsibility model is a written matrix, not a handshake. For each requirement or operating task, identify what the client does, what the MSP does, what a cloud/provider does, and who retains the evidence.
The working question for a small business under CMMC is concrete: within the defined FCI/CUI boundary, who is responsible for this requirement, and what evidence today shows it is functioning as intended?
The rule in plain English
Responsibility can split inside one requirement. The MSP may configure endpoint policy while the client approves users, reports HR events, controls physical access, and decides what data may be placed on the endpoint.
Inherited technical capability is not the same as inherited operational responsibility. The contractor still needs to understand how the whole requirement is met.
How to implement it without overbuilding
Create a responsibility matrix linked to actual services in scope. Use RACI labels only if they are unambiguous and assign evidence ownership separately.
Review the matrix after service changes, new tools, mergers, staffing changes, or changes to the CUI boundary.
What evidence to keep
Keep the service agreement, responsibility matrix, evidence index, escalation contacts, review records, and samples of provider-delivered evidence.
Test one split-owned control to confirm both sides can produce their evidence without contradiction.
Where teams get into trouble
A common failure is 'MSP handles IT' as the only ownership statement. Another is assigning the same task to both parties without saying who actually executes it.
Small-contractor walkthrough
The MSP patches systems and manages endpoint security, while the client approves users, controls facilities, and owns employee terminations. A shared-responsibility matrix should split both implementation and evidence ownership so neither side assumes the other completed a task.
For readiness, choose a normal business example rather than a perfect demonstration environment.
- List services and controls.
- Assign implementation owner.
- Assign evidence owner.
- Define escalation.
Shared responsibility should be mapped below the slogan level
A client may approve an engineer's access while the MSP creates the account, applies groups, enrolls the device, and retains the provisioning ticket. For patching, the MSP may deploy updates while the client owns maintenance windows and business-risk decisions. For incident response, the MSSP may detect and triage while the contractor owns DoD reporting and contract communication. These are split responsibilities inside individual requirements.
Build the Customer Responsibility Matrix from actual services. For each requirement or assessment objective, identify the client action, provider action, shared handoff, evidence source, evidence owner, and exception path. Avoid RACI tables where both parties are called responsible but neither is clearly the executor.
Evidence ownership is not the same as control ownership
The MSP may operate the firewall while the contractor still needs assessor-ready evidence that the configuration and monitoring are in place. Conversely, the contractor may approve access while the MSP retains the system-generated change record that proves implementation. Add an evidence column to the CRM so the storage location and retrieval owner are known before assessment.
Test evidence retrieval as an operating service level. Select a split-owned objective and ask both sides to produce the policy or procedure, approval, technical configuration, operating record, and relevant log. If records contradict each other or one party needs a week to engineer a custom export, the shared-responsibility design is not mature.
Review shared responsibility whenever the service changes
Update the CRM after new tools, new CUI workflows, cloud migrations, acquisitions, changes in MSP subcontractors, new locations, or boundary changes. A matrix written at onboarding becomes inaccurate when the provider replaces the RMM, changes backup architecture, moves the SOC, or takes over identity administration.
Use the CRM during internal assessments and contract reviews, not only during C3PAO preparation. Good handoffs improve daily operations: HR notices reach the right queue, privileged changes receive approvals, alerts reach the client, evidence accumulates, and exceptions have an owner.
Add one quarterly spot check for a shared control. Compare the CRM, service agreement, live tool ownership, and latest evidence. Correct the mapping immediately when the provider or client is doing different work from what the document claims.
Last-mile depth check
Use the CRM during incidents, not just assessments. If an alert involves a provider-managed control, the matrix should make it obvious who investigates, who communicates with the client, who preserves evidence, and who decides whether the event triggers contractual reporting. An assessment-ready responsibility model should improve incident speed as well as documentation quality.
Operational edge-case check
Finally, include the client and MSP in the same tabletop exercise at least once. Use a termination, critical vulnerability, or security alert and watch the handoff in real time. Record where approvals, notifications, evidence, or escalation stall. Those friction points belong in the CRM because they show where shared responsibility fails operationally even when the written matrix looks complete.
A short working check
- ✓List services and controls.
- ✓Assign implementation owner.
- ✓Assign evidence owner.
- ✓Define escalation.
- ✓Review after changes.
- ✓Test split-control evidence.
Common questions
Can we outsource CMMC responsibility?
You can outsource tasks, but contractual accountability and the need to demonstrate implementation remain with the contractor.
Should the matrix use all 110 requirements?
For Level 2 it is often useful where responsibility is split, but the format can fit the environment.
What if the MSP refuses evidence?
That is a service and assessment risk to resolve contractually or architecturally.
Does shared responsibility apply to SaaS?
Yes. Cloud services often create provider/customer splits that should be documented.
Is a shared responsibility matrix the same as a Customer Responsibility Matrix?
The market uses both terms, but 32 CFR 170.19 uses Customer Responsibility Matrix for documented ESP/client responsibilities relevant to the service.
Official sources used for this guide
Open the primary source before making a contract-specific decision. Regulations and program implementation can change.
