Shared Responsibility in CMMC: What Your MSP, MSSP, and Internal Team Each Must Prove
The Assessor Does Not Care Who Is Responsible. They Care Who Has the Evidence.
When a C3PAO assessor evaluates a CMMC control, they do not ask which party is responsible for it. They ask whether the control is implemented and whether someone — anyone — can produce the evidence. Shared responsibility models fail at assessment time because the contractor points at the MSP, the MSP points at the contractor, and nobody has the artifact. Here is how to prevent that.
Why Shared Responsibility Fails at Assessment Time
The shared responsibility model is a sensible operating concept. The cloud service provider manages the infrastructure. The managed service provider manages the configuration. The contractor manages the policies and the users. Each party handles the layer they are best equipped to manage.
The problem is that CMMC does not assess layers. It assesses controls — 320 individual assessment objectives across 110 practices. Each objective is scored Met or Not Met based on evidence. The assessor does not evaluate Microsoft's half of a control separately from the contractor's half. They evaluate whether the control, as a whole, is satisfied. If the evidence for the provider's portion is missing, the control is Not Met — even if the contractor's portion is flawless.
This is why the phrase "shared responsibility" is misleading for CMMC purposes. It is not truly shared. It is divided responsibility with unified accountability. The contractor divides the work across parties. The contractor is solely accountable for proving all of it to the assessor.
Control Ownership Matrix by Function
A control ownership matrix — sometimes called a Customer Responsibility Matrix (CRM) or a RACI matrix — maps every CMMC control to the party responsible for implementing it, the party responsible for providing evidence, and the party responsible for maintaining it over time. Without this document, the assessment becomes a discovery exercise where the assessor asks about a control and nobody knows who owns it.
In a typical environment with a cloud provider (Microsoft GCC High), a managed service provider (MSP), and the contractor's internal team, the ownership generally falls into these patterns:
| Control Domain | Cloud Provider | MSP / MSSP | Contractor |
|---|---|---|---|
| Physical Security (PE) | Owns — data center | — | Owns — office facility |
| Access Control (AC) — identity config | Platform capability | Configures — CA policies, groups | Owns — user provisioning, access reviews |
| Audit & Accountability (AU) | Generates — platform logs | Configures — SIEM, log retention | Owns — log review, response |
| System & Comm. Protection (SC) | Owns — encryption in transit/rest | Configures — DLP, labels | Owns — policy, classification |
| Configuration Management (CM) | Platform baselines | Configures — Intune, GPO | Owns — baseline approval, change mgmt |
| Incident Response (IR) | Reports — platform incidents | Detects — monitoring, triage | Owns — IR plan, DoD reporting |
| Risk Assessment (RA) — vuln scanning | — | Executes — scans, remediation | Owns — policy, exception approval |
| Awareness & Training (AT) | — | May deliver — phishing sims | Owns — training program, records |
| Media Protection (MP) | Owns — media destruction in DC | — | Owns — removable media, tape, disposal |
| Personnel Security (PS) | Owns — personnel screening (DC staff) | Owns — their own staff screening | Owns — employee screening, termination |
Provider Policies Versus Customer Procedures
A common mistake is treating the provider's documentation as if it automatically satisfies the contractor's obligation. It does not. The provider's policies describe what the provider does. The contractor's procedures describe what the contractor does. Both are needed — and neither substitutes for the other.
"Microsoft encrypts data at rest with AES-256."
This is documented in Microsoft's FedRAMP SSP and Service Trust Portal. It satisfies the provider's portion of SC.L2-3.13.16 (data at rest). But the assessor will also ask: "Is this encryption FIPS-validated? Which module? How do you verify it?" The contractor must be able to reference the provider's FIPS certificate and explain how it maps to the control — not just point at a marketing page.
"We enforce sensitivity labels on all CUI content."
This is the contractor's implementation on top of the provider's platform. Microsoft provides the Purview labeling engine. The contractor configures the label policies, defines the auto-labeling rules, and trains users to apply labels correctly. The provider's capability enables the control. The contractor's procedure implements it. Both must be documented. Both must produce evidence.
The same pattern repeats across every control domain. The provider offers a capability. The MSP may configure it. The contractor defines the policy that governs its use. The assessor evaluates the full chain — capability, configuration, policy, and evidence of operation. If any link is missing, the control is incomplete.
Evidence Inheritance and What Cannot Be Inherited
In CMMC, certain controls can be partially or fully inherited from a cloud service provider — meaning the provider's FedRAMP authorization satisfies the provider's portion of the control, and the contractor references the provider's authorization as evidence. This is the mechanism that makes cloud-based compliance architectures viable. Without inheritance, every contractor would need to implement every control from scratch, including physical security, infrastructure encryption, and platform-level access controls.
But inheritance has strict limits. The following categories cannot be inherited — they must be implemented and evidenced by the contractor regardless of the provider relationship:
User-Level Access Controls
The provider configures the identity platform. The contractor provisions users, assigns roles, performs access reviews, and manages the lifecycle of every account. AC.L2-3.1.1 (limit access to authorized users) cannot be inherited because the provider does not know which of your users should have access to which resources. That is your decision, your configuration, and your evidence.
Security Awareness Training
No provider can train your employees on your CUI handling policies. AT.L2-3.2.1 and AT.L2-3.2.2 require role-based security awareness training with documented completion records. This is 100% contractor-owned. Even if your MSP delivers phishing simulations, the training program, content, tracking, and evidence of completion belong to you.
Incident Response Plan and Execution
Your MSSP may detect and triage security events. But the incident response plan — including the 72-hour DoD reporting obligation under DFARS 7012(c) — is the contractor's responsibility. IR.L2-3.6.1 requires an operational IR capability that the contractor owns and exercises. Delegation of detection is not delegation of response. The contractor must own the plan, the decision-making authority, and the reporting obligation.
Risk Assessment and POA&M Ownership
Risk assessments (RA.L2-3.11.1) and the Plan of Action and Milestones are organizational artifacts. The MSP may contribute vulnerability scan data and remediation guidance, but the risk assessment judgment — which risks to accept, which to remediate, which to escalate — belongs to the contractor. The POA&M is the contractor's document, signed by the contractor's senior official.
Policy Documents
Every CMMC control family requires an organizational policy — access control policy, audit policy, incident response policy, and so on. These policies describe the contractor's intent and operating rules. They cannot be generic templates from the MSP. They must reflect the contractor's actual environment, actual procedures, and actual risk decisions. The MSP can help draft them. The contractor must own, approve, and maintain them.
Contracts, SLAs, and Right-to-Audit Language
The legal agreement between the contractor and each provider is the foundation of the shared responsibility model. If the contract does not specify the provider's security obligations, the provider has no contractual obligation to meet them — and no obligation to produce evidence when the assessor asks.
Every contract with an MSP, MSSP, or cloud provider that touches CUI should include the following provisions:
Overseas Staff, Subcontractors, and Access Restrictions
One of the most consequential — and most overlooked — aspects of the shared responsibility model is who at the provider has access to the contractor's CUI environment. The physical location and citizenship status of provider personnel can determine whether the entire architecture is ITAR-compliant or not.
MSP with Overseas NOC or Helpdesk
Many MSPs operate 24/7 by staffing a network operations center in a lower-cost overseas location. If those staff members have admin credentials to the contractor's GCC High tenant, Azure AD, or firewall — they have access to CUI. If the CUI includes ITAR-controlled data, access by non-U.S. persons violates export control regulations. This is not a CMMC finding — it is a criminal liability.
MSP Subcontracting to a Fourth Party
The contractor contracts with MSP-A. MSP-A subcontracts backup management to MSP-B. MSP-B's technician has admin access to the backup server that holds CUI. The contractor has no contract with MSP-B, no visibility into MSP-B's security posture, and no control over MSP-B's personnel. But MSP-B's access to CUI puts MSP-B in the assessment boundary as an ESP — and the contractor is accountable for documenting it.
Mitigations must be contractual and technical — not just policy-based:
- Contractual restriction — The MSP contract must prohibit subcontracting of services that involve CUI access without the contractor's prior written approval. Every subcontractor must be identified and their access scope documented.
- U.S. person requirement — For ITAR environments, the contract must require that all provider personnel with access to CUI are U.S. persons (citizens or lawful permanent residents). The provider must be able to attest to this.
- Named personnel list — The contractor should maintain a list of provider personnel authorized to access the CUI environment. Changes to the list require notification. New personnel require screening verification.
- Technical access controls — Conditional access policies, IP restrictions, or privileged access workstations that limit provider access to managed, auditable channels. If the MSP can VPN in from any device at any location, the access control is the weakest link in the chain.
- Access logging and review — Every provider login to the CUI environment must be logged and periodically reviewed by the contractor. If the MSP accesses your Azure AD at 3 AM from an overseas IP, you need to know — and you need to have a process for investigating it.
Building an Assessor-Ready Responsibility Map
The deliverable that ties all of this together is a single document — or a structured set of documents — that the assessor can reference to understand who owns each control, where the evidence lives, and how the contractor verified the provider's compliance. Here is what that package looks like:
The Bottom Line
Shared responsibility in CMMC is an operating model — but it is not a compliance model. The contractor holds the certification, the contractor sits in the assessment, and the contractor must produce the evidence for every control, including the controls that providers implement on their behalf. The MSP's work is valuable. The cloud provider's FedRAMP authorization is essential. But neither absolves the contractor of the obligation to document, verify, and present the complete control environment.
The contractors who pass assessments cleanly are the ones who build the responsibility matrix before they need it, put the evidence obligations in the contract before they sign it, collect the provider evidence before the assessor asks for it, and review the entire package annually to make sure nothing has drifted.
When the assessor asks "who is responsible for this control?" the only correct answer is: "We are — and here is how we verified that every party did their part." That answer requires a responsibility matrix, a provider evidence binder, and the contractual authority to demand both. Build those before the assessment. Not during it.