Shared Responsibility Matrix for CMMC
Clarity that protects
Map roles, reduce risk, prove compliance
A Shared Responsibility Matrix (SRM) is one of the most important documents in a CMMC Level 2 environment. It defines—control by control—who is responsible for configuring, enforcing, and evidencing each requirement. Without it, gaps, assumptions, and audit failures are almost guaranteed.
Shared Responsibility Matrix for CMMC
Clarity that protects
Map roles, reduce risk, prove compliance
A Shared Responsibility Matrix (SRM) is one of the most important documents in a CMMC Level 2 environment. It defines—control by control—who is responsible for configuring, enforcing, and evidencing each requirement. Without it, gaps, assumptions, and audit failures are almost guaranteed.
What an SRM Is
A practical compliance foundation
A Shared Responsibility Matrix (SRM) outlines how CMMC Level 2 requirements are met across your environment—by you, your Cloud Service Providers (CSPs), and your External Service Providers (ESPs/MSPs). For defense contractors, it is the single most effective way to demonstrate that every control has an identified, traceable owner.
To understand CMMC scoping in general, you can also review our CMMC Explained page.
Why auditors insist on an SRM
An SRM eliminates assumptions. For each practice in NIST 800‑171, it specifies exactly what the provider implements, what your MSP manages, and what you—the OSC (Organization Seeking Certification)—must document in your SSP. Without it, assessors cannot verify that your system matches real-world configurations or that inherited controls have been properly documented.
CSPs and inherited responsibilities
FedRAMP‑authorized platforms such as Microsoft GCC High (covered on our GCC vs GCC High Comparison post) often include inherited controls. These represent CSP‑implemented responsibilities such as logging architecture, infrastructure protections, and datacenter security. However, identity, device governance, data protection, and configuration enforcement almost always remain your responsibility.
Security Protection Assets (SPAs)
Some tools used as Security Protection Assets (SPAs) are not themselves FedRAMP authorized or CMMC certified. That does not make them non‑compliant, but you should perform a vendor risk assessment to ensure they’re the right fit for your environment. They require clearly outlined responsibilities in the form of an SRM—what they do, what you must configure, and how evidence is gathered.
MSPs and shared responsibilities
If you work with a Managed Services Provider to configure, maintain, or troubleshoot your CMMC environment, you absolutely need an SRM. MSPs often implement key technical controls—identity systems, endpoint management, SIEM monitoring, DLP, and device onboarding. Even so, the OSC retains ultimate responsibility for demonstrating each control in the SSP.
How to obtain SRMs/CRMs from vendors
Most CSPs publish standardized CRM/SRM documents. MSPs typically tailor SRMs for each client based on Scope of Work and ODPs (Organization-Defined Parameters). ICS Data handles this process as part of our CMMC Managed Services onboarding workflow.
What your SRM should include
Vendor CRMs
Request Appendix J documents from CSPs to determine inheritable responsibilities.
Granular subcontrols
Document responsibility down to each assessment objective.
Mapped SSP language
Your SRM should reinforce and align with your SSP implementation statements.
ODP-aligned scope
Ensure SRM coverage aligns with your Organization‑Defined Parameters.
Clear customer actions
List approvals, reviews, updates, and confirmations required by the OSC.
SRM Structure and Key Components
What “good” looks like
A strong shared responsibility matrix is granular—down to the subcontrol. It should include:
Clear ownership definitions
Each assessment objective includes specific implementation responsibilities, such as:
| Identifier | Assessment Objective | MSP Responsibility Detail | Customer Responsibility Detail |
| 3.4.2[a] | Determine if security configuration settings for information technology products employed in the system are established and included in the baseline configuration. | Provide recommendations and implement access controls that align with established security configuration requirements. | Validate baselines and approve configurations. |
| 3.4.2[b] | US Department of State (DDetermine if security configuration settings for information technology products employed in the system are enforced. | Configure enforcement mechanisms for system security settings. |
| 3.4.2[a] |
| Assessment Objective: Determine if security configuration settings for information technology products employed in the system are established and included in the baseline configuration. |
| MSP Responsibility Detail: Provide recommendations and implement access controls that align with established security configuration requirements. |
| Customer Responsibility Detail: Validate baselines and approve configurations. |
| 3.4.2[b] |
| Assessment Objective: Determine if security configuration settings for information technology products employed in the system are enforced. |
| MSP Responsibility Detail: Configure enforcement mechanisms for system security settings. |
| Customer Responsibility Detail: N/A |
Inheritance boundaries
Inherited portions (e.g., FedRAMP control inheritance from GCC High or Azure Gov) must be clearly labeled and paired with vendor CRM statements.
Customer-required actions
The SRM must identify approvals, reviews, and actions the OSC must complete. Many audit failures occur because customer responsibilities were assumed but never documented.
Straightforward explanations
Shared Responsibility Matrix FAQ
These are the most common questions we hear about SRMs when defense contractors prepare for CMMC Level 2.
Why does my assessor require an SRM?
Because it demonstrates traceability—who implements each portion of every control, and where evidence originates.
Is a CRM the same as an SRM?
Functionally, yes. CSPs often use CRMs/Customer Responsibility Matrices; MSPs typically produce SRMs/Shared Responsibility Matrices. Assessors accept both.
What if my CSP or SPA isn’t FedRAMP authorized?
They should still outline shared responsibilities and customer configuration requirements. Add those directly into your SRM and SSP.
What responsibilities can be inherited?
Infrastructure, datacenter operations, platform protections, and some logging functions. Identity, data governance, and device compliance remain customer responsibilities.
Why do MSPs need an SRM?
Because MSPs implement major portions of technical controls, and auditors expect those responsibilities to be formally documented.
Compliance without confusion
Why Choose ICS Data
We build SRMs that actually match your environment and withstand auditor scrutiny—no guesswork and no ambiguity.
CMMC Level 2 certified
ICS Data operates in a fully CMMC‑compliant environment, giving you confidence that anything we implement or manage aligns with audit-grade standards.
Tailored SRM development
We create SRMs aligned to your Scope of Work and ODPs, with control-by-control clarity.
Implementation statement writing
Our team drafts technical control language and guides you on what to add to your SSP.
Vendor shared responsibility matrix collection
We coordinate directly with CSPs and SPAs to collect SRMs/CRMs for all products we implement in your environment.
More Articles on CMMC and IT Compliance
You Treat Patients. We Handle HIPAA Cybersecurity.
You didn’t go to school for cybersecurity. See how managed IT handles HIPAA compliance for medical practices behind the scenes – so your team can focus on patients, not IT.
Read More
What’s the difference between Microsoft 365 GCC and GCC High?
Understand the differences between Microsoft 365 GCC and GCC High—compliance, hosting, cost, and use cases—choose the right option for you.
Read More
GCC High Migration Guide
Discover how a GCC High Migration helps you prepare for ITAR and CMMC L2 by aligning domains, security controls, user roles, and audit evidence for a secure transition.
Read MoreResources
Shared responsibility for reliability Microsoft Learn [accessed 2026-08-02] https://learn.microsoft.com/en-us/azure/reliability/concept-shared-responsibility
DFARS 252.204-7012: Requirements, Scoring, and Compliance Legal Clarity [accessed 2026-07-31] https://legalclarity.org/dfars-252-204-7012-requirements-scoring-and-compliance/
