When an MSP manages systems that process CUI or Security Protection Data for a defense contractor, both organizations share the compliance obligation. The contractor holds the CMMC certification. The MSP operates portions of the assessed environment. The assessor needs to know who owns what.
Ambiguity about control ownership is one of the most common sources of assessment findings. The contractor thinks the MSP handles a requirement. The MSP thinks the contractor owns it. Nobody implemented it. The assessor scores it NOT MET.
Documenting how security responsibilities are divided between your organization and each in-scope provider is not optional. A customer responsibility matrix is required by the CMMC scoping guidance for all in-scope ESPs.
Why Shared Responsibility Creates Risk
In a traditional IT relationship, the MSP manages infrastructure and the contractor focuses on their business. Responsibilities are divided informally, often through a service agreement that describes what the MSP delivers but not how it maps to security requirements.
CMMC changes the stakes. Every one of the 110 NIST 800-171 security requirements must be implemented, documented, and evidenced. When an MSP operates in-scope systems, some of those requirements are satisfied by the MSP’s configurations, some by the contractor’s practices, and some by a combination of both.
The assessor doesn’t care about your service agreement’s scope of work. They care about whether each security requirement is met. If a requirement falls in the gap between what you think the MSP does and what the MSP thinks you do, the requirement is NOT MET.
What a Customer Responsibility Matrix Covers
A customer responsibility matrix maps each applicable NIST 800-171 security requirement to one of three ownership categories:
Contractor-owned. The contractor is fully responsible for implementing, documenting, and evidencing the requirement. The MSP has no role.
MSP-owned (ESP-owned). The MSP is fully responsible for implementing the requirement in the context of the services they provide. The contractor relies on the MSP’s implementation. The MSP must produce evidence for assessor review.
Shared. Both parties play a role. The specific division is documented. For example: the MSP configures MFA on the identity platform. The contractor manages the enrollment of users and the policies governing MFA exceptions. Both produce evidence for their respective portions.
For each requirement, the CRM should document:
- The requirement identifier
- The ownership designation (contractor, MSP, shared)
- For shared requirements: the specific division of responsibility
- Who produces the evidence for assessor review
- How the contractor verifies the MSP’s ongoing compliance with their assigned controls
Where Shared Responsibility Gets Complicated
Access Control
Who manages user accounts? Who approves access requests? Who conducts access reviews? Who revokes access when an employee leaves?
In many MSP relationships, the MSP administers Active Directory or Azure AD. The contractor manages the business logic of who should have access to what. Both parties touch the access control requirements, but neither owns them entirely.
The CRM needs to specify: the MSP configures and maintains the identity platform. The contractor defines access policies, approves access requests, and notifies the MSP of personnel changes within a defined timeframe. The contractor conducts periodic access reviews. The MSP provides the reports and tools needed for those reviews.
Audit and Accountability
Who configures audit logging? Who reviews the logs? Who retains them for the required period? Who alerts on anomalies?
If the MSP manages the SIEM and the logging infrastructure, they own the technical configuration. But log review, which is a requirement, often falls to the contractor or is a shared function. The retention policy needs to be agreed upon and documented.
Incident Response
The 72-hour DIBNet reporting clock is ticking, the MSP detected the incident first, and nobody has reported it because both sides assumed the other would. That scenario plays out when detection and reporting responsibilities aren’t documented.
Who detects incidents? Who investigates? Who reports through DIBNet within 72 hours? Who preserves evidence? The reporting obligation sits with the contractor under DFARS 7012, even when the MSP monitors the environment. The handoff between detection and reporting needs to be defined, tested, and documented. A 72-hour window doesn’t leave time for finger-pointing about whose responsibility it was to call it in.
Configuration Management
Who controls baseline configurations? Who approves changes? Who documents changes? Who verifies that changes don’t break compliance?
The MSP may manage the systems, but configuration management under NIST 800-171 requires documented baselines, change control processes, and impact assessments. If the MSP makes a configuration change that affects a security control, the contractor’s SSP needs to reflect it. That requires a communication mechanism between the MSP and the contractor’s compliance documentation.
Vulnerability Management
Vulnerability management follows a common pattern where the MSP runs scans and applies patches, but the questions of who prioritizes remediation and who tracks whether vulnerabilities are addressed within defined timeframes often go unanswered until an assessor asks. The contractor is responsible for verifying that remediation happens on schedule. The CRM documents who does what, and who produces the evidence showing it was done.
Building Your CRM
Step 1: List All In-Scope Security Requirements
Start with the full set of 110 NIST 800-171 Rev 2 security requirements. Not all will involve the MSP. Some, like personnel security screening, are inherently contractor responsibilities. Others, like technical access controls, often involve the MSP.
Step 2: Classify Each Requirement
For each requirement, determine: does the MSP touch this at all? If yes, is the MSP fully responsible, or is responsibility shared?
Walk through this with your MSP. Don’t assign responsibilities unilaterally. The MSP needs to agree to what they own, understand what evidence they’ll need to produce, and confirm they can deliver.
Step 3: Document the Split
For shared requirements, be specific about who does what. “Shared” without detail is as useless as no assignment at all. The assessor needs to trace each requirement to a specific implementation. “Shared between contractor and MSP” isn’t traceable.
Step 4: Define the Evidence Plan
For each requirement, document who produces the evidence. If the MSP owns the technical implementation, they need to produce the configuration exports, the log samples, the scan reports. If the contractor owns the policy layer, they produce the policy documents, the review records, the approval artifacts.
Step 5: Establish Review Cadence
The CRM isn’t a set-it-and-forget-it document. Review it when the MSP changes their service offering, when your environment changes, when you onboard new systems or retire old ones, and before every assessment cycle.
Need a starting point for your customer responsibility matrix? Learn about our partner program to see how Deep Fathom manages shared compliance between contractors and MSPs.
What Assessors Look For
During a CMMC assessment, the assessor examines the CRM to understand the control ownership model. Then they evaluate whether each party is actually fulfilling their assigned responsibilities.
They look for gaps. Requirements where neither party has clear ownership. Requirements where the CRM says one thing but the implementation says another. Requirements where the MSP was assigned ownership but can’t produce evidence.
They look for consistency. The CRM should be consistent with the SSP. If the SSP describes a control as implemented by the contractor but the CRM assigns it to the MSP, that’s a finding.
They may interview MSP staff. If the MSP is responsible for specific controls, the assessor may want to interview MSP personnel about those controls. The MSP should be prepared for this and should know the assessment is happening.
Common Mistakes
Not having a CRM at all. This forces the assessor to determine control ownership during the assessment, which is slow, produces findings, and suggests the contractor hasn’t thought through how their compliance program works with their service providers.
Using the MSP’s generic service description as a CRM. A service agreement describes what the MSP delivers. A CRM maps that delivery to specific NIST 800-171 requirements. They’re different documents.
Assigning everything to the MSP. Some contractors hand their MSP the full list and say “you handle compliance.” The CMMC certification belongs to the contractor, not the MSP. The contractor is responsible for ensuring all requirements are met, including those implemented by the MSP. Delegating implementation is fine. Delegating accountability is not.
Not verifying the MSP’s work. Assigning a control to the MSP doesn’t end the contractor’s responsibility. The contractor needs a verification mechanism, periodic reviews, evidence requests, or monitoring, to confirm the MSP is actually doing what the CRM says.
Making It Work
The contractors who handle shared responsibility well treat the CRM as a living operational document, not a compliance checkbox. They review it regularly, verify the MSP’s performance against it, and update it when anything changes.
Deep Fathom manages the customer responsibility matrix as part of the living compliance system. Control assignments are linked to evidence, SSP sections, and assessment objectives. When the MSP produces evidence for their assigned controls, it flows into the same system of record. The assessor sees one integrated package rather than having to reconcile separate documents from separate organizations.
Check your readiness or talk to our team.
Related reading: