Does CMMC apply to an MSP or MSSP, and what does it cost them?
An MSP or MSSP is an external service provider (ESP) in CMMC scope only when controlled unclassified information (CUI) or security protection data, such as logs and configuration data, is processed, stored or transmitted on its assets. A provider that supports a defense contractor's network without touching either is outside the assessment boundary. Where it is in scope, the customer's assessment decides how much of the provider is examined, because a non-cloud ESP is treated as an extension of the contractor's environment and is accountable for every user with access to CUI through its service. Ask each customer which of your people, tools and facilities they will need to evidence.
Contract timing matters as much as scope. On 13 July 2026 the Department of War suspended CMMC Phase II, which had covered the Level 2 certification requirement for applicable contracts. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place, so a contractor may still need you to show evidence for their self-assessment. Confirm each customer's current contract requirement in writing before you commit staff or budget, and check the status on the DoW CIO About CMMC page, since the implementation schedule has been changing.
Cost and effort depend on three drivers: how many defense customers you serve, which of your assets touch CUI or security protection data, and whether you pursue your own Level 2 certificate. Serving many customers from one shared SOC multiplies the evidence each customer's assessor may request, while a dedicated tenant for one customer narrows it. A voluntary certificate for your own ESP is an option, not a requirement, and it can reduce the effort during customer assessments. When you request quotes from consultants or assessors, ask them to price each customer's scope separately, to state which costs are one-time and which recur, and to name the evidence they will produce for you.
Which MSP services make the provider an ESP, and which do not
Whether a managed provider counts as an External Service Provider depends on what it does for the contractor and whether CUI or security protection data sits on its assets. The cards below cover the roles the CMMC rule describes, from staff augmentation that needs no assessment to a shared SOC that is external even inside one corporate group. Check each role against your own contracts and environment before you assume an outcome.
Staff augmentation with contractor-run processes
A provider that supplies people only, while the contractor supplies all processes, technology and facilities, falls outside the ESP assessment path. The CMMC rule says this arrangement needs no CMMC assessment. Check whether your contractor really controls the tools, tickets, admin accounts and facilities the staff use. If your engineers log in to the provider's own consoles or hold CUI on its laptops, the arrangement stops looking like staff augmentation and needs a fresh scoping decision.
Non-cloud technical support provider
A provider that delivers technical support on systems that are not cloud services is an MSP under the rule, and it is an ESP if CUI or security protection data such as logs and configuration data touches its assets. Its staff are then part of your assessed environment for every user who can reach CUI through its service. Confirm where its remote-support tools, jump hosts and ticketing systems store customer data, and whether they hold your logs or configuration exports.
Provider that manages a third-party cloud service
An ESP that runs a cloud platform on the contractor's behalf is not itself a cloud service provider under the rule, even though it operates that cloud service. The cloud provider behind it still carries its own requirements for CUI. Ask the managed provider which cloud platform hosts the data, who holds the administrative credentials, and whether the cloud vendor's authorization covers the service the contractor is buying.
Centralized SOC or NOC across business units
A security operations center that serves several business units can sit inside one corporate structure and still be external to a given contractor. The rule uses this centralized model as an example. Map which units the SOC monitors, whether it receives logs that include CUI-bearing systems, and whether it can change configurations there. A non-cloud ESP may also request a voluntary C3PAO assessment, which can reduce the effort of each customer assessment.
Scoping decisions to document
Whatever role a provider plays, the decision must be written down and tied to evidence. Record what the provider does, what it can access, which assets hold CUI or security protection data, and who signed off on the scope. Ask your provider for a written description of its services and its data flows before contract signature, and keep that record with your system security plan so an assessor can trace each conclusion back to the contract and the environment.
Why security protection data pulls an MSSP into scope
For a managed security service provider, the trigger that brings it into CMMC scope is often not the CUI itself. Under the definition in 32 CFR 170.4, security protection data such as log, configuration and alert data counts as a reason to treat a provider as an External Service Provider (ESP) when that data is processed, stored or transmitted on the provider's assets. An MSSP that never opens a customer's CUI file can still be in scope the moment its monitoring platform collects the customer's authentication logs, firewall configurations or endpoint alerts and keeps them in its own environment. The practical first step is an asset-by-asset inventory of where each customer's security protection data lands: collectors, SIEM indexes, ticketing systems, backup targets and analyst workstations.
The concern many MSPs raise is that their tools will themselves be treated as security protection assets and need to be assessed as such. The CMMC final rule addresses this directly: DoD says it cannot comment on specific products, that a wide range of technologies may be used to implement CMMC requirements, and that it will not publish a list of approved tools. So the question for an MSSP is not whether a particular SIEM or log platform is acceptable, but how its chosen stack implements the controls the customer depends on, such as audit logging, access control and encryption, and whether the provider can show that implementation with evidence. Where a tool choice affects scope or the customer's assessment, confirm the answer with the customer and their assessor, not with the tool vendor, because only the assessor's reading of the customer's environment is decisive.
Customer-scoped assessment or voluntary certification: which path fits
This table compares three ways an external service provider can show its security to defense contractor customers: being assessed only inside each customer's assessment, requesting a voluntary C3PAO certification, or relying on a cloud provider's FedRAMP route. Read each row to see who pays, how often the work repeats, what the customer's contract requires, and which provider profile each path suits.
| Path | Who pays and how often work repeats | Best fit and what to confirm |
|---|---|---|
| Customer-scoped assessment only | Each customer's assessment examines the provider's responsible controls, so the provider supports that work for every customer. The cost of preparation repeats with each assessment cycle, and the provider often carries it through its services agreements. | Fits a provider with few customers that can absorb repeated evidence requests. Confirm with each customer which minimum assessment type its contract requires and whether that customer accepts assessment-only evidence. |
| Voluntary C3PAO certification under 32 CFR 170.19(c)(2)(ii) | The provider pays the assessor directly for one certification assessment, and assessors may treat requirements it is responsible for as validated during customer assessments. Work repeats only at the certification cycle, not per customer, though personnel must still take part. | Fits a provider with many customers that all send repeated assessment requests. Confirm the minimum assessment type in each customer's contract, because certification helps only where the contract allows it to reduce effort. |
| Cloud provider FedRAMP route under DFARS 252.204-7012 | Applies when the provider is a cloud service provider handling CUI, which must meet FedRAMP requirements. The cloud provider carries authorization effort and cost, and customers rely on that authorization rather than repeating a full review of the cloud service. | Relevant only if the provider runs a cloud service that handles CUI, not for a non-cloud managed service. Confirm the FedRAMP status with each customer and whether the service is scoped as an ESP that manages a third-party cloud. |
How a voluntary ESP certificate can shorten each customer's assessment
A non-cloud external service provider can reduce the work its customers face by undergoing a CMMC certification assessment on its own initiative. Under 32 CFR 170.19(c)(2)(ii), an ESP may voluntarily undergo that assessment to reduce its effort during customers' assessments, and the minimum assessment type for that ESP is set by each customer's contract requirement. Under the CAP v2.0 guidance, when a non-cloud ESP holds a valid Level 2 Certificate of CMMC Status, assessors may treat the requirements it is responsible for as validated. The benefit is real only if the ESP's people still take part in each customer assessment and the inherited requirements are still shown to be maintained, so the certificate narrows the questions rather than removing them.
The certificate does not replace each customer's own scoping. Every contractor still decides which systems hold CUI or security protection data, which services touch that scope, and which ESPs are in it. The customer also still owns its controls and remains accountable for every user with access to CUI through the service. Before relying on an ESP's certificate, the MSP should confirm with each customer which assessment type that customer's contract requires, since a certificate that satisfies one customer's minimum may fall short of another's. The customer's responsibility matrix must be current and cover every in-scope requirement the MSP performs wholly, partly or jointly, and an assessor will check this against the MSP's actual operations.
For an MSP planning this, the practical step is to map which of its services and personnel fall within each customer's scope, then decide whether a voluntary certification assessment is worth its cost for the customers it serves. Ask the Certified Third-Party Assessment Organization (C3PAO) for a written scope that names the services, personnel, facilities and tools covered, and confirm that the scope matches the responsibility matrix you give customers. Keep evidence of the certificate's maintenance and of your staff's participation ready for each customer assessment. Confirm the current status of the Level 2 requirements and assessment types with the Department of War, since the program's phases are under review.
How the customer responsibility matrix gets built and kept current
A customer responsibility matrix records which CMMC requirements the MSP performs, which the customer performs, and which both share, so that each assessor can trace every in-scope requirement to a named party and current evidence. The sequence below builds that record from the customer's scope outward and keeps it accurate as services change.
Confirm each customer's CUI scope
Start with the customer's own assessment boundary. Work with the customer to identify which systems store, process or transmit CUI and which of them the MSP supports. Then identify which MSP assets touch CUI or security protection data, such as log collectors, remote management consoles, backup repositories and configuration stores, because only those assets make the MSP an external service provider for that customer under 32 CFR 170.4. Output: a scoping note per customer that lists in-scope MSP assets and the customer systems they support, signed off by the customer's security owner.
List every in-scope requirement the MSP touches
For each in-scope asset, list every CMMC Level 2 requirement the MSP performs wholly, partly or jointly. Requirements are identified by their IDs in the form DD.L2-REQ, such as AC.L2-3.1.1, and the list should cover domains such as audit and accountability, configuration management, incident response and system and information integrity, where managed services commonly sit. Mark each row as wholly, partly or jointly performed. Output: a draft matrix with one row per in-scope requirement and a performance type for each row, reviewed by the MSP's security lead against the requirement wording in the CMMC Model.
Name every party with security responsibilities
Record every party that holds a security responsibility for each row, including the customer, the MSP, any subcontractor or cloud provider the MSP relies on, and any internal function at the customer such as an identity team or facilities group. CAP v2.0 expects the matrix to name all such parties, so a row that depends on a sub-provider must say so. Output: a party register that gives each name, role and contact point, and that links each party to the rows it covers.
Agree the split with each customer in writing
Walk through each row with the customer and record who does what for that requirement. Agreement should be in writing and should state the division for shared requirements, since a partly performed requirement can leave gaps if both parties assume the other is covering it. Ask the customer to confirm which rows they will evidence themselves. Output: a signed or accepted matrix version that both parties have reviewed, with dates of agreement recorded in the document history.
Collect final evidence for each row
For every row, gather the evidence that shows the responsible party performs the requirement. Assessors look for final-form records, not drafts, because a requirement is met only when its assessment objectives are satisfied with evidence in final form under 32 CFR 170.24(b). Typical items include ticketing records, monitoring configurations, backup test results, access review exports and change approvals, with each item named and stored where the assessor can reach it. Output: an evidence index keyed to requirement IDs, with each item marked as final and linked to its owner.
Check the matrix against the CAP v2.0 test
Before the matrix goes to a customer or an assessor, check it against the points CAP v2.0 says assessors verify: it is current, it names all parties with security responsibilities, and it covers every in-scope requirement the ESP performs wholly, partly or jointly. Any gap found here should be closed by updating the row, the party register or the evidence index. Output: a completed check record that shows each point was tested and which rows were corrected.
Review the matrix on a set cycle and after changes
Set a review cycle with each customer in the agreement and hold a review whenever the MSP changes a tool, a sub-provider, a monitoring scope or a service that touches CUI or security protection data. Each review re-runs the scoping, row and party checks and refreshes the evidence index. Confirm the review interval with the customer, since no fixed period is set by the supplied CMMC rule text. Output: a dated revision of the matrix with a change log that records what changed, who approved it and which evidence was refreshed.
Who owns which part: the MSP, its customers, DeployOpen and the assessor
The managed service or managed security provider owns the services it runs, the staff who run them and the evidence for every requirement it performs. Under the CMMC final rule, a non-cloud provider that handles CUI or security protection data is an external service provider, and it is treated as an extension of the customer's environment. That means its personnel, change records, monitoring output and backup procedures must hold up when an assessor asks for them.
- Service-level responsibility: Document which requirements the MSP performs wholly, partly or jointly, and keep that list current.
- Staff accountability: Maintain identity records and access reviews for every MSP user who can reach customer CUI or security protection data.
- Operational evidence: Keep logs, tickets, patch records and monitoring reports in final form, not drafts.
- Voluntary certification: A non-cloud ESP may request a C3PAO assessment to reduce its effort during customer assessments. Confirm the minimum assessment type in each customer contract.
- Tool decisions: The MSP selects its own tools. DoD will not publish an approved product list, so the MSP must show how each tool meets the requirements it implements.
Check that the MSP's responsibility matrix names every party with security duties and matches what the MSP actually does.
The defense contractor owns its CUI environment, its scoping decisions and its affirmations. It decides which systems hold CUI, which providers touch those systems, and whether a provider is an ESP at all. The contractor also signs the affirmation and remains accountable for the security of its contract information, whether or not a provider performs some of the work.
- Scoping decisions: Determine which MSP services fall inside the CUI boundary and which are staff augmentation, where the contractor supplies all processes, technology and facilities.
- Contract flowdown: Set the minimum assessment type the MSP must hold and write the reporting duties into the service agreement.
- Responsibility matrix: Require a current matrix from each provider that covers every in-scope requirement the provider performs.
- Affirmations and records: The Affirming Official signs for the contractor, and the contractor must keep its own System Security Plan and Plan of Action and Milestones current.
- Oversight: Review provider evidence, access lists and incident notifications on a regular schedule.
Confirm with your contracting officer and counsel how DFARS 252.204-7012 applies to each provider before you finalize the matrix.
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For an MSP, that work may include building the controls the MSP delivers, drafting the responsibility matrix, and assembling the evidence an assessor will request. DeployOpen prepares systems and evidence within a written scope. It does not issue assessment reports, attestations or certificates, and it does not decide whether a requirement is MET.
- Scoped preparation: Agree in writing which requirement families, systems and documents are in scope before work starts.
- Control build and documentation: Configure logging, access, configuration baselines and backups so the MSP can show evidence in final form.
- Evidence packaging: Organize artifacts by requirement ID so the MSP and its assessor can trace each one.
- Testing support: Run security testing that feeds the MSP's risk assessments and vulnerability remediation records.
- Independence boundary: DeployOpen should not act as the assessor, certify the MSP, or write the findings the MSP's assessor will test.
Ask for the written scope, the deliverables list and who signs each document before engaging anyone.
A Level 2 certification assessment is performed by a C3PAO authorized or accredited by The Cyber AB. A Level 3 certification assessment is performed by DCMA DIBCAC. The assessor tests each requirement against the NIST SP 800-171A objectives, and it issues findings and any certificate on its own authority. For a non-cloud ESP that holds a valid Level 2 certificate, the assessor may treat requirements the ESP is responsible for as validated, provided ESP personnel take part and the inherited requirements are still shown to be maintained.
- Independent findings: The assessor decides MET or NOT MET for each objective based on evidence in final form.
- Inheritance rules: A valid ESP certificate can reduce testing on the provider's requirements, but it does not remove the customer's own obligations.
- Matrix review: The assessor checks that the responsibility matrix is current and complete for the provider's requirements.
- Consultant limits: Consultants may prepare evidence, but the assessor may not be the same party that prepared the environment it tests.
- Scope confirmation: Ask the assessor early to confirm which provider services fall inside the assessed boundary.
Verify the assessor's authorization status with The Cyber AB before you sign an assessment agreement.
What delays MSP CMMC projects and how to avoid each delay
Most delays in an MSP's CMMC work start with scope: which customers, which systems and which tools are inside the boundary. The cards below cover the decisions that stall projects most often and one action to take on each before the assessment team arrives. Each fix is something the provider can start this week with its existing customer contracts and service records.
Unclear scope across several customers
An MSP that serves many defense contractors often has one shared SOC or NOC and no written record of which customer data reaches it. Under the CMMC rule, a provider counts as an ESP only if CUI or security protection data such as logs and configuration data is processed, stored or transmitted on its assets, so the answer differs by customer. Map each customer's data flows to the provider's platforms, log sources and staff access before scoping anything. Confirm the result with each customer in writing.
Responsibility matrix left out of date
The customer responsibility matrix is the document assessors use to see which requirements the provider performs, shares or leaves to the customer. A matrix written before a platform change, a new monitoring service or a staffing shift will be wrong, and assessors check that it is current and names every party with security responsibilities. Set a review trigger in your change process so any service change updates the matrix before it goes live. Keep a dated revision history for each customer.
Evidence kept in draft form
A requirement counts as MET only when all applicable assessment objectives are satisfied with evidence in final form, not drafts. MSPs often produce runbooks, alert review records and access reviews as working documents that are never approved or signed off, so the evidence exists but does not count. Assign an owner and an approval step to each evidence type, and store the approved version with its date. Ask each customer which evidence formats its assessor will accept.
Tools assumed to be out of scope
Many MSPs assume their monitoring, ticketing or remote management tools fall outside the boundary, or assume the opposite and pay to re-platform them. DoD has said it will not comment on specific products and will not publish a list of approved tools, so the answer depends on what each tool stores or transmits for each customer. Inventory every tool that touches customer data, record what it holds, and ask each customer to confirm its treatment in writing before the assessment.
Staff augmentation confused with technical support
The CMMC rule treats staff augmentation as an ESP that needs no CMMC assessment when the contractor provides all processes, technology and facilities. A provider that runs technical support on its own platforms is an MSP and is assessed against the requirements it performs. Teams that sell both services often apply the lighter treatment to work that is actually managed service delivery. Document, per engagement, who owns the process, the technology and the facility, and classify each contract accordingly.
Voluntary certificate treated as a substitute
A non-cloud ESP may voluntarily request a C3PAO assessment, and a valid Level 2 certificate lets assessors treat the requirements it is responsible for as validated. That does not replace each customer's own assessment, because the provider's personnel must still take part and the inherited requirements must still be shown to be maintained. Plan the certificate as a way to reduce effort in each customer assessment, and confirm with each customer what minimum assessment type its contract requires.
Questions MSPs and MSSPs ask before they hire help
Is every managed service provider an external service provider under CMMC?
No. Under 32 CFR 170.4, a provider counts as an external service provider (ESP) only when CUI or security protection data, such as log and configuration data, is processed, stored or transmitted on its assets. A provider that supplies staff only, with the contractor providing all processes, technology and facilities, needs no CMMC assessment. A non-cloud ESP that provides technical support is an MSP, and it is treated as an extension of the contractor's environment, so it is assessed against the applicable requirements and is accountable for every user with access to CUI through its service. A centralized SOC or NOC inside the same corporate group can still be external to the contractor. The first step is therefore an inventory of which customer data reaches the provider's systems. Read 32 CFR 170.4
Does an MSP have to get CMMC certified?
It depends on the customer's contract and the current phase status, so get the requirement in writing before you commit. On 13 July 2026 the Department of War suspended CMMC Phase II, which would have required Level 2 C3PAO certification for applicable contracts. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. The DoW CIO's About CMMC page says that, as of 17 October 2026, implementation is paused in Phase 1 and may only require self-assessments at Levels 1 and 2, while the eCFR text still contains the original schedule. A non-cloud ESP may also voluntarily request a certification assessment, and 32 CFR 170.19(c)(2)(ii) says this can reduce effort during customers' assessments. Check the current status on the DoW CIO site
What drives the effort of CMMC work for an MSP?
The effort follows the scope each customer creates. The main drivers are the number of customers whose CUI or security protection data reaches the provider, the services delivered to each one, and the assets that touch that data, such as SIEM, remote monitoring, ticketing, backup and identity systems. The number of administrators with access to customer CUI and whether the provider runs cloud or non-cloud infrastructure also matter. One-time work includes building the responsibility matrix, designing evidence, and remediating gaps. Recurring work includes keeping the matrix current, collecting final-form records and supporting each customer's assessment. Ask any provider for a quote that breaks the work down by customer, service and asset class, and that states which items are one-time and which recur.
Can an MSP prepare its own CMMC evidence and responsibility matrix?
Yes, an MSP can prepare its own evidence, provided the matrix and records meet assessor expectations. CAP v2.0 requires assessors to confirm that an ESP's customer responsibility matrix is current, names all parties with security responsibilities, and covers every in-scope requirement the ESP performs wholly, partly or jointly. Each requirement is MET only when all applicable assessment objectives in NIST SP 800-171A are satisfied with evidence in final form, so drafts, unsigned procedures and undated screenshots do not count. Build the matrix from the customer's requirements, assign an owner to each row, and set a review cadence. Organizations with limited internal capacity often ask an outside party to review the matrix before the assessor sees it.
What does CMMC require from an MSP's own staff?
Staff must take part in the assessment whenever requirements the provider is responsible for are examined. CAP v2.0 says that even when an ESP holds a valid Level 2 or Level 3 Certificate of CMMC Status, its personnel must still participate and the inherited requirements must still be shown to be maintained. In practice, named system owners need to explain how each tool is configured, administrators need to produce audit logs, change records and baselines on request, and the provider needs training records and screening evidence for staff who handle customer systems. Plan for interview time, a single point of contact and someone who can retrieve records quickly. Staff who only read documentation without operating the controls will struggle to answer follow-up questions.
Will the security tools in an MSP's stack be treated as security protection assets?
The tool itself does not decide the answer. The CMMC final rule says DoD cannot comment on specific products, that a wide range of technologies may be used to implement CMMC requirements, and that it will not publish a list of approved tools. What matters is whether a tool stores, processes or transmits CUI or security protection data, and which controls it supports. Map each tool to the requirements it helps meet, record where its data resides, and confirm its administrative access model with the customer's assessor before deployment. Open-source platforms can meet many of these needs when they are self-hosted inside the customer's or provider's controlled infrastructure, but each deployment still needs its own evidence and configuration records.
What can an implementation partner do for an MSP's CMMC work, and what can't it do?
An implementation partner can plan the scope, configure and harden self-hosted platforms, document systems, prepare the responsibility matrix and evidence, run security testing and provide training. DeployOpen works this way inside a client's own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. It cannot make the provider compliant on its behalf, and it cannot issue assessment reports or certificates. Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB. The organization owns its controls and its decisions. DeployOpen does not publish a price list, so ask for a quote that follows from the written scope.
How DeployOpen scopes MSP services and prepares evidence for customer assessments
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the evidence a customer assessment needs is produced by systems you run and control. We prepare systems, controls and evidence for assessment, while the organization owns its controls and only an independent C3PAO issues a certificate.
How we scope
- We agree a written scope that names each customer environment, service and tool your MSP operates for them.
- The scope separates services that process CUI or security protection data from services that only provide staff augmentation.
- We identify which requirements you perform wholly, partly or jointly, so the customer responsibility matrix can be drafted from that list.
How we build
- We deploy and harden logging, identity, configuration management and monitoring platforms inside your environment or the customer's chosen environment.
- We configure tenant separation so each customer's CUI and security protection data stays within its own defined boundary.
- We test the controls you own against the NIST SP 800-171A assessment objectives before any assessor sees them.
How we hand over
- We deliver a current customer responsibility matrix that names every party with security responsibilities and covers each in-scope requirement you perform.
- We document system security plans, configuration baselines and runbooks in a form your staff can maintain after handover.
- We export evidence in final form, with dated records of who did what, so customer assessors can trace each requirement to its proof.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope engagement ends.
- We keep the matrix and evidence current as customers, tools and services change, which assessors check on every review.
- Where you pursue voluntary C3PAO certification as an ESP, we help you prepare, while the assessor remains independent of DeployOpen.

