ARC-AMPE’s Second Deadline
The Centers for Medicare & Medicaid Services (CMS) published ARC-AMPE (Acceptable Risk Controls for ACA, Medicaid, and Partner Entities) a year ago as a replacement for MARS-E, which is now deprecated. Administering Entities (AEs), state-based health insurance marketplaces and Medicaid agencies had until March 4, yet industry assessors were flagging widespread readiness gaps leading up to the deadline. Direct Enrollment Entities (DEEs), insurers and web brokers, have until the end of June to comply with 308 controls. The NIST revision jump and restructuring of control families broke the old mapping. If your organization is treating ARC-AMPE’s second deadline as a documentation migration, you’re underestimating what changed under the hood.
What Changed and Why It Matters for Cloud Environments
ARC-AMPE replaced MARS-E v2.2. The AE baseline is 402 controls. The DEE baseline is 308. Both are derived from NIST SP 800-53 Revision 5. Four changes have real architectural implications for organizations running Affordable Care Act (ACA) or Medicaid workloads in AWS, GCP, or hybrid environments.
Data residency is now explicit
All data processing and storage must happen within U.S. legal jurisdiction. For cloud environments, this means region-locking, verifying that managed services don’t replicate data outside U.S. regions, and documenting data residency controls. SA-9(8), Processing and Storage Location, is explicitly in the ARC-AMPE baseline. Organizations using multi-region or global cloud configurations need to prove containment.
Cloud-specific controls are gone
Previously, MARS-E maintained separate control expectations for cloud vs. on-premises environments. ARC-AMPE applies uniformly. If you were relying on a lighter control set for your cloud workloads, that distinction no longer exists.
The PT control family is entirely new
Ten Personally Identifiable Information Processing and Transparency (PT) controls covering consent, privacy notices, PII processing purposes, Social Security Number handling, and revocation rights. This family didn’t exist in MARS-E because it didn’t exist in NIST 800-53 Rev 4. These are enforceable privacy controls that need to be implemented at the infrastructure and application layer, not just documented in a policy binder.
Supply Chain Risk Management is now required
SR controls mandate vendor oversight for cloud service providers, managed services, and SaaS tooling used in ACA and Medicaid environments. Documented risk assessments for every vendor in the chain, with contractual security requirements and ongoing monitoring.
The Reciprocity Advantage Most Organizations Are Missing
ARC-AMPE is 402 controls from NIST 800-53 Rev 5. FedRAMP High is 410. The overlap is substantial, and most organizations aren’t mapping it.
We ran the analysis. An organization with an existing FedRAMP Moderate authorization already satisfies 292 of the 402 ARC-AMPE AE controls. That’s 73% coverage before doing any ARC-AMPE-specific work. FedRAMP High covers 302 of 402, or 75%. The numbers for GovRAMP are nearly identical: GovRAMP Moderate maps to 292 ARC-AMPE controls, GovRAMP High maps to 302.
The remaining gap from FedRAMP High is 100 controls, and it concentrates in specific areas. Twenty-eight are Program Management (PM) family controls: organizational governance like risk management strategy, insider threat programs, security workforce planning, and system inventory. These are documentation-heavy but not technically complex. Ten are the entirely new PT family, none of which appear in any FedRAMP baseline. Roughly a dozen more are PII-related controls scattered across other families (SI, SC, AU, SA, CM, AT), covering data minimization, de-identification, disposal, and quality operations. Seven are SA-8 security engineering principle enhancements. Six are maintenance controls.
The practical implication: an organization with FedRAMP Moderate posture doesn’t have a 402-control problem. It has a 110-control problem, concentrated in privacy governance and program management documentation. That’s a fundamentally different compliance project than starting from zero, and it should be scoped accordingly.
State Medicaid agencies and health insurance marketplaces that have done any 800-53-based compliance work, whether for FedRAMP, GovRAMP, or other federal requirements, are sitting on evidence and control implementations that directly satisfy ARC-AMPE. The organizations that treat ARC-AMPE as a standalone assessment are duplicating efforts they’ve already completed.
How Organizations Can Prepare Now
Regardless of where you are in the timeline: run a reciprocity analysis against any existing 800-53 compliance work before scoping net-new effort. Map your data residency controls early, since region-locked cloud environments close multiple ARC-AMPE requirements at once. Build your System Security and Privacy Plan (SSPP) in the new ARC-AMPE Excel template from the start. CMS replaced the old Word format, and converting later breaks every documentation workflow.
Risks of Missing ARC-AMPE’s Second Deadline
File a realistic Plan of Action and Milestones (POA&M) with CMS. Prioritize the PT and SR control families first, since those have no MARS-E predecessor to map from and represent the largest net-new implementation effort. If you have existing 800-53 compliance work from FedRAMP, GovRAMP, or other federal frameworks, you likely already satisfy 70-75% of the baseline. Don’t start from scratch.
DEEs facing the June deadline
Three months is tight for 308 controls. Start with a gap assessment against the DEE baseline specifically. Identify which controls you already meet through existing HIPAA or SOC 2 work.
Conclusion
RKON helps organizations running ACA and Medicaid workloads in AWS and GCP close the ARC-AMPE gap. We maintain cross-framework compliance tooling that maps existing control implementations to ARC-AMPE requirements, so you’re building on evidence you already have rather than starting over. If your team is facing the June deadline or remediating after March, reach out.
Author: Jorge P., Senior Security Engineer, RKON
