VA ATO, VAEC, and FedRAMP: How AI Actually Ships on VA Infrastructure

What is the VA Enterprise Cloud, and why does it matter?

VAEC is the VA’s multi-tenant, FedRAMP High cloud, stood up in 2018 and run by the Enterprise Cloud Solutions Office (ECSO) inside VA’s Office of Information and Technology. It has two production foundations — VAEC-AWS on AWS GovCloud and VAEC-Azure on Microsoft Azure Government — and per the VA’s October 2025 RFI to expand its cloud provider portfolio, it hosts roughly 757 applications and systems, including VistA and the Veterans Benefits Management System. The reason it matters to a vendor is structural: each of those two foundations is a General Support System (GSS) that holds its own VA ATO, and tenant applications inherit from it. As the VA’s own deployment-model document puts it, project teams “leverage established security controls, processes, and operations” from the GSS — but it also warns that an application’s ATO “is separate from the VAEC CSP Environment ATO,” and “each project team is responsible for its application level ATO.” That sentence is the whole game: you inherit the hard part, and you own a thin residual.

Two adjacent platforms come up constantly. VA Platform One (VAPO) is the VA’s containerization PaaS, sitting on top of VAEC, that bakes pre-approved security features into a vetted DevSecOps pipeline so tenant apps clear ATO review faster through platform-layer inheritance. And Lighthouse (the VA API platform at developer.va.gov) is the OAuth-protected API surface for Veteran health, benefits, and claims data — usually the boundary an AI tool reads from, not the thing it deploys into.

How does the VA ATO process actually work?

It’s the NIST Risk Management Framework, implemented under VA Directive 6500 and VA Handbook 6500 (both February 2021), with contractor obligations in Handbook 6500.6. One recent change worth knowing: VA Notice 25-06 (March 2025) superseded the old cloud handbook (6517) and pointed cloud services directly at FedRAMP and OMB M-24-15. The lifecycle runs in seven steps.

1. Prepare

   Designate roles, define the system boundary, pick the hosting environment, and identify which controls you can inherit.

2. Categorize

   A FIPS 199 impact rating driven by whether the system touches PII/PHI. Sensitive Veteran data lands at Moderate or High.

3. Select

   Choose the NIST 800-53 Rev. 5 baseline, then split it into inherited controls (from the GSS, VAPO, and the CSP) versus system-specific ones you own.

4. Implement

   Build it; document every control in the System Security Plan (SSP) plus a Customer Responsibility Matrix.

5. Assess

   An independent Security Control Assessor tests the controls and writes a Security Assessment Report.

6. Authorize

   Residual risks and a Plan of Action & Milestones (POA&M) go to the Authorizing Official, who signs the ATO. That signature — the acceptance of risk — is the one thing the AO cannot delegate.

7. Continuously monitor

   Ongoing scans, POA&M remediation against FedRAMP’s severity SLAs (criticals in 30 days, moderates in 90, lows in 180), and reauthorization.

The roles you’ll meet: a System Owner, an Information System Security Officer (ISSO) who lives in the SSP day to day, an Authorizing Official, a Privacy Officer running the privacy assessment, the Office of Information Security, and — for AI use cases — the Chief AI Officer, who routes AI through the inventory and RMF intakes. The workflow tool is eMASS, the RMF package system the VA adopted from DoD in 2018. Historically a cloud ATO ran 9–18 months; once ECSO built its FedRAMP-inheritance process, teams reported bringing apps into VAEC in 60–90 days. That inheritance pattern is the substrate the new AI ATO sits on.

What is the 60-day accelerated AI ATO — and what isn’t it?

It’s real and published. The VA’s “Building the Future” AI strategy (September 2025) commits the department to an accelerated process that lets “IT products, including AI products, receive an initial VA ATO within 60 days,” and the VA’s M-25-21 compliance plan repeats it and ties AI use cases into the RMF, FITARA, and Unified System Registry intakes.

Here’s the honest part: the VA hasn’t published a discrete step-by-step spec for the 60-day path — no memo number, no published checklist. From the corroborating evidence — ECSO’s pre-existing 60-to-90-day inheritance pattern, the strategy’s framing, and the RMF integration — the practical mechanics are heavy control inheritance (host inside a GSS or VAPO that already holds an ATO, so your SSP only documents residuals), tight pilot scoping (an initial ATO for a defined pilot, not an enterprise rollout), and — for any AI deemed high-impact under OMB M-25-21 — the full minimum practices: pre-deployment testing, an AI impact assessment, ongoing monitoring, and human review. A vendor should state that honestly rather than overpromise a turnkey 60-day guarantee.

Where does FedRAMP fit, precisely?

FedRAMP is the governmentwide cloud authorization program, codified by the FedRAMP Authorization Act in late 2022. Its three impact levels carry escalating control counts — Low = 156, Moderate = 323, High = 410 controls across the NIST 800-53 Rev. 5 families. PHI, PII, and sensitive Veteran data categorize to High, which is exactly why VAEC was built on AWS GovCloud and Azure Government — both FedRAMP High. The Act also gives agencies a “presumption of adequacy”: a CO must presume an existing FedRAMP authorization is adequate for their own ATO decision, absent a documented need for more. That’s a lever a vendor can point a CO toward.

The live modernization is FedRAMP 20x, launched March 2025, pushing machine-readable (OSCAL) submissions and automated validation. GSA reported authorization timelines down to about five weeks and 114 authorizations in FY2025 — more than double the 49 in FY2024 — and in August 2025 prioritized AI cloud services for the 20x track. The VA has skin in this: its OIT chief product officer sits on the FedRAMP Board. The post-2026 phase targets are real but verbal, so treat them as moving.

So can a Cloudflare-native vendor even do VA work?

Yes — with one load-bearing honesty constraint. Cloudflare for Government is FedRAMP Moderate authorized (since December 2022, ~325 controls), and Cloudflare for Government — High is “Agency Auth In Process” on the FedRAMP Marketplace, with zero active authorizations today. Cloudflare announced in August 2025 its intent to bring its AI suite — Workers AI, AI Gateway, Vectorize — into both its FedRAMP High and Moderate boundaries in 2026. The practical translation: until that lands, VA PHI, PII, and Moderate/High-impact Veteran data cannot run in Cloudflare’s AI tooling — it must sit inside the VAEC FedRAMP High boundary on AWS GovCloud or Azure Government. Cloudflare is the right tool for the lower-sensitivity edges: public Veteran-information portals, public-policy RAG over public corpora like 38 CFR, and synthetic-data dev/eval — and only with the sponsor’s FIPS 199 categorization agreeing. This is the same constraint the capability spokes defer to, stated once, here, in full.

How does a small SDVOSB actually ship inside this?

Through the control-inheritance model, which is the unlock for a small team. Deploy into VAEC and you inherit the CSP’s FedRAMP High controls (physical security, environment, hypervisor, base network) and the VAEC GSS controls the VA layered on top (boundary protection, VA identity/PIV/SSO, central logging, ECSO change management) — and, if you build on VAPO, the container-platform controls too. What you still own is the application layer: identity and access in your app, logging into the VA SOC, data handling, secure SDLC and SBOM attestations, vulnerability remediation on the FedRAMP clock, privacy support, Section 508 accessibility on any UI, and — if the AI is high-impact — the M-25-21 obligations.

The realistic 90-day pilot pattern: land inside a sponsor’s existing ATO (a program office, or a prime on T4NG2 or SPRUCE) and scope the AI as a feature inside that boundary rather than a brand-new system; scope the workload to fit the accelerated AI ATO and log it in the AI use-case inventory; pick VAEC-AWS, VAEC-Azure, or VAPO at architecture sign-off and draft the Customer Responsibility Matrix on day one; build with synthetic data first, cutting over to a VAEC FedRAMP High runtime when the ATO is in hand; and engineer continuous monitoring — logging, scanning, POA&M templates, OSCAL-friendly evidence — from the start. A vendor who arrives that way collapses the single biggest source of post-award schedule slip.

Working with Truvisory

Truvisory is an SDVOSB founded by a combat veteran, building working AI on a Cloudflare-native, FedRAMP-aware architecture, fixed-scope, in 90 days — designed for VAEC control inheritance from day one.

If you’re a VA program manager or contracting officer trying to de-risk getting a vendor’s AI tool authorized and running, we arrive ATO-literate: a named VAEC target, an SSP skeleton and Customer Responsibility Matrix at kickoff, a ConMon plan, and a Section 508 baseline — with PHI workloads hosted in VAEC FedRAMP High and Cloudflare reserved for lower-sensitivity edges. Book a scoping call. For the capabilities this authorizes, see document automation, the RAG policy assistant, and claims automation; for the procurement path, the $5M sole-source guide and the VA AI modernization pillar.