Do cloud and SaaS providers need CMMC for defense contractors?
A defense contractor that puts CUI in a cloud or SaaS product will ask you for CMMC evidence, and the honest answer starts with FedRAMP. Under DFARS 252.204-7012, an external cloud service provider that stores, processes or transmits covered defense information must meet security requirements equivalent to the FedRAMP Moderate baseline, along with the clause's incident reporting and forensic support duties. CMMC does not certify the cloud service itself, so there is no CMMC certificate to hand over for a platform. What you owe the customer is proof of FedRAMP Moderate authorization or a documented equivalency, checked against the exact offering the customer uses.
The answer changes with what your service does with the data. A cloud service provider that handles CUI must meet the FedRAMP requirements. A cloud or non-cloud provider that handles only security protection data is assessed as a security protection asset. A non-cloud external service provider that handles CUI is treated as an extension of the contractor's own environment, assessed against all applicable requirements, and accountable for every user who reaches CUI through its service. Confirm which of these three roles you hold before you answer a customer, because the wrong label changes what gets assessed and what gets promised.
Even when your platform is authorized, the contractor keeps ownership of its overall assessment. The customer's scope, system security plan and responsibility matrix must show which controls your service inherits, which the customer runs, and which are shared. Ask your customer's compliance lead for the external service provider wording they plan to use, and check that your authorization covers the specific offering named in their documentation. If you run the service for a Department of War customer, separate cloud computing rules in DFARS 252.239-7010 may also apply, so confirm those requirements in the contract before you commit.
How the ESP scoping table sorts cloud and non-cloud providers
The table compares the three external service provider categories in 32 CFR 170.19(c)(2) by what data the provider handles and whether it is a cloud service. Read each row by first identifying which data the service touches, then find the assessment route and the evidence your customer will ask you to show.
| Provider type | Data handled | How it is assessed | What the SaaS vendor must show |
|---|---|---|---|
| Cloud service provider handling CUI | Covered defense information stored, processed or transmitted | Must meet FedRAMP requirements in DFARS 252.204-7012, verified by the assessor against the FedRAMP Marketplace | FedRAMP Moderate authorization or equivalency for the exact offering named in the SSP, plus incident reporting and forensic support |
| Cloud or non-cloud provider handling only security protection data | Logs, alerts and other security protection data, not CUI | Assessed as a security protection asset within the contractor's CMMC scope | Documented role in protecting the contractor's systems, and evidence that its own administration is controlled |
| Non-cloud ESP handling CUI | CUI delivered through a hosted or managed service that is not cloud | Treated as an extension of the contractor's environment and assessed against all applicable Level 2 requirements | Evidence for every user with access to CUI through the service, mapped to the contractor's own control assessment |
| Cloud provider used only for non-CUI business data | Data that is not CUI and not security protection data | Outside CMMC assessment scope for the cloud service itself, subject to contract terms | Written confirmation of the data classification boundary, so the contractor can show CUI never reaches the service |
| Cloud platform under a DoD-run cloud | Government data hosted for DoD use | Governed by DFARS 252.239-7010 and the DoD Cloud Computing Security Requirements Guide, not the ESP table alone | Confirmation of the required impact level and that Government data not on DoD premises stays in the United States unless the contracting officer approves otherwise |
How assessors verify FedRAMP Moderate or equivalency
When a cloud service provider handles CUI, the default path is a FedRAMP Moderate authorization. The assessor does not accept a vendor's statement that the service is compliant. They look up the offering on the FedRAMP Marketplace and compare what they find with what the contractor's system security plan names. The check is specific: the provider, the service offering, the impact level and the authorization status must all line up with the environment that stores, processes or transmits CUI.
- Provider and offering: The assessor confirms the listed cloud provider and the exact service offering, not a parent brand or a different product line from the same company.
- Impact level and status: The listing must show a Moderate impact level and an active authorization status at the time of assessment.
- SSP alignment: The offering named in the contractor's SSP must be the one listed. A mismatch in region, boundary or product name is a finding even when the vendor holds a valid authorization elsewhere.
- Shared responsibility: The assessor checks which controls the provider inherits and which the contractor still implements, using the documented responsibility matrix.
- Evidence currency: The authorization record and the contractor's copy of the provider's package should be current, since the assessor will ask how the contractor tracks changes.
Before an assessment, ask your provider to confirm in writing the exact listing name, impact level and status, and where the SSP cites it.
Some providers claim a FedRAMP Moderate equivalent rather than an authorization. The equivalency path under DFARS 252.204-7012 is narrower than many vendors assume. Assessors under CAP v2.0 do not judge the offering against the FedRAMP Moderate baseline themselves. They confirm that the body of evidence supporting the claim is complete, intact and produced within the required periodicity under the DoD CIO equivalency policy in force at the time.
- Completeness: The assessor checks that every artifact the current equivalency policy requires is present, not only the security assessment summary.
- Integrity: The evidence must be unaltered and traceable to the assessed offering, so version history and signatures matter.
- Periodicity: Assessments, scans and reviews must fall within the intervals the policy sets. An expired artifact can defeat an otherwise sound package.
- Scope match: The evidence must cover the offering and environment that holds CUI for this contractor.
- Policy version: The assessor applies the policy current at assessment, so providers should be asked which version their package was built against.
The vendor should confirm the current equivalency policy with the DoD CIO before relying on this path, because the requirements and artifact list can change.
Assessors verify documentation and listings. They do not audit the cloud provider's data center, and they do not re-run the FedRAMP baseline. This boundary shapes what the contractor must prepare. The contractor owns the proof that the provider was checked, and the assessor tests whether that proof is accurate, current and tied to the in-scope environment.
- Verification records: Keep dated screenshots or exports from the FedRAMP Marketplace or the provider's evidence package, with the reviewer's name.
- Contractual flowdown: Confirm that the provider agrees to the incident reporting and forensic support terms in DFARS 252.204-7012.
- Change tracking: Record when the provider's authorization or equivalency package is renewed, changed or withdrawn.
- Gaps: Document any controls the provider does not inherit and show how the contractor covers them.
- Independence: An implementation partner can assemble these records, but only the independent assessor concludes whether the evidence meets the requirement.
Ask your assessor which records they expect for the provider before the assessment begins.
Preparation is where most cloud gaps appear. Teams often hold the right provider documents but cannot show how those documents map to their own SSP. The goal is a single traceable package that answers the assessor's first questions without follow-up. This work is preparation, not certification, and the contractor remains accountable for the result.
- Mapping sheet: List each cloud-hosted requirement, the provider control that inherits it and the contractor's own control where the provider does not.
- Authorization record: Store the verification proof alongside the SSP and update it when the listing or package changes.
- Boundary diagram: Show exactly which accounts, regions and services hold CUI so the offering match is obvious.
- Data location: Document where Government data resides, since DFARS 252.239-7010 applies to cloud services used to provide IT services under a contract.
- Recurring checks: Assign an owner to recheck the listing or equivalency artifacts on a fixed schedule.
Confirm with your assessor whether they want the mapping sheet in a particular format.
Clouds run for DoD: the separate rules under DFARS 252.239-7010
DFARS 252.239-7010 is a separate obligation from CMMC scoping. It applies when a cloud service is used to provide IT services in performance of a contract, so a provider can owe DoD security requirements under this clause even when its service would not be assessed under CMMC at all. The clause requires the contractor to meet the DoD Cloud Computing Security Requirements Guide for the security level the contract requires, and it requires that Government data not residing on DoD premises stay within the United States or its outlying areas unless the contracting officer approves another location. The clause text is at DFARS 252.239-7010 on eCFR.
The practical question for a SaaS or cloud provider is which clause a given contract carries. Read the solicitation and award for 252.239-7010, for 252.204-7012 (which carries the FedRAMP Moderate equivalency requirement for cloud providers storing covered defense information), or for both. Ask the contracting officer or prime which impact level applies, and whether any data location exception has already been approved. Record the answer in the contract file, because the CMMC scoping table and the cloud clause answer different questions and a provider can be in scope for one and not the other.
Keep the two evidence trails separate. The Cloud Computing Security Requirements Guide and the data location terms are assessed against the contract, not against a CMMC assessment of your customer's environment. Confirm with your prime or contracting officer which document set they expect, which authorization or provisional authorization your service must hold for the required level, and who signs off on any Government data stored outside the United States or outlying areas. Re-check these terms whenever the contract is modified, renewed or moved to a new hosting region.
What drives the cost and effort of cloud provider evidence
For a cloud or SaaS provider, the evidence burden follows a few decisions made early: which services touch CUI, how the offering is authorized, and how far customers can rely on the provider's documentation. Each driver below changes who does the work and how often that work recurs.
Number of CUI-handling services
Every service that stores, processes or transmits CUI enters the assessed boundary, so a platform with twenty services in scope carries far more evidence than one with three. Before any quote, inventory each service and mark whether it touches CUI, handles only security protection data, or sits outside the boundary. Ask the implementation partner to show how that inventory maps to the system security plan, because each added service adds controls, log sources and review cycles that recur every year.
FedRAMP Moderate authorization or equivalency
An offering with a FedRAMP Moderate authorization listed on the marketplace gives assessors a direct check: provider, offering, impact level and status. An offering that relies on equivalency needs a complete body of evidence that the assessor can verify but not re-evaluate against FedRAMP Moderate, which usually means more documentation work up front. Confirm the exact offering name in the system security plan matches the listing, because a mismatch is the most common reason an authorization fails to support the claim.
Completeness of the evidence body
For equivalency, assessors check that the evidence is complete, intact and produced within the required periodicity. Gaps in continuous monitoring reports, scan results or change records are where effort concentrates, and they recur every cycle. Set a named owner and a calendar for each recurring artifact, and ask the implementation partner to produce a sample package the assessor could review without follow-up requests.
Incident reporting and forensic support
DFARS 252.204-7012 requires a cloud provider holding covered defense information to meet the clause's incident reporting and forensic support requirements, which means the provider must be able to preserve images, support the contractor's reporting and make data available on request. Staffing for on-call response, log retention and tested runbooks is a recurring cost. Ask what the provider commits to in writing about reporting timelines, forensic access and retention before signing.
Customer-facing responsibility matrices
A responsibility matrix states which controls the provider implements, which the customer implements and which are shared. Each defense customer will read it against its own system security plan, so vague entries create rework across every contract. Build the matrix from the control set in scope, review each row with the provider's engineers, and keep it under version control so updates are traceable when the platform changes.
Number of defense customers
Each defense customer may ask for its own evidence package, questionnaire answers and assurance calls, and those requests multiply the recurring work. A provider serving many prime contractors benefits from a single, standardized evidence set that every customer can reuse. Ask any partner how they will package evidence once and reuse it, and what a per-customer request costs in staff time, so the quote reflects the work that will actually recur.
How a SaaS vendor gets ready for a defense customer's review
The sequence below lets a cloud or SaaS provider give its defense customer the scoping answer, authorization evidence and shared responsibility records that the customer's assessment needs. The contractor and the assessor decide the outcome; the provider prepares the inputs.
Confirm data types and CUI flows
Start by listing every data type the service will hold, process or transmit for the defense customer, and map where CUI enters, moves through and leaves the service, including backups, logs, support tickets and administrator access. Mark which flows carry CUI, which carry only security protection data, and which carry neither. The output is a data flow diagram and a short data inventory signed off by the provider's engineering and compliance leads, which the customer can compare against its own CUI boundary.
Determine ESP classification from the scoping table
Using the ESP scoping table in 32 CFR 170.19, classify the service as a cloud service provider handling CUI, a cloud or non-cloud provider handling only security protection data, or a non-cloud external service provider handling CUI. The classification decides which rule applies: FedRAMP requirements for cloud providers with CUI, security protection asset treatment for security protection data, and assessment as part of the contractor's environment for non-cloud providers. Record the chosen row and the reasoning, then ask the defense customer to confirm it, since the contractor owns the scoping decision.
Verify authorization or equivalency status
For a cloud service provider handling CUI, confirm a FedRAMP Moderate authorization on the FedRAMP Marketplace for the exact provider, service offering, impact level and status named in the system security plan. If the offering relies on FedRAMP Moderate equivalency instead, gather the equivalency package and confirm it is complete, intact and within required periodicity under the DoD CIO equivalency policy in effect. Note the date of each check. Where the offering or status does not match, correct the SSP language before the customer's assessor sees it.
Confirm the offering named in the SSP
Compare the service name, the authorized boundary and the hosting regions in the provider's system security plan against the marketplace listing or the equivalency record. The assessor checks that the specific offering is listed, so a parent platform name or a different region can fail the check even when the broader platform is authorized. The output is a one-page reconciliation showing each matching field and any gap, with a named owner for each gap.
Document the shared responsibility matrix
Write a responsibility matrix that assigns each applicable requirement to the provider, the defense customer or both, citing the controls the provider operates inside its authorized boundary. For a non-cloud external service provider handling CUI, state plainly that the provider is accountable for every user with access to CUI through the service. Have legal or contracts review that the matrix matches the customer agreement and the DFARS 252.204-7012 obligations for incident reporting and forensic support, so no requirement is left without an owner.
Check cloud location and incident reporting terms
Where the service is an external cloud provider for a DoD workload, confirm the DFARS 252.239-7010 terms: the required DoD Cloud Computing Security Requirements Guide level, and whether Government data stays within the United States or outlying areas unless the contracting officer approves another location. Confirm the incident reporting and forensic support commitments in DFARS 252.204-7012 are written into the service agreement, with named contacts and the evidence the provider will hand over after an incident.
Gather evidence in final form for the assessment
Collect the artifacts the contractor's assessor will test against the NIST SP 800-171A objectives: the authorization letter or equivalency package, the SSP extract, the responsibility matrix, configuration baselines, access reviews, audit log samples, encryption settings and recent vulnerability scan results. Only final versions go into the package, not drafts, because a requirement is met only when its evidence is in final form. The output is an evidence index mapped to requirement IDs, and the provider then hands it to the contractor, who decides the outcome of the assessment.
Who owns what: the SaaS vendor, the contractor, and the assessor
A cloud or SaaS provider that stores, processes or transmits CUI owns the authorization question. Under DFARS 252.204-7012, an external cloud service provider that handles covered defense information must meet security requirements equivalent to the FedRAMP Moderate baseline and the clause's incident reporting and forensic support requirements. The vendor's own controls, its authorization package and its incident response obligations are the vendor's to build, document and maintain. A vendor does not receive a CMMC certificate for its platform, because CMMC assesses the defense contractor's own capabilities.
- FedRAMP status: Hold a FedRAMP Moderate authorization for the specific offering, or be ready to show equivalency under current DoD CIO policy.
- Incident reporting: Support the customer's reporting and forensic obligations under the clause within the timeframes in the contract.
- Documentation: Maintain a current system security plan and evidence package for the offering that the customer's assessor can read.
- Continuous monitoring: Run the monitoring and vulnerability management that the authorization requires, and report on it.
- Customer responsibility matrix: Publish a clear statement of which controls the vendor operates and which the customer must operate.
Before signing, confirm which exact offering is authorized, its impact level and status, and whether the customer's environment is inside that boundary.
The defense contractor remains accountable for CUI wherever it lives. If a non-cloud external service provider handles CUI, that provider is treated as an extension of the contractor's environment and is assessed against all applicable requirements. For a cloud provider, the contractor must confirm the provider meets the FedRAMP requirements and must assess its own use of the service. The contractor cannot transfer its obligation to a vendor by signing a contract.
- Scoping: Identify every cloud service that stores, processes or transmits CUI, and classify each under the scoping rules.
- Customer responsibilities: Implement the controls the vendor's responsibility matrix assigns to the contractor, such as user access, configuration of tenant settings and audit review.
- Verification: Check the FedRAMP Marketplace entry for the provider, service offering, impact level and status, and confirm the offering named in the system security plan is listed.
- Evidence: Keep the vendor's authorization artifacts, contract terms and your own configuration records in final form.
- Assessment readiness: Prepare your own system security plan and assessment evidence so the scope boundary is clear to the assessor.
Ask your vendor for its responsibility matrix and authorization details before you describe the service in your SSP.
An implementation partner such as DeployOpen works on the customer side of the boundary. Where a contractor runs self-hosted open-source platforms in its own cloud accounts, data centers or air-gapped networks, a partner can plan, configure, harden, back up and document those systems, and prepare the evidence that the contractor's assessment will examine. The partner does not own the contractor's controls, does not decide whether a requirement is MET, and does not issue any report, attestation or certificate.
- System preparation: Configure logging, access control, encryption and boundary settings to the contractor's documented requirements.
- Evidence preparation: Produce configuration baselines, change records and log exports that the contractor can review and present.
- Documentation support: Help draft system security plan sections for systems the partner built, to be reviewed and owned by the contractor.
- Testing: Run security testing that the contractor commissions, and report findings for the contractor to remediate.
- Scope limits: Work is set out in a written, fixed scope with agreed deliverables before work starts.
Confirm in writing which deliverables are the partner's and which remain the contractor's, and that the partner will not represent itself as an assessor.
Only an independent body issues the result. For CMMC Level 2 certification assessments, that is a C3PAO authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB. For a FedRAMP authorization, the authorizing body is the FedRAMP program and its authorizing officials, not the customer or a consultant. The assessor tests whether the requirements are met with final evidence, and for cloud offerings it verifies the authorization on the FedRAMP Marketplace or, for equivalency claims, checks that the evidence is complete, intact and current.
- Authorization check: Verify the FedRAMP Moderate entry by provider, offering, impact level and status.
- Equivalency check: Confirm the body of evidence is complete and within required periodicity, without re-evaluating the offering against the FedRAMP baseline.
- Testing: Assess each in-scope requirement against its assessment objectives, using evidence in final form.
- Independence: The assessor may not design or implement the controls it tests.
- Result: The assessor, not the contractor or partner, posts the outcome that the contractor relies on.
When selecting an assessor, ask how it handles cloud evidence and whether it has a conflict-of-interest policy covering your implementation partner.
Questions SaaS vendors ask about CMMC and FedRAMP
Does every SaaS offering a defense contractor uses need FedRAMP Moderate authorization?
Only when the service stores, processes or transmits CUI. For a cloud service provider handling CUI, the CMMC rule points to the FedRAMP requirements in DFARS 252.204-7012, and that clause requires an external cloud provider storing, processing or transmitting covered defense information to meet security requirements equivalent to the FedRAMP Moderate baseline. A cloud or non-cloud provider that handles only security protection data is assessed as a security protection asset instead. Confirm with your defense customer which of your services touch CUI, because that decision sets the scope of everything else. Document it in your data flow diagram so the customer's assessor can trace it.
Does CMMC certification apply to the cloud platform itself?
No. CMMC assesses the defense contractor's own capabilities, so there is no CMMC certification for a cloud platform. Microsoft and AWS both state this in their public guidance. A SaaS vendor that builds on a cloud platform must confirm the underlying platform holds at least FedRAMP Moderate authorization, and must show that the specific offering it uses is listed. Your own company's controls around that platform, such as access management, logging and configuration, remain in scope for the customer's assessment.
What changes when the service is hosted but not run on a cloud platform?
A non-cloud external service provider that handles CUI is treated as an extension of the contractor's environment. The rule says it is assessed against all applicable requirements, and the provider is accountable for every user with access to CUI through its service. This usually means your hosted environment appears inside the customer's assessment boundary, with your controls examined directly. Ask your customer early whether they expect you to be listed as an external service provider in their System Security Plan, since that determines how much of your environment the assessor reviews.
Is a hyperscale government region enough to meet the requirement?
It can be part of the answer, but it is not the whole answer. A hyperscale government region is useful only if the exact offering your service runs on is listed with the right provider, service model, impact level and status on the FedRAMP Marketplace. Assessors check that the specific offering named in the System Security Plan is listed. Running on a government region does not cover your application logic, identity setup, logging or administrator access, which still need evidence. Verify the listing yourself before your customer's assessor asks.
How long does the evidence work take for a SaaS vendor?
No researched duration is available for this work, so confirm it with an assessor and your implementation partner against your own environment. The effort depends on how many services touch CUI, how much of the stack you already document, whether your logging and access controls are centralized, and whether you claim FedRAMP Moderate authorization or equivalency. Evidence must be in final form, not drafts, so plan time for review and sign-off. Ask any partner to break the estimate into discovery, control implementation, evidence collection and assessment support.
What does the work need from our internal staff?
Your staff must own the decisions and the system knowledge. Expect to need people who understand your architecture, identity provider, deployment pipeline, logging, incident response and customer contracts. Engineering owns configuration evidence, security owns the policies and risk decisions, and legal or contracts owns the flowdown and incident reporting obligations. An implementation partner can prepare systems and evidence, but it cannot make those decisions for you or sign attestations. Name an accountable internal owner before work starts so that evidence reviews do not stall.
Can a consultant handle CMMC and FedRAMP scoping alone?
A consultant can prepare the work, but not complete it alone or issue the result. Independent assessors, such as a C3PAO for Level 2 certification assessments, or a FedRAMP-authorized third party assessment organization, verify the evidence and issue findings. Your organization must own its controls and operate them day to day. DeployOpen prepares systems, controls and evidence for compliance assessments under a fixed scope agreed in writing, and it does not issue audit reports, attestations or certifications. Ask any firm to state in writing which parts it performs and which parts an independent assessor performs.
What the current CMMC status means for cloud vendors now
The Department of War suspended CMMC Phase II on 13 July 2026, so the certification requirement that was scheduled to start on 10 November 2026 is not in force for now. That pause does not reduce what cloud and SaaS vendors owe defense customers. Phase I self-assessments, SPRS postings, annual affirmations by the Affirming Official and the obligations of DFARS 252.204-7012 all remain in place. Your customers still need the Department's required cyber protections for covered defense information in the systems you run for them, and their assessors will still ask how your service meets FedRAMP Moderate or an equivalent baseline.
The Department's CIO page states that implementation is paused in Phase 1 and may only require self-assessments at Levels 1 and 2. The eCFR text of 32 CFR 170.3(e) still carries the original four-phase schedule, so the two sources do not match. Do not plan around either one alone. Ask each defense customer's contracting officer which CMMC requirement applies to their contract, whether a Level 2 self-assessment or a certification is expected, and how the suspension affects any option periods or new awards. Record the answers in writing and file them with your contract documents, because a verbal assurance will not help you if a prime later asks.
Keep your FedRAMP authorization or equivalency evidence current whatever the schedule. Confirm that the offering named in each customer's system security plan is still listed on the FedRAMP Marketplace with the correct impact level and status, and that any equivalency package is complete, intact and inside its required periodicity. Assign one owner to track the reform task force's outcome and the Department's published updates, and review the schedule again each time one changes. Customers who do not yet know what they will be asked for will ask you first, so a current evidence file is the fastest answer you can give.
How DeployOpen prepares cloud and SaaS evidence
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the evidence for your side of the boundary is in place before an assessor arrives. We prepare systems, controls and evidence for assessment, while the organization owns its controls and an independent assessor issues any result.
How we scope
- Map which services, tenants and administrative paths handle CUI and which are security protection assets.
- Record the boundary between your platform and any FedRAMP Moderate or equivalent cloud provider in writing.
- Agree scope, deliverables and timelines in a fixed-scope written statement before work starts.
How we build
- Configure access control, audit logging, encryption and configuration baselines against the NIST SP 800-171 Rev. 2 requirements your scope needs.
- Deploy and harden open-source platforms inside your cloud accounts, data centers or air-gapped networks.
- Test controls and record results so each requirement has evidence in final form, not drafts.
How we hand over
- Document the system security plan, architecture diagrams, responsibility matrix and control evidence for your assessor.
- Provide a list of inherited controls to confirm with each cloud provider, such as the FedRAMP Marketplace listing for the named offering.
- Train your staff to run and maintain the evidence so it stays current between assessments.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Review evidence periodically and update documentation when platforms, tenants or contract clauses change.
- Confirm with your contracting officer and assessor which requirements apply before you commit to an assessment date.
