FedRAMP and Healthcare AI: What Government Contractors Need to Know in 2026

What FedRAMP Is and Why It Exists

FedRAMP was established in 2011 to create a standardized security assessment process for cloud services used by federal agencies. Before FedRAMP, each agency conducted its own vendor security assessments independently, creating duplicated effort and inconsistent security standards across the federal government.

FedRAMP solves this by requiring cloud vendors to go through a rigorous, standardized security assessment once and then making that authorization reusable by any federal agency. The program is managed by the General Services Administration (GSA) and maintained at marketplace.fedramp.gov, where you can verify any vendor's authorization status.

The confusion for healthcare contractors stems from a simple question: does my AI vendor need FedRAMP authorization just because I have a federal contract? The answer depends entirely on what data the AI tool touches, not on the existence of a federal contract relationship.

When FedRAMP Applies to Healthcare AI

FedRAMP applies to your AI tool when that tool processes, stores, or transmits federal data. In healthcare contracting, this typically means one of the following scenarios:

Scenario 1: Direct Federal Agency Contract for Clinical Services

You hold a contract with a federal agency (VA, DoD, Indian Health Service, CMS) to deliver healthcare services directly to federal beneficiaries. Your AI voice agent handles scheduling calls for those beneficiaries and reads or writes to records that are considered federal agency data. In this scenario, FedRAMP authorization for your AI tool is very likely required.

Scenario 2: Federal Agency IT System Integration

Your AI tool integrates directly with a federal agency's IT systems, databases, or networks, rather than operating on your own infrastructure. Any cloud service that touches a federal agency's information systems must be FedRAMP authorized.

Scenario 3: State Medicaid or Subcontract Work

You hold a subcontract under a state Medicaid managed care organization, a federally qualified health center, or another pass-through entity. In most cases, the federal funding does not make your operational tools subject to FedRAMP unless the prime contract or agency explicitly requires it. State-level equivalents or standard HIPAA compliance may be sufficient.

Scenario 4: Contractor Internal Operations Only

Your AI tool manages scheduling and communications for your own practice staff and patients under a state or local government contract, but no federal agency data flows through the system. FedRAMP does not apply. HIPAA compliance and your contract's specific security requirements govern instead.

HIPAA vs. FedRAMP: Understanding the Difference

Many healthcare contractors conflate HIPAA and FedRAMP. They address different risks and are not interchangeable.

A tool that is HIPAA compliant is not automatically FedRAMP authorized. And FedRAMP authorization, while it incorporates HIPAA-relevant controls, is not a substitute for a signed BAA and HIPAA compliance documentation.

Government health contractors need both frameworks applied correctly to their specific situation, not one or the other.

State Medicaid Contracts: Different Rules Apply

State Medicaid programs receive federal funding through CMS but operate under state authority. This creates a distinct compliance landscape that many contractors misunderstand.

For most state Medicaid contracts:

• FedRAMP is not required unless the state contract explicitly mandates it or the tool connects to federal CMS systems directly.
• StateRAMP is increasingly accepted as the state-level equivalent. StateRAMP uses the same NIST framework as FedRAMP but is administered at the state level. Many states now require or prefer StateRAMP for cloud tools used in Medicaid programs.
• SOC 2 Type II plus HIPAA BAA is accepted by many states for operational tools that do not process Medicaid beneficiary data directly through the tool.
• CMS Acceptable Risk Safeguards (ARS) apply to systems that connect to CMS data systems, including the Medicaid Information Technology Architecture (MITA).

Before deploying any AI tool under a state Medicaid contract, review the contract's data security exhibit or information security appendix. These documents specify exactly which security frameworks are required and which tools or data categories they apply to. Your contracting officer can clarify if the exhibit is ambiguous.

Using Non-FedRAMP AI Tools Compliantly

Most healthcare AI voice agents available in 2026 are not FedRAMP authorized. FedRAMP authorization is expensive (typically $1M to $5M) and time-consuming (12 to 18 months for initial authorization). Most commercial AI vendors pursue HIPAA compliance and SOC 2 certification instead, which is appropriate for the majority of healthcare contracting environments.

A non-FedRAMP AI tool can be used compliantly in government health contracting when:

1. The contract does not explicitly require FedRAMP for the specific tool category
2. No federal agency data flows through the tool
3. The vendor provides a signed BAA
4. The vendor holds SOC 2 Type II certification
5. Data is stored in US-based infrastructure
6. The tool meets the security controls specified in your contract's security appendix

Document all of the above before deployment. In the event of an audit, your ability to demonstrate that you evaluated vendor security posture and made a documented compliance determination is as important as the determination itself.

What to Require from Any AI Vendor

Regardless of whether FedRAMP applies to your specific contract, government health contractors should require the following from any AI vendor before signing:

• Signed Business Associate Agreement (BAA). Non-negotiable. Any vendor that hesitates on a BAA is not suitable for healthcare use.
• SOC 2 Type II report. Issued by an independent auditor, covering security, availability, and confidentiality. Request the full report, not just an attestation letter.
• Data residency confirmation. All data processed and stored in the United States. Get this in writing, not just verbally.
• Encryption specifications. TLS 1.2 or higher for data in transit. AES-256 or equivalent for data at rest.
• Audit log documentation. Evidence that all data access and system interactions are logged with timestamps and retained for a specified period.
• Incident response and breach notification policy. Specifically, the timeline for notifying you of a breach (must be within 60 days under HIPAA, but faster is standard practice).
• Penetration testing cadence. Independent penetration testing at least annually, with results available on request.
• Subprocessor disclosure. A list of any third-party vendors that process your data as part of the service.
• FedRAMP status confirmation. Even if not required, knowing where the vendor stands (not authorized, in process, authorized at what level) is useful for future contract requirements.

State Contract Vehicles and What They Cover

State contract vehicles like Texas DIR (Department of Information Resources) simplify procurement for state and local government entities. BetaQuick holds Texas DIR contract DIR-CPO-6057, which allows Texas state agencies, local governments, and eligible entities to procure AI services without a separate competitive bid process.

What DIR contracts do and do not cover from a compliance perspective:

• DIR contracts establish vendor qualification and pricing but do not independently certify security compliance for specific use cases.
• Each agency deploying a DIR-contracted tool remains responsible for ensuring the tool meets their specific security and data handling requirements.
• DIR contracts can be used for state Medicaid program vendors in Texas, but CMS-specific requirements still apply when the work involves federal data systems.
• Other states have equivalent cooperative purchasing programs (NASPO ValuePoint, OMNIA Partners) that similarly streamline procurement without replacing agency-specific security review.

Using a DIR or equivalent state contract vehicle accelerates procurement and establishes a baseline of vendor qualification. It does not replace the security review that should happen before any AI tool touches patient or government data.

Managing Compliance Risk Before Deployment

The highest-risk moment in AI adoption for government health contractors is the gap between signing with a vendor and completing a formal compliance review. Many contractors deploy first and document later. This is the pattern that creates audit exposure.

A practical pre-deployment compliance checklist:

1. Review your contract's security appendix and identify any explicit tool or vendor requirements. Flag anything that mentions FedRAMP, StateRAMP, FISMA, or specific NIST control baselines.
2. Classify the data the AI tool will touch. Federal agency data? State Medicaid beneficiary data? Contractor operational data only? The classification drives the compliance framework.
3. Collect vendor documentation before go-live: BAA, SOC 2 report, data residency confirmation, encryption specs, incident response policy.
4. Document your compliance determination. A one-page memo stating what you reviewed, what you found, and why you concluded the tool is compliant for your use case. Keep it in your contract file.
5. Notify your contracting officer if you are uncertain about a specific requirement. An inquiry before deployment is far less painful than a finding during an audit.

Frequently Asked Questions