VA Compliance: Why FedRAMP-Aware Is Right and CMMC Doesn't Apply

What security framework does VA work actually require?

A dense, specific stack — none of which is CMMC. FISMA (44 U.S.C. §§ 3551–3558) is the statute requiring the VA to secure its systems, including those a contractor operates on its behalf. The technical baseline is the NIST Risk Management Framework (NIST SP 800-37 Rev. 2) implemented against NIST SP 800-53 Rev. 5 controls, selected at Low/Moderate/High per the system’s FIPS 199 categorization. The VA’s own implementation lives in VA Directive 6500 and VA Handbook 6500, with contractor obligations bound by VA Handbook 6500.6 (Contract Security). In a solicitation, those obligations arrive as VAAR clauses: 852.204-71 (the master information-security clause), the 852.239-70 through -74 IT-services security stack, and 852.211-76 (liquidated damages for a data breach). When VHA protected health information is involved, the contractor is a HIPAA Business Associate and signs a BAA under VAAR 824.103-70. For the cloud underneath, FedRAMP is the standard — and VAEC’s two providers, AWS GovCloud and Azure Government, are both FedRAMP High.

Here’s the cleanest single distinction from DoD: VA does not currently invoke NIST SP 800-171 in its contract clauses. The 800-171 standard is the DoD/DFARS requirement for CUI in non-federal systems — it’s the substance CMMC assesses. VA contractors instead run on the federal-system track (NIST 800-53, plus 800-88 for media sanitization, 800-52 for TLS, FIPS 140-3 for encryption). Different track, different standard, different program.

Why doesn’t CMMC apply to VA contracts?

Because CMMC is, by its own regulation, a Defense Department program. The CMMC Program Rule at 32 CFR Part 170 (effective December 16, 2024) opens by describing itself as “the Cybersecurity Maturity Model Certification (CMMC) Program of the Department of Defense” and establishing requirements “for defense contractors and subcontractors.” It’s administered by the DoD CIO and verified through the DoD’s Supplier Performance Risk System. Its three levels escalate accordingly: Level 1 is an annual self-assessment against the 15 basic safeguards in FAR 52.204-21; Level 2 is the 110 controls of NIST SP 800-171 Rev. 2, mostly assessed by a third-party C3PAO; Level 3 adds 24 enhanced controls from NIST SP 800-172, assessed by the government’s DIBCAC.

What makes CMMC contractually binding is the acquisition rule — the DFARS amendment carrying clause DFARS 252.204-7021, which took effect November 10, 2025, launching a four-phase, three-year rollout across DoD contracts. And that’s exactly the point: DFARS is the Defense supplement to the FAR. The clause flows from a DoD prime to its subcontractors on a DoD contract. There is no equivalent clause in the VAAR. A VA contracting officer writing a VA solicitation has nothing to insert that requires CMMC, and couldn’t impose it if they wanted to. The flow-down simply doesn’t reach VA awards.

One edge case is worth naming, because it’s the source of most confusion: a vendor that performs on both VA and DoD contracts will need to meet the CMMC level its DoD instrument requires — for the systems used on that DoD work. But its VA work continues to run under the VA’s FISMA/800-53/VA ATO regime. CMMC attaches to the DoD contract, not to the company in the abstract, and not to anything on the VA side.

(There’s a wildcard on the horizon — the FAR CUI Proposed Rule, published January 15, 2025, which if finalized would extend NIST 800-171 Rev. 2 and an 8-hour incident-reporting requirement to civilian-agency contractors, VA included. It’s not final, and it’s been sitting under a regulatory freeze. But note what it would and wouldn’t do: even if it lands, it would impose 800-171 controls, not CMMC — the assessment program stays DoD-only.)

What does “FedRAMP-aware” honestly mean — and what doesn’t it mean?

This distinction is load-bearing, and getting it wrong is how vendors get into trouble. FedRAMP is a registered GSA trademark, and the FedRAMP PMO recognizes exactly three Marketplace statuses: FedRAMP Ready, FedRAMP In Process, and FedRAMP Authorized. The PMO has stated plainly that terms like “FedRAMP Compliant” or “FedRAMP Equivalent” are not FedRAMP-certified designations. So “FedRAMP Authorized” is a specific, verifiable thing — a Cloud Service Offering that completed a full assessment, holds an agency or Board ATO, appears on the public Marketplace, and is under continuous monitoring.

A small application-layer SDVOSB is not that, and doesn’t need to be. It isn’t a Cloud Service Provider; it builds an application that runs inside an already-authorized boundary (VAEC on AWS GovCloud or Azure Government, both FedRAMP High) and inherits the bulk of the control families from that boundary, owning only the customer-responsibility controls in its own application layer. That posture has an honest name: FedRAMP-aware (or -aligned) — it builds to the FedRAMP/NIST 800-53 control families and designs for inheritance from VAEC’s FedRAMP High boundary. It is emphatically not “FedRAMP Authorized.” The vendor isn’t on the Marketplace, isn’t under PMO continuous monitoring, and its app isn’t a governmentwide-reusable authorized offering. Claiming otherwise would be false.

Why does the precision matter beyond pedantry? Because misrepresenting a federal cybersecurity credential to win a contract is a documented False Claims Act exposure. The DOJ’s Civil Cyber-Fraud Initiative produced a stream of settlements in 2025 — including MORSECORP at $4.6 million (the company had implemented only about 22% of the required NIST 800-171 controls while a passing score sat in the government system), Raytheon/RTX at $8.4 million, Illumina at $9.8 million, and Health Net Federal Services at $11.25 million. The legal theory doesn’t require a breach — just a false certification. A vendor claiming a FedRAMP authorization it doesn’t hold is making exactly that category of representation. Honesty here isn’t only ethics; it’s risk management.

Why does leading with CMMC on a VA bid signal misalignment?

This isn’t a knock on CMMC. It’s a serious, well-built program, and for a vendor pursuing DoD work that handles CUI, achieving Level 2 is the right and necessary investment. The problem is purely one of placement. On a VA proposal, “CMMC Level 2 certified” as your headline security claim tells the contracting officer one of two things: either you don’t know which framework governs VA work, or you’re using “CMMC” as a generic synonym for “cybersecurity maturity.” It’s the same signal a vendor would send by leading a healthcare-agency bid with “HITRUST certified” when the requirement was FedRAMP — confident, but aimed at the wrong target.

The framework-fluent posture, in the order a VA contracting officer wants to hear it: SDVOSB via SBA VetCert (the procurement gate); FedRAMP-aware engineering that inherits from VAEC’s FedRAMP High boundary and builds to NIST 800-53 Rev. 5, VA Handbook 6500/6500.6-literate and VA-ATO-ready (the authorization mechanics live here); M-25-21 alignment for any high-impact AI use case; and HIPAA BAA readiness where PHI is in play. That sequence demonstrates fluency in the regime that actually applies.

How should a VA AI vendor represent its security posture?

Plainly, and without inflation. Here’s the honest guide.

You can truthfully say:

• “We’re an SDVOSB, SBA VetCert-certified.”
• “We’re FedRAMP-aware: we design and build to the FedRAMP / NIST SP 800-53 Rev. 5 control families.”
• “We deploy inside the VA Enterprise Cloud — AWS GovCloud and Azure Government, both FedRAMP High. Our applications inherit control implementation from the VAEC boundary; we own the customer-responsibility controls.”
• “We’re aligned to VA Directive/Handbook 6500, Handbook 6500.6, and the standard VAAR security clauses.”
• “We’re M-25-21-aligned; high-impact AI use cases are scoped through the VA’s governance process.”
• “We don’t hold CMMC, because CMMC is a DoD program that doesn’t apply to VA contracts.”

You must not say:

• “FedRAMP Authorized” or “FedRAMP certified” (no Marketplace listing — false).
• “FedRAMP Compliant” / “FedRAMP Equivalent” (per the PMO, not certified designations).
• “CMMC Level 2 certified” (false — and irrelevant to VA work).
• “VAEC requires CMMC” (it doesn’t).

And the honest line on the cloud stack: Cloudflare for Government has been FedRAMP Moderate Authorized since 2022, and Cloudflare announced in early 2025 its intent to pursue FedRAMP High, with its AI tooling targeted for both boundaries in 2026 — forward-looking statements, not achieved status. So for sensitive or PHI workloads today, the FedRAMP High requirement is met by hosting inside VAEC; Cloudflare-native is appropriate for lower-sensitivity edges. Don’t pitch a Cloudflare-only path for PHI.

Working with Truvisory

Truvisory is an SBA-verified SDVOSB founded by a combat veteran. We’re FedRAMP-aware, not CMMC-certified — by design, because CMMC is a DoD program and our VA work runs on the FISMA / NIST 800-53 / VA ATO / FedRAMP track, with sensitive and PHI workloads hosted inside VAEC’s FedRAMP High boundary. We’d rather tell you exactly what applies than dress up a credential that doesn’t.

If you’re a VA contracting officer or program manager trying to vet a vendor’s security posture, that precision is the point — and it’s the same precision we bring to the build. Book a scoping call. For how a system gets authorized, see the ATO/VAEC/FedRAMP guide; for how the AI is governed, the M-25-21 guide; for the capabilities, document automation, the RAG policy assistant, and claims automation; and the VA AI modernization pillar for the whole picture.