The CRM (or SRM, the terms are used interchangeably in the field) is the operational glue between the OSA and any ESP that touches the assessment scope. The CMMC L2 Scoping Guide ESP Considerations section uses 'Customer Responsibility Matrix'; the cloud industry generally uses 'Shared Responsibility Matrix.' Whatever the label, the document does the same job.
What a CRM or SRM does
A CRM allocates each NIST SP 800-171A assessment objective between the ESP and the OSA. For each objective, the CRM identifies:
- Whether the OSA is responsible.
- Whether the ESP is responsible.
- Whether the responsibility is shared, and how.
- How the ESP's contribution is documented and verified.
What the L2 Scoping Guide requires
From the ESP Considerations section, the OSA must:
- Document the use of the ESP, its relationship to the OSA, and the services provided in the SSP.
- Have the ESP provide a service description and Customer Responsibility Matrix describing the responsibilities of OSA and ESP with respect to the services provided.
- Evaluate the ESP's CRM where the provider identifies security requirement objectives that are the provider's responsibility and security requirement objectives that are the OSA's responsibility.
- Consider agreements with the ESP (SLAs, MOUs, contracts) that support the OSA's information security objectives.
Practical CRM structure
| Column | What it captures |
|---|---|
| Practice / Objective | NIST 800-171A practice and assessment objective identifier |
| Responsibility | OSA / ESP / Shared |
| Implementation summary | How the responsible party implements the objective |
| Evidence reference | Where the supporting evidence lives (SSP section, ESP-provided documentation, audit log) |
| OSA responsibilities (for shared) | Specific OSA actions required to inherit the ESP's implementation |
Example: how IA.L2-3.5.3 (MFA) might look in a CRM
Practice 3.5.3 (Multi-Factor Authentication) breaks into three assessment objectives in NIST SP 800-171A. In a CRM for an OSA whose CSP provides the MFA platform but where the OSA is responsible for configuration and enrollment, the allocation typically looks like this:
| Objective | Responsibility | Implementation summary | OSA responsibilities (for shared) | Evidence reference |
|---|---|---|---|---|
| 3.5.3[a] MFA for local access to privileged accounts | OSA | OSA manages local privileged accounts on OSA-managed endpoints. MFA enforced via the endpoint management platform. | Enable MFA in endpoint management. Enroll privileged users. Review the enrollment list monthly. | SSP § 3.5.3; endpoint MFA enrollment report. |
| 3.5.3[b] MFA for network access to privileged accounts | Shared | CSP provides the MFA platform and Conditional Access policy framework. OSA configures and enforces the policy targeting the privileged role group. | Configure Conditional Access policy targeting the privileged role group. Enroll users. Monitor for policy bypasses. | CSP service description § X; SSP § 3.5.3; Conditional Access policy export. |
| 3.5.3[c] MFA for network access to non-privileged accounts | Shared | CSP provides the MFA platform. OSA configures and enforces the policy targeting all users. | Configure Conditional Access policy targeting all users. Maintain and review the policy exception list. | CSP service description § X; SSP § 3.5.3; Conditional Access policy export. |
Two things worth noticing in this example: the allocation is at the assessment-objective level (not just at the practice level), and the OSA still has work to do on objectives where the CSP provides the underlying capability. Inheritance is not the same as not having to do anything.
What goes wrong without a CRM
- The assessor cannot tell which controls are inherited and which are owned by the OSA.
- Apparent CUI Asset coverage by the ESP turns out to have OSA-side responsibilities the OSA did not implement.
- The OSA's SSP describes implementations the OSA cannot actually demonstrate because they were assumed to be the ESP's job.
- At assessment, the assessor concludes inheritance is undocumented and treats the affected practices as NOT MET.
Common errors
- Treating a vendor SOC 2 report as a CRM. A SOC 2 is an attestation, not a per-objective responsibility allocation.
- Treating a high-level shared-responsibility diagram as a CRM. A standard cloud-provider "shared responsibility model" diagram is not control-level enough for CMMC.
- Accepting the CRM without per-objective implementation summaries. The CRM must allocate each assessment objective, not just each practice.
- Not documenting the OSA-side responsibilities for shared controls. If the ESP provides the technology and the OSA has to configure it, the OSA's configuration responsibility must be in the SSP and supported by evidence.
Sources
- CMMC Assessment Scope, Level 2 (v2.13). External Service Provider Considerations, Customer Responsibility Matrix. link
- 32 CFR Part 170, § 170.19(c)(2). link
- NIST SP 800-171A, Assessing Security Requirements for Controlled Unclassified Information. Assessment objectives per practice. link
- DoW CIO FedRAMP Authorization and Equivalency Brief (Feb 2025). link
Review your ESP CRM with a Lead Assessor.
Wrightbrained Security reviews Customer Responsibility Matrices for completeness against the assessment objectives in NIST 800-171A.
Talk with a Lead Assessor