What Goes in a CMMC Responsibility Matrix?

A Cybersecurity Maturity Model Certification (CMMC) responsibility matrix should identify each provider service, the security requirements it supports, the tasks retained by the contractor, and the evidence each party supplies. Tie those assignments to the system boundary, contract, and actual operating procedures, rather than marking an entire control “outsourced.” (DoD guidance)

The Department of Defense (DoD) requires relevant external service provider relationships to be documented in the system security plan and described through a service description and customer responsibility matrix. The practical buyer question is whether those documents describe the same service you are purchasing (DoD Level 2 Scoping Guide, September 2024). The governing provision is in Title 32 of the Code of Federal Regulations (CFR), section 170.19 (CMMC scoping rule).

What are the key takeaways?

• Define the provider boundary using controlled unclassified information (CUI) and security protection data (SPD), not the provider's marketing label (DoD scoping guidance).
• Assign a named owner for configuration, monitoring, approval, evidence production, and exceptions.
• Ask the provider to demonstrate one shared requirement from configuration through assessment evidence.
• Keep the matrix consistent with the system security plan (SSP) and service description (32 CFR 170.19(c)(2)).

Which providers belong in the matrix?

Start with providers whose services process, store, or transmit CUI or SPD within the relevant assessment scope. The DoD guidance defines an external service provider (ESP) by the services and data involved, not simply whether the company calls itself a managed security service provider (MSSP) (DoD Level 2 Scoping Guide).

SPD includes security-relevant information such as log data, configuration information, and vulnerability information. The guidance specifically discusses external security information and event management (SIEM) services, including log storage, when explaining assessment scope (DoD guidance, security protection assets and ESPs).

Our recommendation is to inventory the actual service chain before filling in a spreadsheet. Include the monitoring provider, the platform holding telemetry, any separate archive, and administrators who can change collection. Ask who operates each component and where its evidence will come from. A reseller name on an invoice is not an adequate description of the operating boundary.

Document exclusions just as carefully as inclusions. If a service is outside the proposed scope, record the technical and contractual reason, the data it cannot access, and who verifies that limitation. Do not accept “we do not handle CUI” as the entire answer when the service holds security logs or manages protective capabilities.

What columns should a useful matrix contain?

Use columns that let an assessor or incident responder follow a responsibility to an owner and an artifact. We recommend the following checklist as a practical design, not a claim that DoD mandates this exact spreadsheet format.

1. Requirement and objective: identify the requirement and the specific activity being allocated. Avoid a single shared checkbox when parties perform different steps.
2. Service and assets: name the covered tenant, tools, systems, and data flows. Reference the service description and boundary diagram.
3. Provider action: describe what the provider configures, reviews, retains, or reports, including any prerequisites.
4. Customer action: identify approvals, local configuration, account administration, and business decisions that remain with the contractor.
5. Evidence and custodian: state the artifact, storage location, access method, retention decision, and person responsible for retrieving it.
6. Operating trigger: specify whether work occurs during onboarding, on a schedule, after a change, or when an alert appears.
7. Exception and acceptance: name the decision owner and the process for documenting gaps, compensating measures, and closure.

How should you divide a shared security activity?

Break the activity into observable handoffs rather than giving both parties identical responsibility labels. For a monitoring service, our illustrative division would separate log onboarding, alert review, containment authorization, and evidence export.

The contractor might identify business-critical systems and approve collection, while the provider configures agreed integrations and checks ingestion. The provider might investigate an alert, while a designated contractor manager decides whether a production system can be isolated. Whoever makes that decision should be reachable through an agreed escalation route.

Then test the evidence handoff. Ask for a sanitized example showing the detection, analyst assessment, escalation, approval, action, and closure record. Use synthetic records if production evidence would expose sensitive information. This is a procurement demonstration, not a claim that one demonstration establishes compliance.

Write down what happens if the contractor does not respond or an integration stops sending data. Those are service-design questions worth resolving before assessment preparation. A matrix that describes only the successful path leaves the most consequential decisions undefined.

Does a provider certificate replace shared evidence?

No. The applicable treatment depends on the provider type, the data involved, and the services within scope. Under 32 CFR 170.19(c)(2), relevant non-cloud ESP services may be assessed as part of the organization seeking assessment; a separate certificate is not a universal substitute for documenting that relationship (CMMC provider-scoping requirements).

Cloud service providers handling CUI are subject to the Federal Risk and Authorization Management Program (FedRAMP) requirements referenced in Defense Federal Acquisition Regulation Supplement (DFARS) 252.204-7012. SPD-only services are treated differently under the CMMC scope rules, so do not apply the CUI cloud rule indiscriminately to every logging tool (32 CFR 170.19 provider table).

Ask the provider to explain which assessment or authorization evidence applies to the exact offering, deployment, and service period. Keep that evidence alongside the responsibility matrix, rather than replacing the matrix with a certificate. Escalate ambiguous scope interpretations to the appropriate assessment and contracting advisers.

For the related buying distinction, read whether your MSSP needs CMMC certification. Use that discussion to challenge an unsupported sales claim, not to assume that every provider has the same obligations.

How would our SOC validate the handoffs?

Our U.S.-based security operations center (SOC) would walk through a hypothetical account compromise with the contractor. We would ask who receives the alert, who can disable access, who approves disruptive action, and who exports the investigation record. We would compare those answers with the matrix and the contracted service.

We would also test an unavailable approver and a missing log source. The aim is to expose an ownership gap while it is still a planning problem. This describes our proposed review method, not a customer incident or an assurance that a tabletop exercise proves every requirement is satisfied.

A practical acceptance package should include the approved matrix version, its linked service description, the relevant SSP references, and an unresolved-issues register. Put a review trigger in the change process so new tools, new data flows, or a different subcontractor do not silently invalidate the arrangement.

What should you ask before signing the service order?

Ask for a jointly reviewed draft matrix before treating the service as assessment-ready. Require the provider to identify evidence that is included, evidence that costs extra, and evidence that depends on customer configuration.

Our CMMC compliance services can support that boundary review, while the CMMC readiness checklist helps organize the broader preparation work. Keep the purchasing decision grounded in demonstrated tasks and retrievable evidence, rather than a promise to “cover CMMC.”

What else should buyers know?

Is a responsibility matrix the same as an SSP?

No. The provider relationship belongs in the SSP, while the service description and customer responsibility matrix describe the relevant services and responsibilities. Keep the documents aligned (DoD Level 2 Scoping Guide).

Can a log-only provider be in scope?

Yes. Security protection data can bring relevant provider services into the assessment scope even when the provider does not handle CUI (32 CFR 170.19(c)(2)).

Who should approve the matrix?

We recommend joint review by the contractor’s security owner and the provider’s accountable service owner, with assessment and contracting advisers resolving disputed boundaries. Record approval and version history.

When should the matrix be reviewed?

We recommend review when services, tools, data flows, administrators, or contractual responsibilities change, and before assessment evidence collection. Verify actual practice rather than simply renewing the document date.

Need help defining the next step?

Bring your service description, proposed boundary, and draft matrix to a focused readiness discussion. Get a CMMC readiness assessment or Call 833-92-CYBER to discuss scope and ownership.