What CMMC 2.0 Level 2 Actually Requires From Software Vendors Running on a Hyperscaler Cloud

Key points:

• CMMC 2.0 Level 2 applies to any DoD contractor or subcontractor whose systems store, process, or transmit Controlled Unclassified Information (CUI). It requires all 110 security requirements of NIST SP 800-171 Revision 2, documented in a System Security Plan, assessed by an accredited C3PAO every three years for most contracts, with an annual affirmation filed in SPRS by a senior official.
• Certification is scoped to an information system boundary, not to a company. You can hold Level 2 status for one enclave while the rest of your estate runs normally. The assessor looks at the assets you put in scope: CUI Assets, Security Protection Assets, Contractor Risk Managed Assets and Specialized Assets.
• If CUI touches a cloud service, DFARS 252.204-7012 requires that service to be FedRAMP Moderate authorized or equivalent. The DoD CIO's December 2023 memo defines equivalency as 100% of the FedRAMP Moderate baseline, assessed by a FedRAMP-recognized 3PAO, with no open POA&M items from that assessment. Verify the exact service and region on the FedRAMP Marketplace.
• A FedRAMP-authorized region covers only the provider's share. Identity, MFA, key handling, audit log review, configuration baselines, vulnerability scanning and subcontractor flow-down stay with you, and that is most of what a C3PAO examines.
• Three things break a normal software pipeline: FIPS-validated cryptography, CUI leaking into CI/CD, previews, logs and support tools outside the boundary, and US persons access rules. The cheapest fix is architectural: shrink the enclave and run the same deployment workflow in both estates.

"Our cloud provider is FedRAMP authorized" is the most common answer software vendors give when a DoD prime asks if they are CMMC Level 2, and it covers a minority of what the assessor will actually test. The rest is your identity setup, your logs, your pipeline and your paperwork. The timing also matters: the DFARS rule that puts CMMC into contracts took effect on November 10, 2025, which means Phase 2, where DoD intends to require Level 2 (C3PAO) certification as a condition of award, starts on November 10, 2026.

I have spent years watching teams discover that the hard part of a regulated boundary is the engineering around it, not the cloud underneath it. This is the reference I wish CTOs had the day that first questionnaire lands. It is not legal advice: the authoritative sources are your contract clauses and the final rule at 32 CFR Part 170.

What is CMMC 2.0 Level 2, and which software vendors does it apply to?

CMMC 2.0 Level 2 is the DoD certification tier for any contractor or subcontractor whose information systems store, process, or transmit CUI, and its requirements are identical to the 110 requirements in NIST SP 800-171 Rev. 2. If your SaaS product ingests a DoD customer's CUI, the systems that handle it are in scope. Company size and contract value do not change that.

The trigger is the data type. A prime that hands you CUI must flow the requirement down: DFARS 252.204-7021(f) requires the clause in any subcontract that involves FCI or CUI and requires the prime to confirm your CMMC status before award, and 252.204-7012(m) flows down the safeguarding and incident-reporting rules. The related provisions 252.204-7019 and 7020 cover your NIST SP 800-171 assessment score in SPRS.

The regulatory timeline is now settled. The program rule at 32 CFR Part 170 was published on October 15, 2024 and took effect December 16, 2024. The acquisition rule that adds DFARS 252.204-7021 to contracts took effect November 10, 2025. 32 CFR 170.3(e) then phases requirements in yearly: Phase 1 (self-assessments), Phase 2 from November 10, 2026 (Level 2 C3PAO for applicable contracts), Phase 3 from November 10, 2027, and full implementation from November 10, 2028.

The correction I make most often: CMMC status attaches to an information system, not to your company. DFARS 252.204-7021 tracks status per "CMMC UID" for each information system that handles FCI or CUI. That is the single most useful fact in this article, because it means you can certify a small enclave instead of your whole company.

For a software vendor, CUI usually looks like technical drawings and specifications, export-controlled design data, logistics data, or personnel records the customer pushes into your product. The contract tells you what is CUI through its markings and CUI designation. When it is unclear, ask the contracting officer in writing. The National Archives CUI Registry lists the categories.

What does CMMC 2.0 Level 2 require in practice? The five deliverables

Level 2 comes down to five deliverables: all 110 NIST SP 800-171 Rev. 2 requirements implemented across 14 control families, a current System Security Plan describing the boundary, a POA&M limited to specific low-weighted requirements, a C3PAO assessment producing Conditional or Final status, and an annual affirmation in SPRS by a senior official.

The 14 families map onto everyday vendor work. A few examples:

• Access control: role separation between support, engineering and admin in your console.
• Audit and accountability: log retention plus a documented review cadence.
• Configuration management: immutable, versioned base images and a recorded baseline.
• Identification and authentication: MFA on every privileged path, including CI and break-glass accounts.
• Incident response: a runbook for the DIBNet report.
• Media protection, system and communications protection, system and information integrity: sanitized disks, encrypted CUI in transit and at rest, patching and malware detection.
• The other six families cover awareness training, maintenance, personnel security, physical protection, risk assessment and security assessment.

Scoring follows 32 CFR 170.24. You start at 110 and lose 5, 3 or 1 point for each requirement NOT MET, and the score can go negative. Evidence must be final: drafts and unapproved policies count as NOT MET.

32 CFR 170.21 sets the POA&M rules. Conditional status requires a score of at least 80% (88 of 110), and only 1-point requirements can sit on the POA&M. The one exception is SC.L2-3.13.11 when you use encryption that is not FIPS-validated. On top of that, six requirements can never sit on a POA&M: AC.L2-3.1.20 (external connections), AC.L2-3.1.22 (public information), CA.L2-3.12.4 (the System Security Plan), and the three physical access controls PE.L2-3.10.3, 3.10.4 and 3.10.5. You must close the POA&M with a C3PAO closeout assessment within 180 days, or the Conditional status expires.

Scoping decides how much of your estate the assessor touches. 32 CFR 170.19 defines the categories:

• CUI Assets are assessed against all 110 requirements.
• Security Protection Assets (your IdP, SIEM, bastion) are assessed against the requirements relevant to the function they provide.
• Contractor Risk Managed Assets can touch CUI but policy says they don't. They are reviewed through the SSP, with limited spot checks.
• Specialized Assets (IoT, OT, test equipment) are documented in the SSP and not tested against other requirements.
• Out-of-Scope Assets cannot handle CUI and are physically or logically separated, and you must be ready to justify that.

Incident reporting comes from DFARS 252.204-7012: report cyber incidents to DoD via DIBNet within 72 hours of discovery, using a DoD-approved medium assurance certificate, then preserve images and packet captures for at least 90 days after the report. Get the certificate before you need it.

The cadence is a C3PAO assessment every three years, plus an affirmation by your Affirming Official after each assessment, after a POA&M closeout, and annually (32 CFR 170.22).

Do you have to use AWS GovCloud or Azure Government, or can commercial cloud regions work?

No specific vendor is required, but under DFARS 252.204-7012(b)(2)(ii)(D) any cloud service that stores, processes, or transmits CUI must meet security requirements equivalent to the FedRAMP Moderate baseline, which in practice means FedRAMP Moderate (or higher) authorized or formally equivalent. Authorization attaches to a named service offering in specific regions, so the rule is per service and per region. Check marketplace.fedramp.gov, not a marketing page.

The DoD CIO's equivalency memo, signed December 21, 2023 and cleared for publication in January 2024, sets a high bar. The service must achieve 100% compliance with the FedRAMP Moderate baseline through a FedRAMP-recognized 3PAO, deliver a full body of evidence (SSP, assessment plan, assessment report, POA&M, continuous monitoring), and carry no POA&M items from that 3PAO assessment. The memo is explicit that "the onus is on the contractor" to validate that evidence and to provide the customer responsibility matrix to assessors. If the provider falls short, you carry the risk.

The final rule adds the practical consequence: a C3PAO can only give credit to a FedRAMP Moderate authorized or equivalent provider, and requirements that depend on any other provider are scored NOT MET.

Two overlays push vendors toward sovereign regions even when FedRAMP Moderate alone would do. Export-controlled data under ITAR or EAR typically needs US-only storage and US persons support, which commercial regions generally do not promise. Sovereign regions also change operations: some services and features arrive late, accounts or tenants are separate, pricing differs, and you cannot keep dependencies back into a commercial region.

Treat every row as a starting point. The FedRAMP Marketplace and DISA's DoD Cloud Service Catalog are the sources of truth for the exact service list.

Who is responsible for what under CMMC? Reading the shared responsibility model

A FedRAMP-authorized region satisfies the infrastructure share of the 110 requirements and nothing more: the C3PAO assesses what you built on top, and that is where most of the work lands. "Our cloud provider is compliant, so we are compliant" is the assumption that fails most often.

Each requirement falls into one of three buckets: inherited from the provider (physical security of the data center), shared (encryption, where the provider ships FIPS-validated modules and you must turn them on everywhere), or customer-owned. The authoritative split is the provider's Customer Responsibility Matrix. Get it first and map it requirement by requirement into your SSP, as 170.19(c)(2)(ii) requires.

Customer-owned items include MFA configuration, session lock and termination, least privilege, audit log retention and review, configuration baselines, vulnerability scanning cadence, media sanitization, security awareness training and personnel screening.

The paperwork is bigger than teams expect: the SSP, the CRM mapping, policies and procedures for every family, and evidence for each requirement against the assessment objectives in NIST SP 800-171A. The assessor marks a requirement MET only when every applicable objective has final evidence.

Your tool stack also matters. Under the final rule's External Service Provider table, a cloud service that handles CUI must meet the 7012 FedRAMP requirements, and a non-cloud service provider that handles CUI is pulled into your assessment scope. Ticketing, source control, observability, support desks and password managers all qualify the moment CUI can reach them.

A worked example: audit log review (AU.L2-3.3.3, a 1-point requirement). Your provider gives you the logging service, which is inherited. You decide what gets logged, where it is retained, who reviews it and how often, and you prove it. The evidence pack is an audit policy, a log source inventory, retention settings, a review procedure, and dated records of real reviews with follow-up tickets.

Where does CMMC break a normal software delivery pipeline?

The requirements that hurt software vendors most are ordinary engineering conveniences that quietly move CUI outside the boundary: hosted CI/CD runners, preview environments seeded with production data, centralized logging, error tracking and support tooling.

• CI/CD. Hosted runners and registries sit outside your boundary. If builds touch CUI test fixtures, or if the deploy pipeline holds credentials to the enclave, an assessor will trace that path end to end. Run runners inside the enclave or prove the pipeline never touches CUI.
• Preview environments. They are fine until someone seeds them with real data, at which point they are CUI Assets. Use synthetic or anonymized seed data and document the data flow showing previews never receive CUI.
• Observability. Request bodies and stack traces routinely carry CUI. A SaaS APM or log platform then becomes an in-scope provider, and as a cloud service it needs FedRAMP Moderate or equivalency.
• FIPS cryptography. NIST SP 800-171 Rev. 2 requirement 3.13.11 requires FIPS-validated cryptography to protect CUI confidentiality. "We use TLS" is not enough: load balancers, databases, base images and client libraries must use modules on the CMVP validated list. Per NIST's FIPS 140-3 transition page, FIPS 140-2 validations moved to the historical list on September 21, 2026, so check which certificate your modules rely on.
• Developer access. Break-glass access, bastions, US persons restrictions where export control applies, and a complete audit trail of who touched production, when and why.

The recurring cost nobody budgets is the two-estate reality: a commercial estate plus a CUI enclave, with two deployment workflows and two sets of tribal knowledge. That second workflow drifts and becomes the thing that fails the assessment.

What does CMMC 2.0 Level 2 cost and how long does it take?

DoD estimates a Level 2 C3PAO assessment and affirmation at $101,752 for a small entity ($104,670 over three years with annual affirmations) and $112,345 per assessment for a larger entity, assuming NIST SP 800-171 is already implemented. Those figures come from the final rule's regulatory impact analysis and exclude remediation, which for a vendor starting from scratch usually dominates both cost and calendar.

Assessor capacity is a real constraint. DoD estimates 8,350 medium and large entities alone will need Level 2 certification assessments, and it planned for C3PAO-led assessments to ramp from 135 in year one to 4,452 in year four. Check the current list of authorized C3PAOs on the Cyber AB marketplace and book early.

Hidden costs to name in your budget: the sovereign cloud premium, duplicated environments, FIPS-validated components, GRC tooling, consultants, and engineers pulled off product work. Sequence the work: scope, gap assess, remediate, run a readiness review, then book the C3PAO.

Shrinking the boundary is the biggest cost lever. Fewer in-scope assets means fewer controls, fewer artifacts and a shorter assessment.

How do you architect a CUI enclave without maintaining two platforms?

The pattern that works is a small, separate CUI enclave (its own accounts or subscriptions in a FedRAMP-authorized region, or an isolated Kubernetes cluster) running the same deployment workflow as the rest of your estate. Engineers learn one system, and you never hand-roll a second pipeline you then have to prove to an assessor.

The enclave checklist:

• Separate accounts, subscriptions or projects, with no shared identity plane with the commercial estate.
• Private networking with explicit egress control.
• A dedicated, immutable logging sink.
• A data flow diagram that matches the SSP exactly.
• Only CUI-touching services inside. Everything else stays outside as Out-of-Scope or Contractor Risk Managed Assets, documented as such.

Now the honest part about Qovery. Qovery holds no CMMC certification and no FedRAMP authorization, and using Qovery does not make anyone Level 2 compliant. Control implementation and evidence remain your responsibility. See our security page and trust center for what Qovery does and does not cover.

What Qovery changes is the engineering cost of a small, reproducible boundary. Qovery deploys and operates applications inside your own AWS, Google Cloud, Azure or Scaleway account, or your existing Kubernetes cluster, so workloads, data and the cloud bill stay inside the boundary you got authorized. No vendor-hosted runtime holds your CUI.

The same workflow runs in both estates: git-push deployments, preview environments per pull request (with synthetic data in regulated scopes), per-environment RBAC, managed cluster upgrades and auto-stop for non-production. That is how a team without a dedicated platform or DevOps group runs Kubernetes in a regulated enclave without managing it by hand. If your enclave sits in a government region, confirm with us that your specific region and cluster setup are supported before you plan around it.

How do I stand up and operate a regulated enclave from Claude Code or Cursor?

Install the Qovery Agent Skills once, then drive the deployment workflow in plain language from the coding agent you already use. The agent proposes each action and waits for approval before anything runs, which also leaves an approval trail you can keep as evidence.

curl -fsSL https://skill.qovery.com/install.sh | bash

# Or scoped to a single project repository
curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

# Qovery MCP Server in Claude Code (OAuth, read-only by default)
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

# Write access, only when you want the agent to act (also enable it in the Qovery Console)
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The skills (qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview, qovery-terraform) do the work, and the MCP Server inspects what already exists. Then ask, for example, "deploy this service to the enclave cluster in my own cloud account with Qovery."

In a regulated boundary, keep agent access read-only by default, record agent-initiated changes in your audit evidence, and never paste CUI into a prompt or any model context outside your boundary. See the AI agent quickstart and the Claude Code integration.