FedRAMP authorizes cloud service providers (CSPs) to host US government data. FedRAMP authorized CSPs must develop a Customer Responsibility Matrix (CRM) Worksheet as Appendix J of their System Security Plan (SSP). The CRM Worksheet describes what the CSP provides to the customer and what responsibilities customers have for each control. Federal customers use the CRM Worksheet to define all the controls they will need to engineer, design, define, and implement to be in compliance with the FedRAMP baseline. Nonfederal customers may use the CRM Worksheet to identify control reciprocity relative to CMMC or other NIST SP 800-171-based security requirements. The nonfederal use case requires translating FedRAMP and CMMC controls. Before claiming full inheritance for any given requirement, practitioners should consider the applicability of security requirements within their authorization boundary.
The best guidance for FedRAMP reciprocity for NIST SP 800-171-based requirements comes from Answer 116 on the DoD Procurement Toolbox Cybersecurity FAQ.

The answer delineates between requirements applied to CSPs and their nonfederal customers. CSPs have to meet requirements within their FedRAMP baseline. Their nonfederal customers have to meet all requirements within NIST SP 800-171. They reference Table D within NIST SP 800-171 as the official mapping between the publications. Nonfederal customers must implement responsibilities assigned to them in the CRM that map to NIST SP 800-171 requirements, which may be different from the SP 800-53 implemented by the CSP. Some controls may require a reciprocal implementation by the customer for the CSP’s control to be effective.
The Title 32 Proposed CMMC rule allowed for the acceptance of FedRAMP environments to meet CMMC requirements.

The CMMC Program Final rule requires nonfederal organizations to document how they meet their CSP’s requirements assigned in CRM within their SSP.

The SSP does not need to incorporate language from a FedRAMP Authorized CSP’s SSP.

Nonfederal organizations must include all components of the information system within their authorization boundary. The system's authorization boundary does not encompass external systems with their own authorizations. FedRAMP authorized cloud services are classic examples of systems with their own authorizations. Your system should document responsibilities assigned through the CRM and address the requirements applicable to your own authorization boundary. In other words, your boundary does not include the cloud service, that is the CSP’s boundary. Your authorization boundary is your infrastructure connecting to the CSP.

We recently reviewed two SSPs that passed a CMMC C3PAO assessment. Each control had a narrative for their cloud services (when relevant) and a narrative for their own infrastructure. The cloud service narrative cited inherited controls and documented shared responsibilities. For example, an implementation statement for AC.L2-3.1.1(a) would read:

Microsoft bundles two cloud services into 365 Government (GCC High). Each service (Office 365 and Azure) has their own FedRAMP authorization. Microsoft's Body of Evidence (BoE) documents compliance with the FedRAMP security control baseline. Within the BoE is the Control Implementation Summary (CIS) & CRM. The CRM identifies the controls a customer may inherit. When controls are not inheritable, the CRM describes the customer's responsibilities.
Microsoft considers their BoE sensitive and confidential information. Microsoft will allow for customers to access the BoE under a Non-Disclosure Agreement (NDA). If you have your Microsoft NDA handy and can provide the document ID, it can save time during the request. To request the BoE, you must be a customer and make an E-mail request to:
In order to pull content from a CRM Worksheet into your SSP, practitioners must translate NIST SP 800-53 Rev 5 into CMMC Level 2 (currently based on NIST SP 800-171 Rev 2). Let’s review the CRM Worksheet and walk through a few crosswalk examples.

The first column of Microsoft’s CRM Worksheet uses a Control ID that identities each control part. A control part sits between the control level (e.g. AC-1) and an assessment objective level (e.g. AC-01a.[01]). All assessment objectives that begin with “AC-01a.” roll up to the control part AC-01(a). The second column identifies whether the customer can inherit the control part. These values include Yes, No, or Partial. The third column identifies customer's responsibilities when a control is not inheritable.
The mapping challenge stems from Table D of SP 800-171 Rev 2. NIST identifies relationships to SP 800-53 Rev 4 controls but FedRAMP standards now use SP 800-53 Rev 5. Many controls allow inheritance of some parts but shared responsibilities for other parts. Table D does not relate SP 800-53 parts to SP 800-171A objectives. Many SP 800-171 security requirements may map to many SP 800-53 controls.
We developed this resource to identify the parts of SP 800-53 Rev 5 controls related to SP 800-171 Rev 2 assessment objectives. We identified security requirements relationships to SP 800-53 controls using Table D of NIST SP 800-171.

We isolated SP 800-171 objectives and identified the relevant part(s) of each SP 800-53 control for each. We tried to stay within the parameters provided by Table D. In some instances we went outside this mapping guidance. For example, 3.13.14 mapped to SC-19 which NIST deprecated in Revision 5. We updated this mapping to SC-7(a).

We provided the relationships to a large language model (Gemini). In the prompt, we asked Gemini to categorize the functional relationships according to the Set Theory mapping style defined in NIST SP 8477 and rate the strength of each relationship. This is an important step that is often overlooked. Remember the guidance from the DoD Procurement Toolbox that states:

Our resource has two sheets. The crosswalk sheet contains the following headers:

The CRM Worksheet includes the guidance from Microsoft’s CRM Worksheet. Row three includes the headers for the CRM Worksheet table. We cannot provide the table from the CRM Worksheet. Microsoft considers their BoE sensitive and confidential information. Once you get the CRM, you can paste the table data into this section. Formulas on the Crosswalk sheet will pull in the relevant responsibilities and inheritance.

K2 GRC can import the inherited controls from the CRM Worksheet relative to a cloud service. We also present the shared responsibilities when the practitioner writes the implementation statements. The image below shows the point at which a practitioner is documenting the implementation of AU.L2-3.3.3(a). K2 GRC presents a relevant section of their Audit and Accountability Policy. Below the related policy statement is an informative reference to NIST SP 800-53 Rev 5. By establishing a relationship between AU-02(e) and AU.L2-3.3.3(a), we can cite responsibilities assigned from the CRM Worksheet. This workflow makes it easier for the practitioner to cite the CRM and relevant sections of their own policy.

Integrating Microsoft’s FedRAMP authorization into your CMMC system security plan doesn’t have to feel like translating Hieroglyphs to Greek. Since NIST derived many CMMC security requirements from NIST SP 800-53 Rev 4, Table D within NIST SP 800-171 gets you most of the way there. Having a more detailed crosswalk makes this a much easier process.
Here’s a final checklist to move you forward with this initiative: