Scrutineer · By framework

ARC-AMPE compliance software and MARS-E 2.2 migration

MARS-E is not the standard any more. CMS published ARC-AMPE on 4 March 2025, and Volume I says it supersedes and replaces MARS-E effective upon publication. Both deadlines have passed.

Scrutineer maps your MARS-E 2.2 control set onto the Revision 5 baseline ARC-AMPE uses and keeps the artifacts CMS reviews. CMS makes the authorization decision.

or try it below ↓

Control-mapped findings · linked evidence · you decide what to remediate

The Scrutiny Desk

Illustrative sample · not an audit attestation

SOC 2 ISO 27001 HIPAA GDPR PCI DSS

Controls in evidence-linked report out

AI scrutinizes you decide

Why it works

What you get with ARC-AMPE

Scope settled before the control work starts

The same role name appears on both sides of the ARC-AMPE mandatory line. A Service Provider that enables ACA functions is in Table 2 and must implement Volume II; a Service Provider performing non-ACA functions sits in Table 3, where implementation is recommended. Scrutineer records which table you fall under and the technical fact that put you there, so the answer survives the next staff change.

MARS-E 2.2 evidence carried forward, not rebuilt

Your MARS-E program was built on NIST SP 800-53 Revision 4. ARC-AMPE rebases on Revision 5, so most of what you already evidence still holds under a different control identifier. Scrutineer maps the old control set onto the new baseline once and shows which artifacts transfer, which need re-testing, and which requirements are genuinely new.

The artifacts CMS actually reviews, kept current

CMS grants the Hub connection on evidentiary artifacts, not on a claim. The SSPP, ISRA, SAP, SAR, POA&M, PIA and penetration test results are reviewed for completeness and accuracy before an Interconnection Security Agreement is signed. Read-only connections keep the evidence behind each control current between submissions rather than in the fortnight before one.

What it handles

Controls in, an evidence-linked report out

Point Scrutineer at a framework or a vendor and it maps every control, pulls the evidence it can find, flags the gaps and scores the risk, returning a report with linked evidence and a prioritized remediation list. Scrutineer is decision support for readiness, an accredited auditor still issues the attestation.

Places you in Table 2 or Table 3 of ARC-AMPE Volume I, which decides whether Volume II is mandatory or merely recommended for your entity
Maps a MARS-E 2.2 control set built on NIST SP 800-53 Revision 4 onto the Revision 5 baseline ARC-AMPE uses, so migration starts from what you already hold
Tracks the AE and DEE baselines separately, because the two mandatory control counts and the two deadlines were never the same
Keeps the evidentiary artifact set CMS reviews before authorization, including the SSPP, ISRA, SAP, SAR, POA&M, PIA and Risk Acceptance form
Notes that the Security Assessment Workbook is required of ACA Administering Entities only, so a Direct Enrollment Entity is not chasing a document it does not owe
Holds an open item list with named owners for the POA&M, which is the instrument an entity past its deadline is actually negotiating with CMS
Reuses the same control evidence for HIPAA, SOC 2 and ISO 27001, because ARC-AMPE Volume I states its technical controls may facilitate adherence to the HIPAA Security, Privacy and Breach Notification rules
Supports the continuous monitoring obligation, since CMS requires ISCM results rather than a single point-in-time assessment to keep the connection

ARC-AMPE readiness_report

READINESS · 82%

ACCESS CONTROL 91

evidence · MFA enforced and access reviews evidenced.

CHANGE MGMT 78

evidence · Mostly covered; one approval log left untested.

VENDOR RISK 64

evidence · Two subprocessors missing a current review.

ENCRYPTION 86

evidence · Data encrypted in transit and at rest, evidenced.

Example report layout, not customer data

Why Scrutineer

One platform that maps controls and scores risk

Not a static questionnaire, not a pass-fail black box, and not a spreadsheet you maintain by hand. Live control mapping across SOC 2, ISO 27001, HIPAA, GDPR and PCI, automatic evidence and a prioritized gap list, returned as a report you can act on. The AI scrutinizes, you decide.

Mapped to real controls

Every framework is broken down into the controls it actually requires, each scored on a red to amber to green scale, so readiness stays transparent and consistent.

Evidence behind every finding

Each control links to the exact evidence that satisfies it, the policy, the config, the log line, so the finding is auditable and your readiness is defensible.

A prioritized gap list

Open gaps roll up into a ranked remediation list, so the highest-risk findings sit at the top and your team fixes what matters before the audit begins.

ARC-AMPE scope reference

Every ARC-AMPE user type, which side of the mandatory line it falls on, and the single fact that decides it

Published guidance to this framework leads with two numbers, the control counts, and two dates. Neither tells you whether you are in scope. ARC-AMPE Volume I splits its users across two tables, and three role names appear in BOTH: the same job description can be mandatory or merely recommended depending on one technical detail of how you are built. An upstream EDE entity that implements single sign-on is mandatory; the identical entity without it is not. A service provider enabling ACA functions is mandatory; a service provider doing dispute resolution is not. Read the fourth column before you read the control count.

ARC-AMPE user type	What you operate	Volume II status	The fact that decides it	What you must hold to stay connected
Federally-facilitated Exchange	The FFE, run by CMS for states without an SBE or SBE-FP	Mandatory (Table 2)	Operating the federal Marketplace itself	ATC, documented in an Interconnection Security Agreement, on the AE artifact set including the Security Assessment Workbook
State-based Exchange (SBE)	A state IT environment connected to the CMS Data Services Hub	Mandatory (Table 2)	A direct state connection to the Hub. Downstream entities performing ACA functions inherit the obligation	ATC, plus responsibility for downstream entities working with the SBE on ACA functions
SBE on the Federal platform (SBE-FP)	QHP certification, consumer outreach and assistance, with eligibility and enrollment left to HHS	Mandatory (Table 2)	The split of functions under 45 CFR 155.106(c). HHS runs eligibility and enrollment; you keep the rest	ATC covering only the functions you retained, not the ones HHS performs
State Medicaid, CHIP or Basic Health Program agency	An Integrated Eligibility and Enrollment System connected to the FFE through the Hub	Mandatory (Table 2)	The IES connection. CHIP and BHP agencies inherit it by using the Medicaid agency IES	ATC on the AE baseline. The AE deadline was 4 March 2026
Primary Enhanced Direct Enrollment entity	An EDE environment you develop, design and host for your own use or for others	Mandatory (Table 2)	Hosting the EDE environment. Building it for others extends what you are answerable for, not what you owe	RTC as a Non-Exchange Entity, on the DEE baseline. The DEE deadline was the end of June 2026
Hybrid Issuer Upstream EDE entity	Single sign-on that sits outside the scope of the Primary EDE entity's approved IT environment	Mandatory (Table 2)	Implementing single sign-on. The identical entity WITHOUT single sign-on sits in Table 3, where Volume II is only recommended	RTC. Controls may be inherited from the Primary EDE entity, which is the cheapest route available here
Hybrid Non-Issuer Upstream EDE entity	An agent, broker or web-broker using a Primary EDE entity's environment, with functionality added on top	Mandatory (Table 2)	Adding functionality or systems beyond minor branding. Branding changes alone leave you a white-label user in Table 3	RTC covering the additions you made, not the platform you sit on
Service Provider enabling ACA functions	Services such as income verification or healthcare coverage verification	Mandatory (Table 2)	Whether the service enables an ACA function. A service provider performing non-ACA work such as dispute resolution is in Table 3	RTC. This row is where most vendors get the answer wrong, because the job title is identical on both sides
Agent, broker or Agent/Broker Entity (ABE)	State-licensed enrollment assistance, registered with the Exchange	Recommended (Table 3)	Licensing and registration without hosting or modifying an EDE environment	No ARC-AMPE authorization of its own. The obligations arrive through the Exchange agreement instead
State health agency or healthcare organization on non-ACA work	MMIS operations, Medicaid, CHIP or state health programs touching consumer PII	Recommended (Table 3)	Performing non-ACA functions and not being an ACA AE. You may still be a HIPAA covered entity or business associate	HIPAA obligations rather than an ATC. ARC-AMPE is an informative reference here, and a useful one
Readiness platform (where Scrutineer sits)	The control library, the evidence behind it and the artifact set, for whichever table you fall under	Not an ARC-AMPE user	We hold your mapping and evidence. CMS, not a vendor, makes the risk-informed decision to grant the connection	Nothing. We prepare the artifacts; we do not assess you, sign an ISA, or grant an ATC or RTC

Scope, user types and artifacts on this page are taken from the CMS document Acceptable Risk Controls for Affordable Care Act (ACA), Medicaid, and Partner Entities (ARC-AMPE) Volume I, version 1.02 dated 10 April 2025, published by the Center for Consumer Information and Insurance Oversight. That document states ARC-AMPE supersedes and replaces MARS-E and the NEE GRC Framework effective upon publication, which was 4 March 2025. The AE and DEE control counts and the two implementation deadlines are as reported by CMS assessor firms rather than quoted from Volume II, and they are worth confirming against your own CMS guidance. Scrutineer prepares readiness evidence, does not act as an independent assessor, and does not grant or negotiate an Authority to Connect.

Good questions

Questions about ARC-AMPE

No. CMS replaced it. ARC-AMPE Volume I states that ARC-AMPE supersedes and replaces MARS-E and the NEE GRC Framework effective upon publication, and version 1.0 was published on 4 March 2025. MARS-E 2.2 has not been the governing standard since then, so a program still being run and assessed against MARS-E is being measured against a retired document.

ARC-AMPE is the Acceptable Risk Controls for Affordable Care Act (ACA), Medicaid, and Partner Entities, published by the CMS Center for Consumer Information and Insurance Oversight. It is a single integrated set of security and privacy standards for Exchanges and the entities that support them, built on NIST SP 800-53 Revision 5, and it replaced two earlier frameworks at once: MARS-E for administering entities and the NEE GRC Framework for non-Exchange entities.

Three things changed, and only one of them is the control list. ARC-AMPE rebases from NIST SP 800-53 Revision 4 to Revision 5. It merges the two separate frameworks that used to govern administering entities and non-Exchange entities into one document with a tailorable overlay. And it adds enterprise risk management, because CMS wrote that a wholly compliance-based framework risks becoming a checkbox exercise. The scope tables were also redrawn, which is what catches entities out.

There were two, and both have passed. ACA Administering Entities were required to be compliant by 4 March 2026, one year after publication. Direct Enrollment Entities followed at the end of June 2026. An entity that is not there yet is not out of options, but it is negotiating through a Plan of Actions and Milestones rather than working to a deadline.

The minimum baselines are reported as 402 controls for Administering Entities and 308 for Direct Enrollment Entities, both derived from NIST SP 800-53 Revision 5. Treat those as the floor rather than the answer: Volume I is explicit that each entity must also assess its own environment to determine what additional controls are needed, so the baseline is where scoping starts.

Volume I splits users across two tables. Table 2 is mandatory: the FFE, State-based Exchanges, SBE-FPs, state Medicaid, CHIP and Basic Health Program agencies, Classic and Primary EDE entities, hybrid upstream EDE entities implementing single sign-on, and service providers that enable ACA functions. Table 3 is recommended: white-label upstream EDE users, agents and brokers, service providers on non-ACA work, and health organizations handling consumer PII outside the ACA.

It depends on what the service does, not on what you are called. A service provider whose services enable ACA functions, such as income verification or healthcare coverage verification, is in Table 2 and must implement Volume II. A service provider performing non-ACA functions, dispute resolution being the example CMS gives, is in Table 3 where implementation is strongly recommended but not mandated. The same two words describe both.

For a hybrid issuer upstream EDE entity, yes, and it is the clearest example of how the scope tables work. An upstream EDE entity that implements single sign-on outside the Primary EDE entity's approved environment appears in the mandatory table. The same entity without single sign-on appears in the recommended table. One architectural decision moves you across the line, and no control count tells you that.

Both are documented in an Interconnection Security Agreement with CMS, and both gate your connection to the CMS Data Services Hub. The Interconnection Security Agreement establishes the Authority to Connect for Administering Entities and the Request to Connect for Non-Exchange Entities. The distinction matters when you are reading guidance, because material written for a state Exchange describes the ATC path and will not match a vendor's.

Volume I gives a non-exhaustive list of fourteen. The core set is the System Security and Privacy Plan (which is ARC-AMPE Volume II itself), the Information System Risk Assessment, the Security Assessment Plan and Report, the POA&M, the Privacy Impact Assessment, penetration test results and a Risk Acceptance form, alongside the agreements: ISA, Data Use Agreement, Information Exchange Agreement, Computer Matching Agreement, MOU or MOA, and a Change Notification form.

No. Volume I footnotes the Security Assessment Workbook as required for ACA Administering Entities only. It is a small detail with a real cost attached, because DEEs working from guidance written for state Exchanges routinely start building a document they do not owe, and the reverse mistake is worse: an AE that omits it submits an incomplete package.

You keep the connection by showing CMS a credible path rather than a finished state. Authorization is a risk-informed decision made on evidentiary artifacts, and CMS explicitly verifies that outstanding findings, risks and vulnerabilities are resolved or mitigated. A realistic POA&M with named owners and dates is the instrument that carries you, which is why the open item list matters more right now than the control count.

No, and it does not claim to. Volume I says ARC-AMPE includes technical controls that may facilitate adherence to the HIPAA Security, Privacy and Breach Notification rules. That is help, not substitution. Many entities in Table 3 are HIPAA covered entities or business associates whose real obligation is HIPAA, with ARC-AMPE serving as a stronger reference than the Security Rule provides on its own.

No, and the names invite the mistake. ARS is the CMS-internal control baseline, currently version 5.2, applied to CMS systems. ARC-AMPE is the standard for Exchanges, Medicaid agencies and their partner entities. Both descend from NIST SP 800-53, both come from CMS, and they govern different populations. Check which one your agreement names before you buy against the wrong catalog.

The evidence work can, which is where the hours are. Control mapping from a MARS-E 2.2 baseline to Revision 5, artifact collection, POA&M tracking, continuous monitoring output and reuse of the same evidence for HIPAA, SOC 2 and ISO 27001 are all repeatable. The scoping decision, the risk acceptance and the CMS authorization itself are judgment calls that stay with you and with CMS.

For the assessment work, usually yes, and that is separate from the software. CMS reviews artifacts including a Security Assessment Report, and Administering Entities documenting an annual attestation with an independent assessor agree the testing approach with that assessor before the assessment begins. A readiness platform prepares what the assessor tests. It does not replace the assessor, and Scrutineer does not act as one.

Read every compliance and risk question

Keep reading

Guides that go deeper on this framework

ARC-AMPE compliance cost and timeline

What the migration actually costs, what drives the number, and what a missed deadline changes.

Read the guide

FISMA compliance software

How federal obligations reach state agencies and grantees through program terms rather than directly.

Read the guide

HIPAA compliance checklist

The Security Rule standards most ARC-AMPE Table 3 entities are actually measured against.

Read the guide

Explore more

More ways to scrutinize compliance and risk with Scrutineer

SOC 2 compliance

Map controls to the Trust Services Criteria, collect evidence, and close gaps before audit.

Learn more

SOC 2 compliance software

A platform that maps SOC 2 controls, automates evidence, and tracks readiness continuously.

Learn more

ISO 27001 compliance

Map your ISMS to Annex A, automate evidence, and stay certification-ready.

Learn more

See every use case See pricing Back to Scrutineer

Stop guessing about readiness. Scrutinize on real evidence.

Point Scrutineer at a framework or a vendor and it maps every control, gathers evidence and scores the risk, returning an evidence-linked report and a prioritized gap list. The AI scrutinizes, you decide.

See pricing

SOC 2, ISO 27001, HIPAA, GDPR & PCI · evidence-linked controls · readiness, not certification