CMMC Shared Responsibility Matrix Who Owns Each of the 110 Controls

Every cloud platform publishes a shared responsibility model: the provider secures the physical data centers, the hypervisor, and the managed services it operates, and the customer secures what it builds and configures on top. That model is a picture. A shared responsibility matrix is the same idea expressed as a table with one row for every security requirement your contract obligates you to meet. For a defense contractor pursuing CMMC Level 2, that means one row for each of the 110 requirements in NIST SP 800-171, and for each row a clear answer to four questions: who implements it, who operates it day to day, who produces the evidence, and what the customer must still do to complete it.

The matrix exists because a control is only satisfied when the whole control is satisfied. Take requirement 3.5.3, multifactor authentication. A cloud identity platform can enforce MFA on every login, but it cannot decide which of your accounts are privileged, enroll your employees, or remove the contractor who left last month. If your SSP says "MFA is provided by our cloud platform" and stops there, an assessor will ask who enrolls users and who reviews the exceptions, and "the vendor" is not an answer the vendor agreed to. The matrix prevents that gap by forcing each half of the control to have a named owner before assessment day.

The CMMC Program rule uses the term customer responsibility matrix, abbreviated CRM. Cloud providers publish documents titled customer responsibility matrix or customer implementation summary. Managed service providers and consultants say shared responsibility matrix, and some assessors say SRM. These are the same document with different labels, and the distinction that matters is not the name but the content: one row per requirement, unambiguous ownership, and a description specific enough that your SSP can cite it. As Craig Petronella, CMMC Registered Practitioner and author of the CMMC 2.0 Certification Guide, explains in the book's treatment of system security plans, a control description that cannot name the person or provider who performs the control is a plan of action waiting to be written.

One more distinction is worth fixing early. A service description tells you what the provider does. A responsibility matrix tells you what the provider does for the purpose of your assessment. The rule requires both from an external service provider, and they are not interchangeable. A glossy services overview that says "24/7 monitoring" does not tell an assessor whether the provider satisfies 3.3.1 audit logging, 3.3.5 audit correlation, or 3.14.6 monitoring for attacks, and it certainly does not say which of those you still have to do yourself.

The practical reading of that table: if you hold CUI and anyone outside your company runs infrastructure, identity, email, storage, backup, endpoint security, or monitoring for the systems that hold it, you need a matrix from that provider, and you need to have folded it into your SSP before you post a score to SPRS or sit for a C3PAO assessment. The rule's language is deliberate: "documented or referred to" means you may cite the provider's matrix rather than copying it, but the citation has to resolve to a real document an assessor can open.

Security protection data is the category most contractors miss. It is the information your security tools generate and hold about your CUI environment: audit logs, vulnerability scan results, configuration baselines, endpoint telemetry. A managed security provider that never sees a single CUI document still holds all of that, and the rule brings that provider into scope on that basis alone.

The test is whether CUI or security protection data is processed, stored, or transmitted on the provider's assets, or whether the provider's people and tools reach the assets that hold it. Reach is the part that surprises companies. An MSP that has never been sent a drawing but whose remote management tool can open a session on every workstation processes CUI in the sense the rule cares about. That is why the scoping step in a CMMC scoping engagement inventories provider access alongside CUI locations before anyone writes a control description.

A responsibility matrix that will survive assessment has six columns at minimum. The first is the requirement identifier and its text, using the NIST SP 800-171 numbering your SSP already uses so the two documents line up row for row. The second is the responsibility assignment: provider, customer, shared, or not applicable to this service, and "shared" is only acceptable when the next column explains the split. The third is the provider's implementation statement, which describes what the provider actually does to satisfy its part, in enough detail that you could quote it in your SSP. The fourth is the customer responsibility statement, which describes what you must configure, operate, or document to complete the control. The fifth is the evidence column, naming the artifact each party produces: a report, a configuration export, a log sample, a policy. The sixth is the inheritance basis for any provider-owned control, which for a cloud offering points to the FedRAMP authorization or equivalency package.

Four responsibility types cover nearly every row. Provider-owned controls are fully implemented and evidenced by the provider; physical protection of a cloud data center is the classic example, and your only job is to cite the inheritance. Customer-owned controls are entirely yours even though the service is involved; deciding which users get accounts is always yours. Shared controls are split at a boundary the matrix must describe, such as the provider enforcing an encryption capability while you decide where it is applied. Not applicable is reserved for requirements the service genuinely does not touch, and a matrix that marks half of the 110 requirements not applicable is telling you the provider did not do the work.

The matrix then has to land in your System Security Plan. For each requirement, the SSP names the responsible party, references the provider's matrix row where a provider is involved, and describes your side of the implementation in your own words. Where the matrix reveals a customer responsibility you have not met, that requirement goes on your plan of action and milestones with a date and an owner. This is where a provider matrix earns its keep: it converts vague comfort ("our cloud is FedRAMP") into a specific list of things you still have to do, and it surfaces that list months before an assessor does.

Notice that no row is entirely the provider's. That is the pattern across all 110 requirements: cloud and service providers carry the infrastructure half of a control, and the governance half stays with the organization seeking certification. Companies that read "provider" in the first column and stop reading are the ones who arrive at assessment with a FedRAMP package and no evidence of their own.

A defense contractor that asks its MSP for a customer responsibility matrix is not being difficult; it is complying with the rule. The provider's choices are to produce a defensible matrix, to accept being assessed inside every client's assessment with no prepared evidence, or to lose the client to a provider that has done the work. Producing the matrix means walking all 110 requirements against each service you sell, deciding honestly where your responsibility ends, and writing implementation statements a stranger could verify. It also means committing to the evidence column: if the matrix says you retain logs for a year, you will be asked for a sample.

Providers that handle CUI in a cloud offering have the harder path, because FedRAMP Moderate authorization or equivalency is a condition of the service being usable at all. Providers that handle only security protection data avoid the FedRAMP requirement but not the matrix. Either way, the matrix is now a sales document as much as a compliance one. Petronella Technology Group has been on both sides of this exchange since the CMMC rule took effect, as a CyberAB Registered Provider Organization (RPO #1449) preparing contractors for assessment and as a managed security provider whose own services are described in client SSPs.

One client review describes the working relationship this requires: "Craig and his team treat your business like it's their own. That level of care and dedication is rare, and it's why we keep coming back." (Milo Rivera, TrustIndex verified review; Petronella Technology Group is rated 4.7 across 92 verified TrustIndex reviews.)