CMS retired MARS-E v2.2 and replaced it with ARC-AMPE, rebasing the program on NIST SP 800-53 Rev 5, folding privacy into a single plan, and adding two control families with no predecessor. This is a re-authorization exercise dressed as a version bump. Here is how to scope the work.
If your state Medicaid agency, exchange, or Direct Enrollment partner has spent the last decade living inside MARS-E, you have probably already heard the news. On March 4, 2026, CMS retired the Minimum Acceptable Risk Safeguards for Exchanges, version 2.2, and launched its replacement: Acceptable Risk Controls for ACA, Medicaid, and Partner Entities, or ARC-AMPE for short.
The first reaction in a lot of program offices is to treat this like a paperwork update. Swap the cover page, remap a few control numbers, and resubmit. That is a costly mistake, and it is the single biggest misread a Medicaid CISO can make this year. ARC-AMPE is not a rebrand. It changes the baseline, the structure, and the scope of what an assessor will expect to see. The deadline for administering entities has already passed, and Direct Enrollment entities are not far behind.
This article is for two groups. The first is an agency already operating under a MARS-E authorization and trying to translate that posture into the new framework. The second is an agency in the middle of migrating off legacy on-premises infrastructure, where ARC-AMPE applies from day one and there is no old package to lean on.
Three changes that make the old paperwork unusable
The NIST baseline moved from Rev 4 to Rev 5.
MARS-E System Security and Privacy Plans were written against NIST SP 800-53 Revision 4, a catalog that dates back to 2013. ARC-AMPE moves the entire program to Revision 5. Rev 5 did not just add controls. It reorganized families, renumbered and retired others, restated many in outcome-based language, and pulled privacy out of a standalone appendix and into the core catalog.
What that means in practice is simple but painful: you cannot assume any existing control narrative is still valid. Every control needs to be checked against its new Rev 5 identifier, and in many cases the implementation statement has to be rewritten because the control is now asking a different question than its Rev 4 ancestor did.
Privacy and security share one plan now.
MARS-E ran eighteen security domains and eight privacy domains as parallel tracks. In most agencies, those tracks were owned by different people, produced different artifacts, and moved on different assessment calendars. Privacy often lived with general counsel or program integrity. Security lived with IT.
ARC-AMPE collapses all of that into twenty unified control families under one SSPP. One plan, one assessment, one evidence set. Where privacy and security have been organizationally separate, the framework now forces a shared governance model. That is a personnel and process problem long before it becomes a technical one. Agencies that wait to resolve ownership usually discover the gap during assessment fieldwork, which is the worst possible time.
Two families arrive with no MARS-E ancestor.
Eighteen of the twenty families have some MARS-E lineage you can anchor against. Two do not:
- PT, Personally Identifiable Information Processing and Transparency. Roughly ten new controls covering how PII is inventoried, minimized, consented to, tagged, and disclosed.
- SR, Supply Chain Risk Management. Roughly six new controls covering vendor risk, component provenance, and acquisition-stage security requirements.
Neither family can be satisfied with a policy memo. PT reaches deep into the application and data layer: field-level handling of Social Security numbers, discovery and classification of PII across storage, retention enforcement, and a defensible inventory of what the system collects and why. SR reaches into procurement, which in state government means coordinating with an office that does not report to security.
The headline number says it all. Administering entities moved from roughly 300 controls under MARS-E to just over 400 under ARC-AMPE, and the SSPP itself shifted from a narrative Word document to a structured workbook. That is around a hundred net-new controls, plus a new deliverable format.
Where cloud inheritance narrows the work
The good news is architectural. Because ARC-AMPE inherits its catalog from NIST SP 800-53 Rev 5, and because major cloud providers hold FedRAMP authorizations built on that same standard, a meaningful share of the catalog can be satisfied through inheritance rather than net-new implementation.
This is the ordinary shared responsibility model applied to a catalog that ARC-AMPE happens to share with FedRAMP. Before you estimate a single hour of work, sort every control into one of three buckets:
- Provider-inherited. The cloud provider operates the control under its own authorization, and the agency cites the provider's compliance artifacts as evidence. Physical and Environmental Protection and most of Media Protection land here. The effort is documentation only.
- Shared. The provider supplies the capability, but the agency configures, operates, and evidences it. Much of Access Control, Audit and Accountability, Configuration Management, Contingency Planning, and System and Communications Protection sits here. The effort is configuration plus proof.
- Agency-owned. The provider supplies tooling at best. Awareness and Training, Planning, Personnel Security, Program Management, and both new families, PT and SR, are yours end to end. The effort is process, policy, and sustained execution.
For an agency already in the cloud, the residual work concentrates almost entirely in that third bucket: privacy governance, supply chain documentation, and a focused set of PII-handling controls in the application layer. That is a very different project plan than trying to implement 402 controls from scratch.
Continuous monitoring is where most programs quietly fail
ARC-AMPE requires an Information Security and Privacy Continuous Monitoring program. This is the requirement agencies most often think they have already satisfied when they have not. A quarterly vulnerability scan and an annual review is not continuous monitoring, and an assessor working from Rev 5 language will say so.
The efficient path is to make your monitoring tooling speak the assessor's dialect. Cloud-native posture management, run with the NIST 800-53 Rev 5 standard enabled, evaluates the same catalog ARC-AMPE is built on and publishes findings under the same control identifiers an assessor will reference. Configuration recording and drift detection covers the CM, CA, and SI expectations. Automated data discovery and classification produces the PII inventory that PT controls demand, rather than a spreadsheet maintained by hand. Validated key management with envelope encryption addresses the encryption-at-rest family and the field-level protection PT expects for identifiers like SSNs. API activity logging with lifecycle-managed retention answers the audit family, including retention duration. Managed threat detection covers system-integrity monitoring and feeds incident handling.
The point is not the product list. The point is that evidence generated in the assessor's own vocabulary removes an entire translation layer from the assessment, and translation layers are where authorization timelines go to die.
If you are already authorized under MARS-E
Do not start from the control catalog. Start from what you already own.
1. Crosswalk before you write. Map every Rev 4 control in the current SSPP to its Rev 5 counterpart and flag three states: carried forward unchanged, carried forward with restated intent, and no equivalent. Only the second and third categories need new work. 2. Rebuild the SSPP in the required structure early. The move from a narrative document to a structured workbook changes how evidence is referenced and how updates are maintained. Agencies that treat this as a formatting task at the end lose weeks. 3. Treat PT as an engineering project. Data inventory, classification, minimization, retention enforcement, and disclosure tracking are application and data-layer changes. They need developer time on a release calendar, not a policy memo. 4. Pull procurement in now for SR. Vendor security requirements, component documentation, and acquisition-stage language require an office outside security to change its templates. That lead time is long and non-negotiable. 5. Resolve privacy and security governance in writing. One accountable owner for the unified plan, one evidence repository, one assessment calendar.
If you are migrating now
An agency moving Medicaid, CHIP, or Marketplace workloads off legacy infrastructure has an advantage worth using: there is no MARS-E-era architecture to retrofit. Design the landing zone against Rev 5 from the start. That means centralized logging with enforced retention, encryption defaults, identity segmentation by data sensitivity, automated posture monitoring, and PII classification wired in at ingestion.
Retrofitting privacy controls into a system already carrying production beneficiary data costs several times what designing them in costs. The migration window is the cheapest opportunity an agency will get for the next decade, and it closes the day the first eligibility record lands.
What we would tell a Medicaid CIO this quarter
The deadline pressure is real, but the risk is not primarily a missed date. The real risk is an authorization package that looks complete and then fails fieldwork on the two families nobody owned. Scope the gap honestly, separate inherited controls from the work that is genuinely yours, and put the privacy and supply chain families on an engineering and procurement calendar rather than a compliance one.
Maverc supports state agencies and their integrators through exactly this kind of transition: control crosswalks against Rev 5, SSPP reconstruction, continuous monitoring architecture, and assessment readiness for systems handling beneficiary data at scale. If your ARC-AMPE gap assessment is still a set of assumptions, we can help you turn it into a defensible plan.
