There is an artifact your assessor is going to ask for that a lot of contractors do not have, and if you have one, it may not survive scrutiny. It is called a Shared Responsibility Matrix, sometimes a Customer Responsibility Matrix, sometimes just "the SRM." Same document, three names. It is the piece of paper that says, control by control, who is actually doing the work.
Half of the contractors we talk to either do not have one or point at a Microsoft PDF they downloaded once and never revisited. Neither answer holds up in an assessment. This piece walks through what the document should contain, where the rows tend to get fuzzy, and how to build one that a Lead Assessor will accept without a follow-up meeting.
What the CRM Actually Is
In plain terms, a CRM is a spreadsheet with one row per NIST SP 800-171 requirement (110 rows for a Level 2 environment) and enough columns to answer, for each row, who implements the control, how it is implemented, and where the evidence lives. That is it. The complexity does not come from the shape of the document, it comes from being honest about the answers.
The naming quirk is worth clearing up because it trips people up in meetings. Cloud providers usually publish a "Customer Responsibility Matrix" (CRM), where the columns emphasize what the customer has to do on top of what the provider covers. Contractors and MSPs increasingly publish a "Shared Responsibility Matrix" (SRM), because the same artifact spans more than one relationship. Same rows, same purpose, different name depending on who is standing in front of the whiteboard.
The CRM lives alongside your SSP and POA&M. The SSP describes the system and how each control is implemented in it. The POA&M lists the ones that are not yet fully in place. The CRM is what the assessor uses to figure out which party they should be asking about a given control. Without it, they have to reconstruct that mapping from the SSP text, and they will not enjoy the process.
Why Assessors Ask For It
Two reasons, and they both come down to time. First, a matrix is the fastest way for a Lead Assessor to see where inherited controls actually rest. If the contractor claims inheritance from GCC High for AC.L2-3.1.5, the assessor is going to want the Microsoft artifact that backs it. The matrix is the fastest path to that artifact, or the fastest way to discover it does not exist.
Second, a matrix surfaces the seams. Real environments are stacks. A cloud provider on the bottom, an MSP or MSSP in the middle, the contractor on top. Between every two layers there is a seam, and seams are where controls fall through. A well-built CRM makes it obvious which side of every seam owns which piece. A missing matrix, or a matrix with "shared" written in every row, hides the seams and leaves the assessor to find them the hard way.
If you are new to how external service providers factor into scope, our CUI scoping piece walks through the basic framework. The CRM is where that framework becomes a concrete artifact.
The Columns That Matter
There is no legally required column layout, but a matrix that survives assessment usually has these fields, in roughly this order. Fewer than this, and the assessor will start filling in blanks with questions. More than this, and the extras rarely earn their keep.
- Requirement ID. The 800-171 control number, like AC.L2-3.1.5. One row per requirement.
- Requirement text. The actual language of the control. Do not paraphrase. Assessors compare to source.
- Cloud provider contribution. What the underlying platform covers, if any. Cite the provider's published CRM or attestation document.
- MSP or MSSP contribution. What the managed service layer implements on top of the platform. Cite the MSP's own CRM or the relevant section of the master services agreement.
- Contractor contribution. What you actually do inside your organization. This is the part contractors most often shortchange. If your MSP configures MFA but your policy and enforcement decisions are yours, say so.
- Ownership summary. One of: Contractor, MSP, Cloud, or Shared. Shared should be a small share of the rows, not most of them.
- Evidence pointer. Where the assessor can go look. Link to the SSP section, the MSP report, the provider's SOC 2, whatever backs the row.
Keep the language spare. This is a working document, not a marketing artifact. If a row needs a paragraph, the paragraph belongs in the SSP with a pointer from the matrix.
Stacked CRMs: How Real Environments Actually Look
Almost every environment we look at is a stack. A cloud provider on the bottom, an MSP running the middle, the contractor on top. Each layer publishes its own responsibilities. The contractor's CRM is what stitches the layers together into a single row for each requirement.
Bottom layer, the cloud provider. Microsoft GCC High publishes a CRM that describes what Azure and Microsoft 365 GCC High cover under the shared responsibility model. AWS GovCloud has an equivalent. Google Workspace GCC has one as well. Download the current version. Do not use the copy you grabbed in 2023. Providers update these on their own cadence and your CRM has to reference what is live now.
Middle layer, the MSP or MSSP. If your MSP handles patching, monitoring, backup, or SIEM, they are running a chunk of the 110 for you. A responsible MSP will hand you a CRM against the requirements they cover, tied to the specific services in your contract. If they will not, that is a red flag worth taking seriously. See our CMMC software landscape for how the MSP layer varies.
Top layer, the contractor. Governance, personnel decisions, physical security at your own sites, incident response coordination, and every configuration choice you or your MSP made on your behalf. This layer is almost always underweight in draft CRMs. The temptation is to push everything down into the stack and inherit it. Assessors will not accept that.
The final CRM is one row per requirement, closed out at the top layer. Every row has a named owner. Every row has an evidence pointer. Every row with "inherited" as its answer has a provider or MSP artifact backing it.
Where the Rows Actually Break Down
Not all 110 rows behave the same way. Some cluster naturally with the cloud provider, some with the MSP, some almost always with the contractor. Rough shape of how the ownership tends to distribute:
- Cloud-heavy clusters. System and Communications Protection (SC), Media Protection (MP), and much of Audit and Accountability (AU). When CUI lives in GCC High, encryption in transit and at rest, FIPS-validated cryptography, and audit log retention are largely platform-provided. Inheritable, but only against a current provider CRM.
- MSP-heavy clusters. Configuration Management (CM), System and Information Integrity (SI), and much of Audit operations. Patching, vulnerability scanning, SIEM operations, and endpoint hardening usually sit with whoever runs the environment day to day, and for most small and mid-size contractors that is an MSP.
- Contractor-heavy clusters. Awareness and Training (AT), Personnel Security (PS), Physical Protection (PE), most of Risk Assessment (RA), and Security Assessment (CA). No cloud provider can train your people. No MSP can decide who has a need to know. These are governance controls and they live with you.
- Shared clusters, done honestly. Access Control (AC) and Identification & Authentication (IA). The platform provides the mechanisms, the MSP may operate them, but the policy decisions (who gets access, how MFA is enforced, how privileged access is reviewed) are yours. A CRM that says "shared" on all of AC and IA is under-specified. A CRM that names, per row, which specific piece is yours and which is inherited is doing the job.
For a walkthrough of a single row done well, see the MFA requirement piece and the replay-resistant authentication piece. The pattern in those two rows is the pattern you want across all 110.
The Traps
Five failure modes show up over and over. If any of these describe your current CRM, fix them before an assessor sees the document.
- "Inherited" without an artifact. If a row says inherited, the assessor is going to ask for the provider or MSP document that backs it. If the answer is a shrug, the row is not inherited, it is undocumented.
- An outdated provider CRM. Microsoft, AWS, and Google update their CRMs on their own schedule. Referencing a 2023 version of the GCC High CRM in 2026 is a finding waiting to happen.
- "Shared" on most rows. "Shared" is fine as a summary label when the responsibility is genuinely split, but the split has to be named in the row body. A CRM with "shared" on most of the 110 is a CRM that punted.
- Silence about MSP scope changes. Contractors change MSPs. Contractors add or drop services. The CRM has to change with them. If your CRM does not reflect the MSP you actually have today, it is describing a system that does not exist.
- No pointer to evidence. A row that names an owner but does not tell the assessor where to look for proof forces the assessor to guess. Assessors do not enjoy guessing. Add the pointer.
We will send the next CMMC update the day it lands.
Shared responsibility guidance, cloud provider CRM updates, and any move by the reform task force that changes what assessors expect. Leave a work email and we will send the analysis the day each development lands. No fear-mongering, just what changed and what to do about it.