Writing the Customer Responsibility Matrix Section of a System Security Plan: Shared Responsibility With a Cloud Provider

Why this section exists

A system security plan, or SSP, describes how you meet each security requirement for the systems that handle controlled unclassified information, or CUI. When part of that system runs in a cloud service, the provider operates the data center, the hypervisor and often the platform software. You still carry the rest. The customer responsibility matrix is the provider's own statement of where that line sits.

The CMMC rule says so directly. Section 170.16(c)(2) allows a Level 2 self-assessment to use a cloud service provider when the offering is FedRAMP Authorized at Moderate or higher, or meets requirements equivalent to Moderate in accordance with DoD policy. It then says the security requirements from the CRM must be documented or referred to in the contractor's SSP. Section 170.16(c)(3) says the same for external service providers that are not cloud providers, and adds that the relationship and services must be described in the SSP and in the provider's service description and CRM.

What a matrix looks like

There is no single required format, but most follow the pattern of the FedRAMP program, where authorized providers publish a matrix next to their security documentation. Each row is a control or requirement. Each row is marked in one of a few ways:

• Provider responsibility. The provider performs it and can show evidence, so you inherit it.
• Customer responsibility. You perform it entirely, for example choosing who gets an account.
• Shared. Both sides do part. The provider supplies a feature and you must configure and operate it, such as audit logging that exists but is off until you turn it on.
• Not applicable, with a reason, for example a physical control that cannot apply to a software service.

Providers write the matrix for their offering. It is generic by design. Yours is specific: your tenant, your users, your settings. That is the gap your SSP section fills.

The shared responsibility rule of thumb

Microsoft Learn explains shared responsibility by service model: with software as a service, the provider carries more; with infrastructure as a service, you carry more. Across all of them, the same page says the customer is always responsible for its data, its endpoints and the accounts and access management that touch the service. Treat that as your floor. If a provider matrix seems to hand you less than that, read it again.

Build the section requirement by requirement

For each of the 110 requirements in NIST SP 800-171 Rev. 2, write one short block in your plan. A block that works has the same five parts every time:

• Who is responsible: provider, you, or both, taken from the current version of the provider's matrix.
• What the provider does, in one sentence, with a pointer to the provider document that says it.
• What you do, in specific terms: the setting, the policy, the role, the review schedule.
• Who on your team owns it by role title, not a personal name that will go stale.
• Where the evidence lives: a screenshot, an exported configuration, a report, a ticket.

Take multifactor authentication as an example. The matrix may say the provider offers it and the customer enables it. Your block says that administrators and all users reach the CUI environment only through sign-in that requires a second factor, who manages the policy, and where the sign-in policy export is saved. That is a statement an assessor can test. "Provider handles identity" is not.

Cover the connection too

Section 170.16 states that your on-premises infrastructure connecting to the cloud offering is part of the assessment scope. So the plan needs the laptops, the network path, the VPN or direct connection and the people who administer the tenant. Draw the boundary once, show where CUI enters and leaves, and link each requirement block to the part of the boundary it covers.

What an assessor looks for

• The matrix is current and matches the exact product and service tier you buy. A matrix for a sister product does not count.
• The provider's authorization or equivalency claim names the same offering. Check the FedRAMP Marketplace listing rather than a sales page.
• Every requirement has a named responsible party. Blank rows and "see provider" with no document are the common flags.
• Shared rows are split into two statements, one for each side.
• Your statements match reality. If the plan says logs are kept for a year, the setting and a sample must show it.
• Inherited items cite a provider document by name and version, so the claim can be traced.
• The plan names the provider's incident reporting duties and how you will learn of an incident, since a cloud provider handling CUI has its own obligations under the contract.

Common mistakes

• Pasting the whole provider matrix into the appendix and calling the section done.
• Marking everything as inherited to shorten the plan.
• Forgetting the provider changed its matrix. Set a review date each time the provider publishes a new version and when you change the service.
• Treating a SOC 2 report or an ISO 27001 certificate as the matrix. They are different documents with a different purpose.
• Leaving out the second or third provider: email filtering, backup, remote support tools. Each one that touches CUI needs its own row set.

A practical way to start

Collect the provider's matrix and service description. List your CUI data flows. Mark each requirement with who does it. Write the five-part block for every requirement you own or share. Attach evidence. Then have someone who did not write it try to test three statements against the live system. Fix what fails and date the review.

We help contractors build and test this section as scoped, authorized work. We do not act as your CMMC assessor and we do not promise any assessment outcome.

Sources

• 32 CFR 170.16, Level 2 self-assessment and scoping with a cloud service provider (eCFR)
• Shared responsibility in the cloud (Microsoft Learn)
• NIST SP 800-171 Rev. 2, Protecting Controlled Unclassified Information (NIST)
• FedRAMP, the federal cloud authorization program

This article is general information, not legal, contracting or technical advice for your environment. Contract clauses, DoD policy and certification rules are set by the Department of Defense and your contract; check what applies to you with your prime, your contracting officer and counsel. Last reviewed November 9, 2026.

Next article

Next · RegulationFIPS 140-2 vs 140-3 Validated Modules: How to Read the NIST CMVP List and What 3.13.11 NeedsRequirement 3.13.11 asks for FIPS-validated cryptography to protect controlled information. A vendor saying a product is FIPS compliant does not meet that. This article explains the NIST validation list, the difference between the 140-2 and 140-3 standards, the 2026 sunset date, and a short checklist for reading a certificate.8 min read

Related reading

• RegulationK-12 Student Data Security: FERPA, COPPA and CIPA in Plain Words, and How to Vet an Edtech Vendor8 min
• RegulationWhat a CMMC Level 2 Assessor Examines, Asks and Tests: Evidence and Six-Year Retention9 min