CMS Compliance for AI Voice Agents: What Health Contractors Need to Know

The CMS Compliance Stack and Why AI Voice Lives Inside It

Any AI voice deployment that touches CMS-administered programs - Medicare, Medicaid, the Federally Facilitated Marketplace, the Children's Health Insurance Program, the CMS-operated Centers for Clinical Standards and Quality data feeds - lands inside a layered federal information-security regime. The layers are not optional; they are sequenced obligations that a contractor must satisfy in order before the system can carry a single live call.

The base layer is FISMA. The Federal Information Security Modernization Act of 2014 mandates that every federal information system be assessed against an impact-categorized control baseline (FIPS 199 / FIPS 200), receive an Authority to Operate (ATO) from a designated Authorizing Official, and be continuously monitored. NIST SP 800-53 Rev. 5 publishes the underlying control catalog.

CMS sits on top of FISMA with two implementation-specific frameworks. The CMS Acceptable Risk Safeguards (ARS), currently at version 5.1, is the CMS-specific tailoring of NIST 800-53 for systems CMS operates or that CMS contractors operate on CMS's behalf. MARS-E 2.2 is the corresponding framework for non-federal entities (state Medicaid agencies, marketplaces, MCOs, eligibility contractors) that exchange data with CMS-administered programs. Above those sit HIPAA Security and Privacy Rules, 42 CFR Part 433 (Medicaid program integrity), 42 CFR Part 438 (Medicaid managed care), and the CMS Information Security and Privacy Group (ISPG) review and authorization process.

An AI voice agent that handles a Medicare beneficiary call about claims, schedules a Medicaid recertification appointment, walks an ACA enrollee through marketplace plan selection, or calls a member-services line on behalf of a CMS-contracted MCO touches all of these layers simultaneously. There is no shortcut path. There are, however, well-traveled paths through the framework that experienced CMS contractors take, and the difference between an 8-month ATO and a 20-month ATO is mostly about how cleanly the platform inherits controls from underlying FedRAMP authorizations and how disciplined the SSP and POA&M documentation is.

MARS-E 2.2, ARS 5.1, and How They Differ

The single most common confusion in CMS contracting is the boundary between MARS-E and ARS. They overlap in the underlying NIST control catalog but they apply to different ownership models.

• CMS ARS 5.1. The CMS-specific implementation of NIST 800-53 Rev. 5 controls for systems CMS owns and for systems CMS contractors operate on CMS's behalf. Applies to: CMS-operated marketplace components, Medicare claims processing systems (Medicare Administrative Contractors, Recovery Audit Contractors, Quality Improvement Organizations), CMS data centers, CMS analytic platforms, and CMS-direct contractor systems. Published by the CMS Information Security and Privacy Group. Version 5.0 (2022) and 5.1 (2024) reflect alignment with NIST 800-53 Rev. 5 plus CMS-specific tailoring on cloud, AI/ML, and supply chain.
• MARS-E 2.2. The Minimum Acceptable Risk Standards for Exchanges. Applies to non-federal entities that exchange data with CMS programs - primarily State-Based Marketplaces, State Medicaid Agencies operating Integrated Eligibility Systems that exchange ACA data, MCOs receiving CMS-shared enrollment data, enrollment brokers, eligibility system contractors (Deloitte CalSAWS, Accenture-built TIERS/NYBEAS, Wipro builds, CGI builds), and any subcontractor handling Federal Tax Information (FTI) under the IRS Publication 1075 framework on behalf of an exchange.
• The overlap. Both derive from NIST 800-53 and FISMA. Both publish a control baseline organized by impact category (Low / Moderate / High). Both require a System Security Plan, a Security Control Assessment, and authorization from a designated authority. The control families are largely the same.
• The differences that matter. ARS authorizations are issued by CMS itself (typically through the ISPG). MARS-E authorizations are issued by the relevant State agency Authorizing Official (state CIO, state HHS Secretary, or designated officer) and the assessment evidence is provided to CMS for federal funding-conditionality verification. The ARS continuous monitoring program runs through CMS; MARS-E continuous monitoring runs through the state with reporting up to CMS.
• Tailoring. Both frameworks publish baseline controls but expect the system owner to tailor them - documenting which controls are inherited from the underlying cloud (AWS GovCloud, Azure Government FedRAMP authorizations), which are common controls inherited from a parent system, which are system-specific, and which are not applicable. AI voice systems specifically require additional tailoring on AI/ML supply chain (NIST AI RMF, OMB guidance), model governance, and prompt-injection / data-leakage controls.
• FTI and Publication 1075. Where the AI voice system handles Federal Tax Information (anything carrying SSA wage data, IRS-derived income verification used for marketplace eligibility), IRS Publication 1075 layers on top with its own control set, network isolation requirements, and notification obligations. This is one of the most enforced edges of MARS-E and a frequent finding in MCO and exchange assessments.

How a CMS-Compliant AI Voice Deployment Is Built

The deployment workflow is engineered around the ATO timeline. Every architectural decision in the first 30 days either accelerates or extends the path to authorization.

1. Categorize the system under FIPS 199. Determine the impact level for confidentiality, integrity, and availability. AI voice systems handling PHI, PII, or FTI typically categorize as Moderate; systems handling Medicare claims data or large datasets of beneficiary records may categorize as High. Categorization drives the entire control baseline.
2. Inherit FedRAMP-authorized infrastructure. Build on Amazon Connect (FedRAMP High), Azure OpenAI Service (FedRAMP High), AWS Transcribe (FedRAMP), Azure Speech Services (FedRAMP), AWS GovCloud, and Azure Government regions. Inheriting controls from these authorized providers compresses the system-specific control work to a fraction of what an unaccredited stack requires.
3. Define the authorization boundary. Document precisely what is inside the ATO boundary (the AI orchestration layer, the call recording store, the transcript store, the analytics dashboard, the integrations to CMS systems) and what is outside (the underlying cloud infrastructure, the EHR or MMIS at the integration endpoint, the telephony carrier).
4. Write the System Security Plan (SSP). Document every control in the applicable baseline (ARS or MARS-E) - implemented, inherited, hybrid, planned, or not applicable - with implementation evidence. This is where most projects underestimate effort. A well-written SSP for a Moderate AI voice system is 600-1,200 pages.
5. Implement the controls. Encryption at rest (FIPS 140-2 / 140-3 validated modules), encryption in transit (TLS 1.2+), role-based access control with MFA, full audit logging to a tamper-evident store, data residency in the United States, vulnerability scanning, secure development lifecycle documentation, supply chain risk management (NIST 800-161 with EO 14028 SBOM delivery), AI-specific controls (model governance, prompt-injection defense, data leakage controls, model card documentation per NIST AI RMF).
6. Independent Security Control Assessment. A CMS-approved Third Party Assessment Organization (3PAO) or designated assessor independently tests the implementation. Findings are documented as either compliant, partially compliant (with mitigation), or non-compliant.
7. POA&M and remediation. Open findings go into the Plan of Action and Milestones with assigned owners and remediation dates. The Authorizing Official decides which open findings are acceptable for initial ATO and which must close before authorization.
8. Authorization decision. The Authorizing Official issues an ATO, an Authority to Operate with conditions (ATO-C), or a denial. ATOs are typically issued for 1-3 years with continuous monitoring obligations.
9. Continuous monitoring. Monthly vulnerability scan reports, quarterly POA&M updates, annual security control reassessments of a sampled subset, immediate notification of significant changes or incidents.

CMS-Adjacent Call Types AI Handles

Medicare Beneficiary Inquiries

Medicare Administrative Contractor (MAC) call centers handling claims status, benefit explanation, deductible questions, supplier inquiries, appeal status. AI handles the volumetric routine queries and warm-transfers complex appeals to licensed CMS contractor staff.

1-800-MEDICARE Overflow

For contractors operating 1-800-MEDICARE overflow scope, AI handles general benefit information, plan-finder questions, and routine status with full warm-handoff to licensed contractor staff for specific account actions.

Medicaid Member Services

State Medicaid call centers and MCO member services lines. Eligibility questions, benefit verification, prior auth status, recertification, plan changes, complaint intake. MARS-E baseline.

Marketplace Enrollment Support

State-Based Marketplace and Federally Facilitated Marketplace enrollment assistance - eligibility questions, plan comparison, premium tax credit explanation, special enrollment qualification. FTI in scope.

QIO and CMS Quality Program Outreach

Quality Improvement Organization outreach to providers and beneficiaries on quality measure adherence, post-discharge follow-up, readmission prevention.

Medicare Advantage and Part D Member Services

MA / Part D plan member services for plans operating under CMS contract. Star ratings impact ties directly to call quality and resolution metrics.

CMS Innovation Center and Demo Outreach

Outreach for CMS Innovation Center models (ACO REACH, Bundled Payments, Primary Care First) - participant communication, beneficiary attribution notification, quality submission reminders.

State Medicaid Recertification Campaigns

The post-unwinding redetermination operating environment. AI handles the outbound recertification outreach with full MARS-E posture, writing back to MMIS and IES with structured outcomes.

HHS OIG and CMS Program Integrity Inquiries

Provider screening, exclusion-list verification, fraud-and-abuse intake. Sensitive scope; AI captures the structured data and routes immediately to investigative staff.

CMS Provider Enrollment

Provider Enrollment, Chain, and Ownership System (PECOS) inquiries, NPI questions, provider revalidation reminders. High volume, low-complexity, ideal for AI resolution.

Integrations: MMIS, IES, Marketplace, and CMS Data Exchanges

• Medicaid MMIS. Gainwell (HealthInteractive), Conduent, Optum (multiple states), DXC, CNSI / Acentra Health, HPE/Accenture-built MMIS. Integration via REST API, HL7 FHIR where supported, and secure SFTP for batch.
• Integrated Eligibility Systems (IES). Deloitte (California CalSAWS, Colorado PEAK, Michigan Bridges, Florida ACCESS), Accenture (Texas TIERS, New York NYBEAS), Wipro, CGI, CNSI, custom state builds. Carry MARS-E and FTI scope.
• Federally Facilitated Marketplace (FFM) Hub. CMS Hub services for eligibility verification, identity proofing (Experian RIDP), income verification (IRS / SSA / VA / DHS / SAVE).
• State-Based Marketplaces. Pennsylvania Pennie, Connecticut AHCT, Washington Healthplanfinder, California Covered California, New York State of Health, others.
• Medicare Administrative Contractor (MAC) systems. Multi-Carrier System (MCS) for Part B, FISS for Part A, VMS for DMEPOS, CWF for cross-A/B claims.
• Provider Enrollment. PECOS, NPPES, NPI registry.
• HIPAA Eligibility & Benefits (270/271), Claims Status (276/277). Direct EDI integration with carrier and clearinghouse systems.
• CMS data dissemination. Beneficiary Claims Data API (BCDA), Blue Button 2.0, Provider Data Catalog, Medicare Claims Data Use Files - relevant where AI is summarizing or surfacing claims data on a call.
• State Medicaid HIE / care management. ADT feeds, state HIE platforms (Audacious Inquiry, Manifest MedEx, others), care management platforms.
• Continuous monitoring tooling. Vulnerability scanners (Tenable, Qualys, Rapid7), SIEM (Splunk, Sumo Logic, Microsoft Sentinel), CSPM, SBOM management tooling for EO 14028 compliance.

Beyond MARS-E and ARS: HIPAA, 42 CFR, FISMA, and the AI Layer

A CMS-compliant AI voice deployment satisfies more than just the CMS-published frameworks. The full compliance posture stacks several layers.

• FISMA and NIST 800-53 Rev. 5. The federal baseline. Both ARS and MARS-E inherit from this.
• HIPAA Security Rule and Privacy Rule. Business Associate Agreement with the covered entity. Encryption, access controls, audit, breach notification within 60 days. Section 1557 language access obligations layered on top.
• 42 CFR Part 433 (Medicaid program integrity). Recordkeeping, fraud detection, false-claims protections.
• 42 CFR Part 438 (Medicaid managed care). MCO operational requirements, member services obligations, network adequacy reporting.
• 42 CFR Part 2 (SUD records). Where the AI handles substance use disorder records for Medicaid behavioral health, Part 2 layers on with consent-based disclosure and re-disclosure prohibition.
• IRS Publication 1075. Where the system handles Federal Tax Information for marketplace eligibility, FTI controls layer on top of MARS-E with their own boundary, network isolation, and personnel screening obligations.
• NIST AI Risk Management Framework (AI RMF 1.0) and OMB M-24-10. AI-specific governance: model card documentation, bias and disparate impact testing, human oversight design, transparency to call recipients, model lifecycle management. Federal contractors handling AI for federal use are increasingly required to align with the AI RMF and follow OMB guidance on use-case inventory and risk management.
• EO 14028 supply chain. Software Bill of Materials (SBOM) delivery in CycloneDX or SPDX format, signed artifacts, attestation of secure development practices, vulnerability disclosure program.
• Section 508 accessibility. All public-facing components and the AI voice agent's inbound interaction (TTY/RTT support, language switching, ASL warm-transfer) must meet Section 508.
• State language access laws and Section 1557. HHS Office for Civil Rights tightened language access in Section 1557 final rules; AI must support the qualified-interpreter and tagline obligations natively.
• CJIS where relevant. Rare for AI voice in the CMS portfolio, but applies if integration touches law enforcement systems.

The CMS ATO Process Step by Step

Compressed end-to-end view of the path from kickoff to authorization.

1. Kickoff and categorization (weeks 1-2). Joint kickoff with the contractor's security team, the CMS ISPG (or state Authorizing Official), and the integrator. FIPS 199 categorization documented and signed.
2. Authorization boundary diagram and SSP outline (weeks 2-6). Authorization boundary diagram, system architecture, data flow, control inheritance map (FedRAMP-inherited vs. system-specific). Initial SSP outline.
3. Control implementation (weeks 4-20). Implement system-specific controls. Document each control's implementation in the SSP. Stand up continuous monitoring tooling. Build the audit log pipeline. Document AI-specific controls (model governance, prompt-injection defenses, data-leakage controls).
4. Internal readiness review (weeks 16-22). Internal pre-assessment to identify gaps before the formal SCA. Many programs run a "pre-SCA" with the same assessor to flag findings early.
5. Independent Security Control Assessment (weeks 22-30). Formal assessment by a CMS-approved 3PAO or designated assessor. SAR (Security Assessment Report) produced.
6. POA&M and remediation (weeks 28-36). Open findings logged with remediation owners and dates. Critical and high findings closed before submission for ATO.
7. Authorization package submission (weeks 34-40). SSP, SAR, POA&M, contingency plan, incident response plan, configuration management plan, supply chain risk management plan, privacy impact assessment, AI use-case inventory submission per OMB M-24-10. Review by ISPG.
8. Authorizing Official decision (weeks 40-48). ATO, ATO-C, or denial.
9. Continuous monitoring (ongoing). Monthly vulnerability scans, quarterly POA&M updates, annual reassessment of a sampled control subset, significant change re-authorization, incident notification within required SLAs.

Realistic timelines: a new contractor stack with no prior CMS history runs 12-18 months to initial ATO. A contractor with prior CMS authorizations who is reusing inheritance and pattern documentation can compress to 6-9 months. Re-authorization of an already-authorized system after significant change runs 8-16 weeks.

What CMS Reviewers Are Measuring

The single most-flagged finding in CMS contractor assessments is incomplete or stale documentation. Reviewers expect to find every claim in the SSP backed by an evidence artifact - a screenshot, a config export, a policy document, a runbook. AI-specific controls are the second most-flagged area now that OMB M-24-10 and the NIST AI RMF have set explicit expectations for federal AI deployments.

Procurement and Contract Vehicles

• CMS strategic partner contracts. Where the contractor is already a CMS prime (Medicare Administrative Contractor, QIO, Recovery Audit Contractor, Innovation Center Implementation Contractor), AI voice scope can be added as a task order or change order under the existing master agreement.
• State Medicaid IT vehicles. State Medicaid agencies procure under their MMIS and IES vehicles, often with CMS approval required for changes affecting MARS-E scope.
• GSA MAS (IT Professional Services SIN 54151S). Common path for federal agency direct buys of compliance-aligned AI voice services.
• CIO-SP4 (NIH NITAAC). Heavy HHS use including CMS-adjacent task orders.
• 8(a) STARS III. 8(a) GWAC with $50B ceiling. Frequent vehicle for CMS-adjacent small business prime work.
• State cooperative purchasing. NASPO ValuePoint, Texas DIR, Sourcewell, OMNIA Partners. BetaQuick delivers Texas DIR scope through partner Compass Solutions, LLC (DIR-CPO-6057, active through October 2030).
• HHS Program Support Center BPAs. HHS-wide BPAs frequently used by CMS for contact-center scope.
• MAC re-procurement and bridge contracts. Periodic MAC re-procurements are an opportunity to scope AI voice as a contractor capability differentiator.

Frequently Asked Questions