CMMC MSSP

Executive summary

Your MSSP becomes part of the CUI control environment.

A CMMC MSSP is a managed security services provider that can operate, document, and evidence security functions inside—or supporting—the system boundary where a defense contractor processes, stores, or transmits Controlled Unclassified Information (CUI). It is not a CMMC certification in a box, and it is not interchangeable with an independent assessor. The provider’s people, tooling, access paths, ticketing, escalation model, and records can become material to your System Security Plan (SSP), evidence library, and assessment narrative.

The choice matters more in 2026 because the CMMC Program Rule took effect on December 16, 2024, Phase I self-assessments remain in place, and the Department of Defense has suspended the planned Phase II rollout while reviewing the program. The final 48 CFR CMMC rule was published in September 2025 and became effective November 10, 2025. The pause changes timing; it does not make CUI safeguarding optional. Level 2 C3PAO assessments also remain an available certification path. Start by eliminating four disqualifiers: no US-persons-only CUI operations; an unverifiable Cyber AB role; a vague CUI data-handling or subcontracting model; and no credible way to map operating evidence to your SSP. Those are governance problems, not procurement details. The 32 CFR Part 170 final rule, DoD’s DFARS change notices, and DoD CMMC guidance provide the current program context; the Cyber AB’s role guidance distinguishes provider and assessor responsibilities.

Provider roles

What “CMMC MSSP” actually means

“CMMC MSSP” is a market description, not an official credential. It should mean the provider can help operate the technical and procedural controls that protect CUI, explain its responsibilities at an assessment-ready level of detail, and work cleanly with an independent assessor. Your evaluation should separate three roles.

RPO: readiness and implementation support

A Registered Practitioner Organization (RPO) delivers non-certified advisory services through Registered Practitioners. The Cyber AB describes RPOs as consultative organizations or MSPs that do not conduct certified CMMC assessments. An RPO signal is useful, but it does not validate a provider’s SOC design, CUI data handling, or managed-service quality. Verify the role in the Cyber AB ecosystem guidance and ask what the organization itself operates.

C3PAO: independent certification assessment

A CMMC Third-Party Assessment Organization (C3PAO) conducts assessments of Organizations Seeking Certification (OSCs) using certified personnel. The Cyber AB states that an authorized C3PAO contracts for and manages CMMC assessments; its assessment process describes it as an independent body that conducts assessments and issues certification. Treat this as an independence boundary: your MSSP may prepare systems and evidence, while a separate C3PAO assesses the organization. Cyber AB C3PAO requirements are a useful verification starting point.

RP and CCA: individual credentials, different functions

Registered Practitioners (RPs) provide implementation consulting and do not participate on assessment teams. A CMMC Certified Assessor (CCA) is an individual certification role; CCAs participate in authorized assessment work through a C3PAO. A provider with CCAs may have valuable assessment literacy, but it should still state clearly whether it is offering preparation, managed security operations, an assessment, or some combination through distinct organizations. The Cyber AB terminology and assessing-role guidance explain those distinctions.

For Level 2, the Program Rule ties the certification-assessment path to the 110 requirements of NIST SP 800-171 Revision 2. NIST has since published Revision 3, which supersedes Revision 2 as a NIST publication; contractors should track DoD transition direction and anchor their immediate plan to the requirements identified in their contract and CMMC assessment path. The CMMC Program Rule, NIST SP 800-171 Rev. 2, and NIST SP 800-171 Rev. 3 are the primary references.

CUI operating boundary

The provider boundary is as important as the system boundary

CMMC scoping is often treated as a diagramming exercise: identify the enclave, list the assets, mark the cloud tenant, and move forward. That is necessary but incomplete when a managed provider participates in the environment. The provider introduces a second boundary—the service boundary. It includes the people who receive alerts, the platforms that collect telemetry, the systems that store tickets and evidence, the privileged paths used to administer tools, and the processes that turn an event into a customer decision.

A defensible design begins by identifying the minimum data a service needs. Some monitoring use cases can be designed to avoid putting CUI into alerts, ticket descriptions, and routine analyst communications. Other workflows may legitimately require access to systems that contain CUI. Those cases must be named, approved, and protected. “We do not store customer data” is not a meaningful answer if an analyst can retrieve CUI through an endpoint console, an email security portal, a cloud administration tool, a remote support session, or a log query.

Ask the provider to walk one real detection from collection through closure. Which log source created it? What fields are visible? Where is the alert enriched? Who can open the case? Can a screenshot, attachment, or copied command output contain CUI? Where does the case live after closure? What does the provider retain for investigations, quality review, and customer reporting? The answer should create a reviewable data-flow narrative, not depend on a verbal assurance from a sales presentation.

Write the responsibility model before the implementation statements

A shared-responsibility matrix is the bridge between service description and SSP. For every provider-operated capability, record the system or service, control objective, provider task, customer task, accountable owner, operating frequency, evidence artifact, retention period, and escalation route. Use the matrix to test ordinary work: an administrator leaves, a detection rule changes, a vulnerability is found, an endpoint stops reporting, or a security event occurs on a weekend. If no owner or evidence exists for a scenario, the operating model is not ready.

The SSP should describe what is actually implemented, including inherited or external services and the interfaces that support the CUI environment. NIST notes that there is no prescribed SSP format or level of detail, but the required information must be conveyed. That flexibility is not permission for generic text. It is a reason to make the statement, responsibility, and evidence traceable. NIST’s Rev. 2 publication page is a useful reference for the scope and SSP context; the applicable contract and CMMC assessment materials govern the operational test.

Contract requirements and managed response are different clocks

An MSSP SLA measures the provider’s service performance: acknowledgement, triage, escalation, reporting, and response activities. DFARS obligations measure the contractor’s legal and contractual duties. Do not let a fast alert acknowledgement be presented as a substitute for an incident-reporting plan. The provider should be able to support your decision-makers with facts, preserved records, time-stamped escalation, and a repeatable process; your organization must still coordinate the contract-specific reporting path.

DFARS 252.204-7012 requires covered defense information to be safeguarded and sets a 72-hour cyber-incident reporting requirement, as well as a 90-day preservation requirement for affected media and relevant monitoring/packet-capture data. Other clauses and the CMMC clause may shape assessment status, eligibility, and flowdown in the contract. Use the current incorporated text, rather than a provider’s summary, as the decision source. DFARS 252.204-7012 and DFARS 252.204-7021 are the relevant starting points.

For a provider selection, the practical question is simple: can the service team give your incident commander enough actionable information early enough to make the right contractual decisions? Require a tabletop that includes an alert, a suspected CUI impact, provider escalation, legal and executive notification, evidence preservation, and the handoff to your reporting process. This demonstrates coordination without pretending that a managed service can assume your contractual obligations.

Cost math

Budget the operating model, not a compliance event

A credible CMMC budget has four lines: the gap assessment and boundary design; remediation and assessment preparation; the independent assessment; and recurring managed security services that keep controls operating. Your internal time belongs in the model too. An MSP quote that excludes evidence production, ticketing treatment, log retention, identity administration, incident coordination, or transition support may be inexpensive only because it leaves important work with your team.

Use the Department of Defense’s published estimates as a transparent planning anchor, not as a provider price sheet. The final rule estimates three-year Level 2 self-assessment costs of $37,196 for small entities and $48,827 for other-than-small entities. For the Level 2 certification-assessment path, the rule estimates $117,768 over three years for other-than-small entities. Those estimates include planning and preparation plus assessment and annual affirmation activities; they do not turn any individual MSSP proposal into an apples-to-apples comparison. DoD’s 32 CFR Part 170 economic analysis is the source for those figures.

The calculation is deliberately simple: three-year provider fees + C3PAO assessment costs + remediation + internal labor + transition risk. Do not subtract the last two categories because they are difficult to estimate. Put them into the RFP assumptions and force variance into the open.

Selection plan

How to select a CMMC MSSP in 90 days

1. Days 1–10: define the decision boundary. Collect contracts, prime directives, CUI flows, system inventory, current SSP/POA&M, cloud tenants, monitoring stack, and assessment history. Decide what is in scope before you ask a provider to price it.
2. Days 11–20: assign responsibilities. Build a control responsibility matrix: what your team owns, what the provider owns, what is shared, what is inherited, and how each claim will be evidenced.
3. Days 21–35: screen the shortlist. Use US-persons CUI operations, provider-role verification, relevant architecture experience, transparent dependencies, and CUI-aware incident operations as gate criteria.
4. Days 36–50: run the 12 questions. Require written responses. Meet the people who will operate the service, not only the sales team. Resolve contradictions between the answer, architecture, contract, and SSP language.
5. Days 51–65: test evidence and resilience. Review a sanitized SSP section, a sample evidence index, incident workflow, access-review process, change record, and data-return plan. Ask how the team performs under a surveillance or customer audit.
6. Days 66–80: normalize the three-year cost model. Compare scope, onboarding, remediation, managed-service operations, retention, assessment preparation, exit, and internal effort. Exclude no important operating task merely because it sits outside the monthly fee.
7. Days 81–90: award and mobilize. Attach the responsibility matrix, service levels, evidence cadence, CUI access commitments, data ownership, and transition terms to the agreement. Launch with named executive and technical owners.

This discipline is particularly important as the program evolves. DoD’s 2025 audit found weaknesses in the process for authorizing organizations to perform CMMC Level 2 assessments, reinforcing why buyers should independently validate roles and avoid relying on marketing labels. DoD IG Report DODIG-2025-056 provides the underlying finding. CISA also maintains a concise CMMC 2.0 program resource for baseline program orientation.