MARS-E compliance requires ACA Administering Entities (AEs), their contractors, and connected non-exchange entities to implement a defined set of security and privacy controls, document them in a System Security and Privacy Plan (SSP), and produce assessment evidence that satisfies CMS review under 45 C.F.R. §155.260 and §155.280. The single most important immediate action is confirming whether your SSP exists, reflects your current system boundary, and maps to the MARS-E v2.2 Volume I framework.
Before reading further, run through this immediate readiness check:
- SSP status: Confirm an approved SSP exists and was reviewed within the last 12 months (or after any major system change).
- PII/PHI/FTI inventory: Verify that all data flows involving personally identifiable information, protected health information, and Federal Tax Information are documented and mapped to controls.
- ATC/ISA artifact readiness: Confirm that Authority to Connect packages and Interconnection Security Agreements are current for every external connection to the Federal Data Services Hub or other CMS systems.
- Volume references on hand: Download MARS-E v2.2 Volume II (SSP template) and the 45 C.F.R. §155.260/§155.280 regulatory text before your next planning session.
- Transition awareness: Note that CMS replaced MARS-E with ARC-AMPE effective March 4, 2026, so any new or renewed authorization work now falls under the updated framework.
Key Takeaways
MARS-E compliance requires documented control implementation, a current SSP mapped to the NIST SP 800-53 Moderate baseline, and assessment evidence covering examine, interview, and test objectives across all applicable control families.
| Point | Details |
|---|---|
| SSP is the foundation | Every control must have a specific, traceable implementation description referencing policies, tools, and responsible roles. |
| FedRAMP evidence reduces scope | Infrastructure controls on FedRAMP-authorized platforms can be inherited, concentrating residual work on privacy, supply chain, and PII handling. |
| ARC-AMPE replaced MARS-E | CMS transitioned to ARC-AMPE on March 4, 2026, rebased on NIST SP 800-53 Rev.5 with approximately 402 controls; gap analysis is now urgent. |
| Vendor governance is a common gap | Current BAAs, ISAs, and vendor SSP attestations must be in place for every third party before ATC submission. |
| Primereadysub delivers defined-scope work | Rutledge & Associates provides SSP development, FedRAMP mapping, and assessor coordination as outcome-owned packages for AEs and prime contractors. |
Table of Contents
- What is MARS-E compliance, and who does it apply to?
- How does MARS-E map to NIST SP 800-53 and related standards?
- What does a MARS-E SSP need to contain?
- A prioritized MARS-E compliance checklist for your assessment
- How do MARS-E assessments work, and what does CMS expect?
- Common pitfalls that delay ATC approvals
- Why the conventional wisdom on MARS-E readiness misses the real work
- Primereadysub delivers defined-scope MARS-E readiness work
- Sources
What is MARS-E compliance, and who does it apply to?
MARS-E stands for Minimum Acceptable Risk Standards for Exchanges. CMS developed the framework under its authority in 45 C.F.R. §155.260 (privacy and security of personally identifiable information) and §155.280 (audits) to establish a minimum floor of security and privacy controls for systems that support ACA health insurance marketplaces and related programs.
The document suite has two major versions. MARS-E v2.0, released in 2015, organized requirements across four volumes: a framework overview, minimum acceptable risk standards, a control catalog derived from NIST SP 800-53 Rev.4, and an SSP template. CMS later published an interim MARS-E v2.2 release that harmonized control parameters with CMS Acceptable Risk Safeguards and updated the SSP template with clearer instructions and annual review requirements.
| Volume | Title | Primary Use |
|---|---|---|
| Volume I | Harmonized Security and Privacy Framework | Defines scope, applicability, and control parameter alignment |
| Volume II | ACA Administering Entity SSP | SSP template, instructions, and review cadence |
| Volume III | Minimum Acceptable Risk Standards | Control catalog and implementation guidance |
| Volume IV | Assessment Procedures | Assessment objectives aligned to NIST SP 800-53A |
Who is in scope? The framework applies to a broader set of entities than many teams initially assume:
- Federally Facilitated Marketplace (FFM) and State-Based Marketplace (SBM) operators
- State Medicaid and CHIP agencies whose systems connect to the Federal Data Services Hub
- Basic Health Program administering agencies
- Contractors and subcontractors that operate, maintain, or develop systems processing ACA-related PII, PHI, or FTI
- Qualified Health Plan (QHP) issuers, to the extent they are bound by exchange agreements
- Non-Exchange Entities (NEEs) that receive or transmit data from an AE system
The trigger for applicability is typically a connection to the Federal Data Services Hub or receipt of data from an AE system. If your system touches that boundary, MARS-E controls apply regardless of whether your organization is a state agency, a managed care organization, or a technology contractor.
How does MARS-E map to NIST SP 800-53 and related standards?
MARS-E was built directly from NIST SP 800-53 Rev.4 at the Moderate baseline, with CMS adding ACA-specific parameter values and enhancements for privacy, FTI handling, and exchange-specific operational requirements. That lineage matters practically: if your team already works with NIST control families (AC, AU, CM, IA, SC, SI, and the rest), the MARS-E catalog is familiar territory with a narrower, more prescriptive parameter set.
Overlap with FedRAMP
FedRAMP also uses NIST SP 800-53 baselines, which creates a meaningful evidence-reuse opportunity. FedRAMP authorization packages and templates document infrastructure-layer controls at the Moderate or High baseline, and those artifacts can serve as supplier evidence during a MARS-E assessment for cloud-hosted components. Microsoft's compliance analysis confirms that FedRAMP attestation documents provide a strong foundation for demonstrating alignment to the MARS-E control catalog. The practical implication: agencies running on FedRAMP-authorized cloud infrastructure can inherit a substantial portion of the control catalog and concentrate residual effort on privacy governance, supply-chain documentation, and PII-handling controls that are not inheritable.
FTI and IRS Publication 1075
Federal Tax Information flowing through ACA systems carries an additional compliance layer. IRS Publication 1075 governs FTI safeguarding requirements, and those requirements run parallel to MARS-E controls rather than being fully subsumed by them. Any system that receives, processes, or transmits FTI must satisfy both frameworks, and the SSP should explicitly identify FTI data flows, map them to Publication 1075 safeguards, and document how those safeguards align with the corresponding MARS-E controls.
The ARC-AMPE transition
The most consequential shift in this space: CMS replaced MARS-E with ARC-AMPE on March 4, 2026, with a Designated Entity (DE) deadline following in June 2026. ARC-AMPE rebases the entire control catalog on NIST SP 800-53 Rev.5, which reorganized control families, renumbered controls, and elevated privacy and supply-chain risk management into the main control set. The ARC-AMPE migration whitepaper references approximately 402 controls in the updated baseline, a substantial expansion from the MARS-E Rev.4 catalog. Entities still operating under MARS-E authorizations need a remapping exercise to verify which Rev.4 control identifiers have changed, merged, or split in Rev.5 before submitting any new authorization package.
What does a MARS-E SSP need to contain?
The MARS-E v2.2 Volume II SSP template is the authoritative source for required fields and documentation expectations. CMS reviewers evaluate SSPs against this template directly, so deviating from its structure creates unnecessary friction during review.
Core SSP fields and documentation requirements
A complete SSP must include:
- System identification and boundary: System name, unique identifier, authorization boundary diagram, and a description of all components within scope.
- System categorization: FIPS 199 impact level (Moderate for most ACA systems), with a documented rationale.
- Control implementation descriptions: For every applicable control, a narrative explaining how the control is implemented, not just whether it is in place. CMS reviewers look for specificity: named tools, configuration standards, responsible roles, and references to supporting policies.
- Traceability artifacts: Each control implementation description should reference the policy, procedure, or technical configuration that evidences it. A control that says "access is managed per policy" without naming the policy or linking to a configuration baseline will likely generate a finding.
- Privacy controls and PIA: Privacy control families (AP, AR, DI, DM, IP, SE, TR, UL in the Rev.4 taxonomy) must be addressed, and a Privacy Impact Assessment (PIA) is required where PII is collected or processed.
- Interconnections: All system interconnections, including Federal Data Services Hub connections, must be documented with ISA references.
- Roles and responsibilities: Identify the authorizing official, system owner, information system security officer (ISSO), and privacy officer, with contact information and defined responsibilities.
- Dates and versioning: SSP version number, date of last review, and planned next review date.
Review cadence and submission expectations
Volume II specifies that the SSP must be initiated early in the system development life cycle and reviewed annually, as well as after any significant system change. CMS also expects a Security Assessment Plan (SAP) and Security Assessment Report (SAR) as companion artifacts. The SAR in particular must be self-contained: CMS reviewers should be able to evaluate findings and residual risk without digging through separate working papers. Any open findings feed directly into a Plan of Action and Milestones (POA&M), which must be tracked and updated on a defined schedule.
The Collaborative Application Life-cycle Tool (CALT) is the CMS system of record for submitting and tracking SSP packages, ATC requests, and POA&M items. Familiarity with CALT's submission workflows and required file formats is a practical prerequisite before any assessment begins.
A prioritized MARS-E compliance checklist for your assessment
The following sequence reflects the order in which evidence gaps most frequently delay ATC approvals. Work through it as a sprint, assigning ownership at each step.
- Confirm SSP currency. Verify the SSP version, review date, and system boundary match the current production environment. Outdated boundary diagrams are among the most common first-round findings.
- Complete the PII/PHI/FTI data flow inventory. Map every data element, its source, destination, storage location, and applicable regulatory category. This inventory drives control selection for privacy families and IRS Publication 1075 requirements.
- Validate access control evidence. Pull current access provisioning records, privileged account lists, and role-based access control configurations. Confirm they match what the SSP describes.
- Collect configuration baseline documentation. For every system component, document the hardening standard applied (CIS Benchmark, DISA STIG, or equivalent) and the last validated scan date.
- Gather vulnerability scanning results. Authenticated scans from tools such as Tenable Nessus or Qualys, dated within 30 days of the assessment, are standard evidence. Unauthenticated or outdated scans will generate findings.
- Assemble audit log evidence. Demonstrate that audit logging is enabled, logs are protected from modification, and log review occurs on a defined schedule. Reference the specific SIEM or log management platform in the SSP.
- Review vendor and NEE agreements. Confirm that Business Associate Agreements (BAAs), ISAs, and vendor SSPs or attestations are current for every third party with access to PII, PHI, or FTI. See the IT compliance checklist for public sector environments for a broader control mapping template.
- Complete or update the PIA. If the PIA predates the current system configuration or a significant data flow change, update it before the assessment.
- Prepare supply-chain documentation. Document software bill of materials (SBOM) where applicable, vendor security reviews, and any open supply-chain risk items.
- Stage the evidence repository. Organize all artifacts by control family in a shared repository so the assessor can navigate without repeated requests. Tools like Xacta, CSAM, or a structured SharePoint library work well for this.
Timeline guidance:
- Days 1–30: SSP currency check, data flow inventory, access control and configuration evidence collection.
- Days 31–90: Vulnerability scanning, audit log review, vendor/NEE agreement audit, PIA update.
- Days 91–180: Supply-chain documentation, POA&M remediation, assessor readiness dry run, CALT package preparation.
Pro Tip: Inherit as much as possible from your cloud provider's FedRAMP package before writing a single new control implementation description. For FedRAMP-authorized infrastructure, FedRAMP templates and authorization packages document infrastructure controls that can be referenced directly in your SSP, reducing the non-inheritable work to the application layer, privacy governance, and supply-chain families.
How do MARS-E assessments work, and what does CMS expect?
Assessment objectives under MARS-E follow the NIST SP 800-53A methodology: for each control, the assessor applies one or more assessment methods (examine, interview, test) against defined assessment objects (policies, procedures, configurations, mechanisms, activities). The result is a determination of whether the control is satisfied, other than satisfied, or not applicable.
CMS expects evidence across all three method types:
- Examine: Policies, procedures, SSP sections, configuration documentation, system logs, scan reports, and interconnection agreements.
- Interview: Conversations with the ISSO, system owner, privacy officer, and relevant technical staff to verify that documented processes are operationally real.
- Test: Technical testing of controls such as access enforcement, audit log generation, encryption configuration, and incident response procedures.
Continuous monitoring
Continuous monitoring under MARS-E (aligned to NIST SP 800-137 / ISCM principles) requires ongoing status reporting rather than a point-in-time snapshot. CMS expects monthly vulnerability scan results, quarterly POA&M updates, and annual SSP reviews as the baseline monitoring cadence. Automated scanning pipelines that push results into CALT or a connected dashboard reduce the manual burden significantly and produce the kind of timestamped, consistent evidence that satisfies reviewers without additional explanation.
ATC and ISA requirements
An Authority to Connect package documents the security posture of a system before CMS authorizes it to exchange data with federal systems. The package typically includes the SSP, SAR, POA&M, and a completed ISA for each interconnection. Under 45 C.F.R. §155.280, CMS retains ongoing oversight authority and can require updated ATCs when system changes affect the authorization boundary. Treating the ATC as a one-time event rather than a living authorization is a common and costly mistake. For guidance on selecting IT partners who understand ATC obligations, the linked resource covers the right questions to ask during vendor evaluation.
Common pitfalls that delay ATC approvals
Most ATC delays trace back to a small set of recurring documentation and governance failures. Recognizing them early saves significant remediation time.
- Weak SSP traceability: Control implementation descriptions that name a control but do not reference a specific policy, configuration standard, or technical artifact. Fix: standardize a control implementation description template that requires a policy citation, a responsible role, and a configuration reference for every entry.
- Inadequate technical testing documentation: Scan reports that are unauthenticated, outdated, or not mapped to specific controls. Fix: schedule authenticated scans within 30 days of the assessment window and map findings to POA&M items before submission.
- Missing or incomplete PIA: A PIA that predates significant system changes or omits FTI data flows. Fix: assign a privacy officer as the PIA owner with a defined update trigger tied to the change management process.
- Inadequate vendor and NEE governance: Third-party vendors without current BAAs, ISAs, or their own SSP attestations. Fix: build vendor security review into the procurement and contract renewal cycle. The contract compliance guide for public sector professionals covers the contract language that enforces downstream security obligations.
- Unmanaged FTI handling: FTI data flows not explicitly mapped to IRS Publication 1075 safeguards in the SSP. Fix: create a dedicated FTI annex in the SSP that cross-references Publication 1075 requirements to MARS-E controls.
- POA&M gaps: Open findings without documented remediation timelines, responsible owners, or milestone dates. Fix: treat the POA&M as a living management document, not a compliance checkbox. CMS reviewers evaluate POA&M quality as a signal of program maturity.
When an assessor requests a remediation plan, respond with a structured POA&M entry that includes the finding description, root cause, planned corrective action, responsible party, and a realistic completion date. Vague or undated remediation commitments extend review cycles.
Why the conventional wisdom on MARS-E readiness misses the real work
Most compliance guidance focuses on the control catalog as if populating SSP fields is the hard part. The actual friction in MARS-E assessments tends to live somewhere else entirely: in the gap between what the SSP says and what the system actually does.
Teams that treat the SSP as a documentation exercise rather than a system description produce plans that look complete on paper but collapse under technical testing. An assessor who interviews a system administrator and finds that the access provisioning process described in the SSP was replaced by a different tool six months ago has found a material finding, regardless of how thorough the written description is. The SSP is not a policy document. It is a factual account of how controls are implemented in the specific system under review.
The second underestimated dimension is vendor governance. AEs frequently have strong internal control postures but weak visibility into what their contractors and NEEs are actually doing with the data they receive. A single vendor without a current BAA or an outdated ISA can hold up an entire ATC package. Building vendor security review into the contract lifecycle, not just the assessment cycle, is the structural fix that most programs delay until it becomes urgent.
The ARC-AMPE transition adds a third layer of complexity. Entities that have invested in MARS-E Rev.4 documentation now face a remapping exercise that is not trivial: NIST Rev.5 reorganized control families, split some controls, and introduced new PT and SR families that have no direct Rev.4 equivalent. Starting that gap analysis now, before a new authorization is required, is the difference between a managed transition and a reactive scramble.
Primereadysub delivers defined-scope MARS-E readiness work
Compliance officers who need SSP development, FedRAMP evidence reuse analysis, and continuous monitoring automation delivered as a defined work package, not a staff augmentation arrangement, have a direct path forward with Primereadysub. Rutledge & Associates brings SDVOSB, woman-owned, and SBA-certified credentials to compliance-heavy public-sector programs, with delivery experience across state agencies in Maryland, New York, and Florida.
Typical engagements cover SSP drafting and gap analysis against the MARS-E v2.2 or ARC-AMPE control catalog, FedRAMP inheritance mapping to reduce non-inheritable control scope, evidence repository organization for CALT submission, and assessor coordination through the ATC cycle. Every engagement is scoped to a defined deliverable set with clear ownership, so prime contractors and agency program managers get audit-ready artifacts without managing day-to-day security work.
To discuss a capability brief or scoped statement of work for your next assessment cycle, contact Primereadysub directly.
Sources
Save these canonical references in your team's evidence repository. Each one serves a distinct function in the assessment and transition cycle.
- MARS-E v2.2 Volume I (Harmonized Security and Privacy Framework)
- MARS-E (US) - Azure Compliance | Microsoft Learn
- NIST SP 800-53 — CSRC NIST
This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.