MARS-E to ARC-AMPE: Guide for state Medicaid agencies on AWS

On March 4, 2026, the Centers for Medicare & Medicaid Services (CMS) replaced the Minimum Acceptable Risk Safeguards for Exchanges (MARS-E) v2.2 with the Acceptable Risk Controls for Affordable Care Act (ACA), Medicaid, and Partner Entities (ARC-AMPE). ARC-AMPE rebases the compliance program on NIST SP 800-53 Revision 5, expands the control catalog significantly for administering entities (AE) and Direct Enrollment (DE) entities, and merges privacy and security into a single governance model.

The AE deadline passed as of March 4, 2026. The DE deadline is in June 2026. For agencies running Medicaid, Children’s Health Insurance Program (CHIP), or Affordable Care Act Marketplace workloads on Amazon Web Services (AWS), ARC-AMPE is now in scope.

This post is for two audiences. The first is agencies already running MARS-E-compliant workloads on AWS that are looking to map their existing posture onto the new framework. The second is agencies planning a migration from on-premises infrastructure where ARC-AMPE will be in scope from the first day.

What’s different about ARC-AMPE

Three things changed, and they’re the reason existing MARS-E documentation can’t be relabeled:

1. NIST 800-53 Rev 4 became Rev 5

Under MARS-E, the System Security and Privacy Plan (SSPP) tracked controls against NIST SP 800-53 Rev 4. ARC-AMPE moves to Rev 5. Rev 5 reorganized control families, renumbered controls, retired some controls, added others, and pulled privacy out of a separate appendix and into the main catalog. Every existing MARS-E control mapping requires an analysis against the new numbering.

2. Privacy and security now live in the same plan

MARS-E maintained 18 security domains and eight privacy domains as parallel tracks. Many agencies ran them on separate teams, with separate documentation, and on separate assessment cycles. ARC-AMPE collapses everything into 20 unified control families in a single SSPP. Privacy controls sit alongside security controls, and the assessment covers both. For agencies where privacy and security have historically been separate functions, ARC-AMPE requires those teams to coordinate under shared governance.

3. Two new control families with no MARS-E predecessor

Two of the 20 families are net-new and don’t have a MARS-E equivalent to anchor against:

• PT (Personally Identifiable Information Processing and Transparency) – Ten new controls
• SR (Supply Chain Risk Management) – Six new controls

These controls require technical implementation in your applications and data layer as well as new policies. The following table summarizes the key differences between MARS-E v2.2 and ARC-AMPE v1.0:

How AWS reduces the gap

ARC-AMPE inherits its control catalog from NIST SP 800-53 Rev 5. AWS holds Federal Risk and Authorization Management Program (FedRAMP) authorizations built on the same standard, which means a significant portion of the ARC-AMPE catalog can inherit the controls enabled by AWS.

This is the standard AWS shared responsibility model applied to a control catalog that ARC-AMPE happens to share with FedRAMP. Customers can think about it this way:

• AWS-inherited controls – AWS operates under its FedRAMP authorization. Agencies reference AWS compliance evidence in AWS Artifact. Physical and Environmental Protection (PE) and Media Protection (MP) families fall here.
• Shared controls – AWS provides infrastructure capability, and the agency configures and operates it. Most of Access Control (AC), Audit and Accountability (AU), Configuration Management (CM), Contingency Planning (CP), and System and Communications Protection (SC) sit in this category.
• Customer-owned controls – AWS provides tooling at most; the agency owns the process, documentation, and execution. Awareness and Training (AT), Planning (PL), Personnel Security (PS), Program Management (PM), and the two new PT and SR families fall here.

For agencies running on AWS today, the implementation concentrates on customer-owned and shared categories. Crosswalks between the AWS FedRAMP package and ARC-AMPE indicate the majority of the catalog is satisfied or partially satisfied through inheritance and shared configuration, with the residual work concentrated in privacy governance (PT, PM), supply chain documentation (SR), and a focused set of personally identifiable information (PII)-handling controls.

Where Security Hub CSPM can help

For most compliance frameworks, AWS Security Hub Cloud Security Posture Management (CSPM) is a useful tool. For ARC-AMPE specifically, AWS Security Hub CSPM NIST 800-53 standard enabled runs continuous automated checks against the same control catalog ARC-AMPE is built on.

That alignment means continuous monitoring is built in. ARC-AMPE requires an Information Security and Privacy Continuous Monitoring (ISCM) program. Security Hub CSPM, with the NIST 800-53 Rev 5 standard enabled, closes that requirement for a substantial portion of the catalog by default. Audit evidence is also generated. Security Hub CSPM publishes findings using NIST 800-53 Rev 5 control identifiers. Those are the same identifiers an ARC-AMPE assessor will reference. The following table maps core AWS services to the NIST 800-53 control families they support and their role in continuous monitoring:

If you’re already on AWS

If your agency is running MARS-E-compliant workloads on AWS today, the transition to ARC-AMPE is smaller than the whole list of 402 controls. Most of the infrastructure investment is carried forward. There are three primary places to focus on: rebuilding the SSPP against the new control structure, implementing the PT family controls in the application layer, and formalizing supply chain risk documentation.

What carries forward

The portions of your AWS environment that derive from FedRAMP authorization (PE, MP, the infrastructure layers of AC, AU, CM, SC, SI) carry forward without modification. The shared responsibility model doesn’t change. Specifically:

• Multi-account structures and service control policies (SCPs)
• AWS Identity and Access Management (AWS IAM) roles, policies, and permission boundaries
• AWS Key Management Service (AWS KMS) keys, key policies, and encryption configurations
• Amazon Virtual Private Cloud (Amazon VPC) topology, network segmentation, and traffic isolation patterns
• AWS CloudTrail, Amazon CloudWatch Logs, and log retention configurations
• Existing AWS Security Hub, AWS Config, Amazon GuardDuty, and Amazon Macie deployments

If AWS Security Hub CSPM is enabled with the NIST 800-53 Rev 5 standard, the control evaluations from your existing environment translate directly to ARC-AMPE evidence.

The steps in the following action plans deploy AWS services that incur charges including AWS Security Hub, AWS Config, Amazon Macie, Amazon GuardDuty, AWS KMS, AWS Lambda, Amazon API Gateway, Amazon DynamoDB, and Landing Zone Accelerator on AWS. Use the AWS Pricing Calculator to estimate costs for your environment before proceeding and remove any resources you deploy for evaluation that you don’t intend to keep.

Action plan

1. Enable AWS Security Hub CSPM with the NIST 800-53 Rev 5 standard across all in-scope accounts. For multi-account environments, enable AWS Security Hub in the management account and use delegated administration. See Setting up AWS Security Hub for enablement steps.
2. Deploy the AWS Config NIST 800-53 Rev 5 Conformance Pack.
3. Download the FedRAMP CRM from AWS Artifact.
4. Map the inherited controls into the ARC-AMPE Volume II Excel SSPP. For each control in the FedRAMP CRM marked AWS-inherited (PE and MP families); copy the control identifier, implementation status, and AWS evidence reference into the corresponding row; and document the inheritance relationship in the implementation description field.
5. Inventory the non-AWS supplier chain (SaaS, managed services, integrators). The AWS FedRAMP package in AWS Artifact is your supplier documentation for the AWS layer.
6. Use AWS Service Catalog to restrict your environment to pre-approved services for third-party tools and partners.
7. For PT, application owners, data engineers, and privacy teams need to work together to implement these new controls: application owners define PII processing requirements, data engineers build the technical controls (tagging, encryption, consent APIs), and privacy teams validate policy compliance.
8. Deploy Amazon Macie for automated PII discovery.
9. Configure AWS KMS envelope encryption for SSN fields.
10. Build consent capture with Amazon API Gateway, Amazon DynamoDB, and AWS Lambda.
11. Rebuild the SSPP in the ARC-AMPE Volume II Excel template with control owners per family.
12. Map existing AWS evidence (AWS Security Hub findings, AWS Config evaluations, AWS CloudTrail logs) to the new control structure.
13. Configure AWS CloudTrail retention for AU-04 (90-day online, 10-year S3 Glacier Deep Archive).

If you’re migrating from on-premises

If your agency is planning a Medicaid or ACA Marketplace migration to AWS, ARC-AMPE changes how to scope the migration. Several decisions that were optional or deferrable under MARS-E are now architectural requirements.

What carries forward

Your existing MARS-E governance work carries forward as input to the new ARC-AMPE SSPP even though control numbering changes. You don’t have to rebuild organizational governance from scratch.

Action plan

For agencies migrating from on-premises, follow this plan to establish an ARC-AMPE-aligned environment:

1. Deploy the Landing Zone Accelerator on AWS with the following configurations:
   1. a. AWS Security Hub with the NIST 800-53 Rev 5 standard
   2. b. AWS Config with the Conformance Pack
   3. c. AWS CloudTrail with AU-04 retention
   4. d. Organization-level data residency SCPs
2. Define the consent architecture before you start migrating data.
3. Define PII classification of data before you start migrating data.
4. Start executing from step 3 of action plan in previous section for customers already on AWS.

The following diagram shows the recommended starting sequence for ARC-AMPE readiness, with separate entry points for agencies already running MARS-E workloads on AWS and those migrating from on-premises and converging on a shared set of steps:

Figure 1: Action plan

The two new control families: PT and SR

PT and SR are the two control families with no MARS-E predecessor.

PT: PII Processing and Transparency

PT addresses how PII is identified, classified, processed, and managed in the system. The high-leverage controls cluster in three areas:

1. Data tagging and classification (PT-2, PT-3) – PII has to be tagged with its processing authority and permitted use. Amazon Macie provides automated PII discovery in Amazon Simple Storage Service (Amazon S3), and metadata schemas in Amazon DynamoDB or Amazon Relational Database Service (Amazon RDS) can carry processing-authority tags per data element. The pattern that scales is to do classification at the point of ingestion rather than retroactively across an existing data lake.
2. Consent management (PT-4) – Consent capture, enforcement, and revocation typically come together as a small set of components: a preference store (Amazon DynamoDB), an API for capture and update (API Gateway plus Lambda), and an enforcement mechanism that downstream services consult before processing. Records should include timestamp, scope, purpose, and revocation state.
3. SSN handling (PT-7(1)) – SSN protection can be implemented through field-level encryption with AWS KMS envelope encryption, with Amazon Macie custom data identifiers detecting unintentional SSN exposure in unstructured data.

The remaining PT controls (privacy notices, individual access, accounting of disclosures, redress) are largely policy and process, but they need to be backed by technical evidence that these implementations produce.

SR: Supply Chain Risk Management

SR addresses vendor and supplier risk across the service chain.

• The infrastructure layer (SR-3, SR-6) – AWS FedRAMP authorization documents the supplier risk for the AWS services in scope. Pull the FedRAMP package from AWS Artifact and reference it in the Supply Chain Risk Management Plan. The package includes the SSP, the Security Assessment Report, and the Plan of Action and Milestones, which together satisfy a substantial portion of SR for AWS itself.
• Everything else – SaaS tools, managed services, system integrators, and partner entities each need a documented risk assessment with contractual security requirements. An efficient pattern is to maintain a vendor inventory in a single tool with an assessment template and a renewal cadence.

Choosing a region: Commercial or AWS GovCloud (US)

ARC-AMPE doesn’t mandate AWS GovCloud (US). It requires US data residency under SA-9(8) and adherence to the full control catalog, both of which are achievable in AWS US commercial Regions. Many state and local government agencies run regulated workloads in commercial Regions successfully. For agencies with Medicaid workloads requiring FedRAMP Moderate level compliance, US commercial Regions paired with Health Insurance Portability and Accountability Act (HIPAA)-eligible service configurations, FIPS 140 endpoints, AWS KMS encryption, and a signed Business Associate Agreement (BAA) can help to meet compliance. For agencies with workloads needing FedRAMP High compliance, AWS GovCloud (US) can host your workloads. The following table compares AWS US commercial Regions and AWS GovCloud (US) across the factors most relevant to ARC-AMPE compliance:

Where to start

Three actions agencies can take in the immediate future include:

1. Enable AWS Security Hub with the NIST 800-53 Rev 5 standard – This is a high impact step for closing the ARC-AMPE gap. The findings published against Rev 5 control identifiers translate directly into ARC-AMPE evidence, and the continuous monitoring capability satisfies a meaningful portion of the ISCM requirement on its own.
2. Pull the FedRAMP package from AWS Artifact – The package serves as the foundation of the Supply Chain Risk Management Plan for the AWS layer and provides the inherited control evidence for the SSPP. Sign into the AWS Artifact console, download the NIST 800-53 Rev 5 Customer Responsibility Matrix, and stage it as the supplier documentation root.
3. Engage an AWS Security Health Improvement Program (SHIP) assessment – SHIP is a no-cost engagement that evaluates the AWS environment across several security use cases and provides a prioritized remediation roadmap. For agencies preparing for an ARC-AMPE assessment, SHIP is a low-friction way to identify gaps before an assessor does. Reach out to the AWS account team to scope the engagement.

For agencies planning a migration, also reach out to the account team about the Landing Zone Accelerator on AWS. An efficient path to an ARC-AMPE-aligned environment is to deploy the Landing Zone before workloads start moving, then migrate into a baseline that’s already monitored and instrumented.

Conclusion

ARC-AMPE expands the compliance baseline, but the scope is manageable. FedRAMP reciprocity covers most of the catalog at the infrastructure layer, and the residual work concentrates in PT, PM, SR, and a focused set of PII-handling controls.

Agencies already on AWS carry their existing infrastructure investment forward. The residual work is weighted toward documentation and privacy implementation. Agencies migrating from on-premises can land in an ARC-AMPE-aligned environment from the first day through the Landing Zone Accelerator on AWS, gaining inherited controls, automated monitoring, and a compliant foundation as part of the migration.

Compliance is a shared responsibility between AWS and the customer. This post helps agencies understand how AWS services relate to ARC-AMPE requirements and does not constitute legal or compliance advice. Agencies should work with qualified assessors to validate their specific compliance posture. For the list of AWS services in scope of specific compliance programs, see AWS Services in Scope by Compliance Program.