CMS ARS and NIST 800-53: What CMS Requires and Who Owns It

What CMS Acceptable Risk Safeguards require from a NIST 800-53 system

The CMS Acceptable Risk Safeguards (ARS) are CMS's tailored form of SP 800-53, and their controls carry the same numbering as NIST, such as AC-1 and AC-2. The baseline that applies to a system is not chosen from the ARS alone. It follows from the FIPS 199 categorization of the system: a system categorized as low, moderate or high impact must implement the ARS controls defined for that baseline. Business owners and contractors should start by confirming the system's categorization with CMS, because every later decision depends on it. The current ARS page lists ARS 5.2, with a record of changes dated July 1, 2026, so confirm that the version you are working to is the one your contract or authorization references.

Ownership is split in a way that is easy to get wrong. CMS states that business owners are primarily responsible for evaluating the ARS and implementing its controls, and that CMS employees, contractors and sub-contractors supporting CMS business missions must observe the baseline policy statements in the CMS information security and privacy policy. Your organization owns the controls and the decisions behind them. An implementation partner can prepare system configurations, control narratives and evidence, but it does not decide what is acceptable risk for CMS. Only an independent assessor issues assessment results, and CMS authorization decisions rest with CMS.

Before any build or evidence work starts, ask CMS and your assessor to confirm three things in writing: the FIPS 199 categorization, the ARS version and the list of CMS-tailored controls that apply beyond the NIST and HHS baselines. Those three answers define the scope of the control set you must evidence. Scope and effort should be quoted against that written list, not against a general reading of SP 800-53.

How the FIPS 199 high water mark selects the ARS baseline

This sequence turns a system's information types into a single impact level, and that level determines which CMS Acceptable Risk Safeguards baseline applies. The output is a documented baseline selection that the system security and privacy plan can cite and an assessor can check. Each step below produces a record that feeds the next.

Inventory the information types the system handles
The system owner, usually the business owner with input from the information system security officer, lists every information type the system stores, processes or transmits. This includes user data, system data and administrative data, in electronic or non-electronic form. The inventory should name the data owner for each type and the mission or business function it supports. The step is done when every information type appears in one list with an owner and a short description, and the list is approved and kept with the system documentation.
Assign a FIPS 199 impact value to each type
For each information type, the owner assigns a potential impact of low, moderate or high for confidentiality, integrity and availability under FIPS 199. The assignment reflects the harm an unauthorized disclosure, modification or loss of availability would cause to the organization or individuals, not the technology used to store the data. Reviewers should challenge values that look arbitrary. The step is done when every information type has three recorded impact values with a written rationale for each.
Take the high water mark for the whole system
The security category of the system is set by the highest impact value found across all information types, separately for each of confidentiality, integrity and availability. A single high value in any one of the three objectives sets that objective to high for the entire system, regardless of how many other types score lower. The team records the result as one three-part category, such as the impact values for confidentiality, integrity and availability. The step is done when the system categorization is signed by the authorizing official or the designated approver.
Match the category to a baseline
The system is low impact only if confidentiality, integrity and availability are all low. It is moderate if at least one objective is moderate and none is high. It is high if any one objective is high. The matched baseline, low, moderate or high, sets the starting set of controls from SP 800-53B. The step is done when the baseline is written into the system security and privacy plan with the categorization that produced it.
Apply the CMS-tailored controls on top of the baseline
CMS controls apply on top of the matched baseline. The ARS defines which controls are mandatory at each baseline, and the CMS-tailored set encompasses the NIST and HHS baselines. Teams confirm that every control defined for their baseline in the current ARS version is accounted for in their control set. Controls are not removed casually: any tailoring decision must be defensible on mission and business needs, backed by an explicit risk-based determination. The step is done when the control set is complete against the ARS and each tailoring decision has a recorded justification.
Document tailoring in the system security and privacy plan
The system security and privacy plan records the categorization, the selected baseline, the CMS-tailored controls, any tailoring decisions and the justification for each. Business owners are primarily responsible for evaluating the ARS and implementing controls, so the plan should name the owner for each control. Assessors use this plan as the starting point for testing. The step is done when the plan is reviewed by the security team, approved by the authorizing official and tied to the assessment scope.
Confirm the ARS version and recategorize on change
Teams confirm which ARS version applies to their system and track its record of changes, since the ARS is updated over time. The team checks the current ARS record before each assessment cycle and whenever the system's information types, mission or connections change. If the impact values change, the categorization and baseline are repeated and the plan is updated. Ask CMS or the contracting office which ARS version governs your contract before you finalize the baseline. The step is done when the version is recorded and a recategorization trigger is written into the change process.

Who must comply with ARS and who owns implementation

CMS states that all of its employees must observe the baseline policy statements in the CMS information security and privacy policy. The obligation attaches to the person's role in supporting CMS business missions, so it applies whether the person works on a system directly or only handles its data or outputs. Employees do not select controls or write system documentation for most systems, but they are expected to follow the rules that the policy sets for their conduct and access.

Policy observance: Employees follow the baseline policy statements in the CMS information security and privacy policy as a condition of their work.
Access conduct: Employees use only the access granted for their duties and do not share credentials or bypass controls.
Reporting: Employees report suspected incidents and control failures through the channels the policy names.
Training participation: Employees complete the security and privacy training the program requires for their role.
Business owner direction: Employees act under the direction of the business owner who is responsible for the system they support.

Confirm with your CMS point of contact which policy version applies to your role and which training records you must keep.

What a CMS contractor must confirm before work starts

A CMS contractor inherits much of its security obligation from decisions made before any control is implemented. Settling these questions with the CMS business owner first keeps the system plan, inherited controls and evidence aligned with the ARS baseline the system actually falls under.

Confirm the FIPS 199 categorization

Ask the CMS business owner which security category applies to the system, covering confidentiality, integrity and availability for each information type. Under FIPS 199 and FIPS 200, the highest of the three impact levels sets the system's overall impact, so one high rating moves the whole system to the high baseline. Get the categorization in writing before selecting controls, because every later decision depends on it.

Confirm the baseline and CMS tailoring

Confirm which ARS baseline (Low, Moderate or High) matches the categorization and which CMS-tailored controls the system must carry. Ask who approved any control removed from the selected baseline and where the justification is recorded. Under SP 800-53B, removals must be defensible on mission and business needs, and every control in the baseline must still be accounted for.

Map inherited and shared controls

Identify which controls come from a hosting provider, a CMS shared service or another system, and which remain the contractor's responsibility. Request the provider's control inheritance documentation and confirm how it covers each inherited control. Inherited controls still need evidence that the inheritance works, so record the boundary between the contractor's and the provider's responsibilities in the plan.

Locate the system security and privacy plan

Ask where the system security and privacy plan lives, who owns it, and which CMS system record it must match. The plan should state the categorization, selected baseline, tailoring decisions and implementation status for each control. Confirm the approval path and the version your team must maintain, so auditors and CMS reviewers see one authoritative document rather than several drafts.

Assign evaluation and evidence roles

Clarify who evaluates whether each control is met and who prepares the artifacts that show it. CMS states that business owners are primarily responsible for evaluating the ARS and implementing controls, and that contractors and sub-contractors must observe the policy statements. Agree in writing which team supplies configuration exports, scan results, logs and training records, and who signs off on each.

Track ARS revisions and changes

Confirm which ARS version applies to the contract and how CMS communicates revisions. Ask how changes to the ARS, to SP 800-53 releases or to the system's boundary will be assessed against existing controls and documented in the plan. Record a named owner for monitoring CMS updates, because a control mapped to an older ARS version can drift out of alignment without any change to the system itself.

Why a tailored baseline must be defended in writing

Under SP 800-53B, a tailored baseline is a set of decisions that each need a written justification, not a list of controls quietly dropped. Organizations do not arbitrarily remove controls from the baseline selected for their system's FIPS 199 impact level. Any control moved out of scope, replaced with an alternative, or implemented differently must rest on mission and business needs and carry an explicit, risk-based determination. For a CMS system, the baseline starts from the ARS controls that apply at the High, Moderate or Low level, and the business owner who evaluates the ARS and implements the controls is the person who must be able to explain each departure from that starting point.

The standard also requires that every control in the selected baseline is accounted for. In practice, that means each ARS control in the baseline has a recorded status: implemented, implemented by inheritance, implemented with a documented alternative, or deliberately tailored out with its rationale. The assessor under SP 800-53A will look for that complete accounting first, then check that the stated reasons match the system's real architecture and data. Documentation is expected in the system security and privacy plan, so the justification should live there, versioned alongside the control implementation statements. Confirm with your CMS system owner and security office which documentation templates and approval steps apply to your system.

Weak documentation is easy to recognize. Typical signs include tailoring rationales that say only "not applicable" or "low risk" with no reference to the system's boundary, data types or mission function; controls marked as inherited with no named provider or agreement; and removals made after the assessment began with no change record. Illustrative example: a moderate system that marks a control as not applicable because it has no mobile devices, while its administrators use mobile management apps, will fail review on the first interview. Before the assessment, have someone outside the implementation team test each tailoring decision against the boundary diagram and the data inventory, and treat any decision that cannot be traced to evidence as open.

What usually delays ARS work and how to avoid it

Most delays in ARS work start before any control is tested. The pitfalls below cluster around scoping, ownership and documentation, and each one is easier to fix at the start of a program than during an assessment. Check these points before you commit to a schedule.

Miscategorized information types

The FIPS 199 categorization sets the baseline, so an information type rated too low leaves required controls out of scope. Each information type needs its own confidentiality, integrity and availability impact values, and the system takes the high water mark across all of them. Under SP 800-53B, a single high impact value moves the whole system to the high baseline. Re-check the categorization with the business owner whenever a new data type is added.

Unclear inheritance from the hosting environment

Controls that the hosting platform provides can be claimed once, but only if the boundary between the platform and the system is written down. Without that line, teams either duplicate evidence or assume a control is covered when it is not. For each control, record whether it is inherited, shared or system-owned, and name the party that produces its evidence. Confirm inheritance claims against the provider's own documentation.

Stale control text after an ARS revision

ARS 5.2 carries a record of changes dated July 1, 2026, and the CMS change log keeps its controls aligned with SP 800-53 Rev. 5 control statements. A system documented against an older ARS version may test against wording that no longer applies. Map each control to its current ARS entry and compare it with the change log before evidence is collected. Assign an owner to track future revisions.

Missing rationale for tailoring

SP 800-53B does not allow controls to be removed from a baseline without a defensible reason. Each tailoring decision needs an explicit, risk-based justification tied to mission and business needs. Every control in the selected baseline must be accounted for, either implemented or tailored with documented reasoning. Record each decision in the system security and privacy plan so an assessor can trace it without a meeting.

Evidence gathered without a mapped control

Screenshots, scan exports and policy documents collected without a control reference rarely satisfy an assessor, because the assessor must see which requirement each artifact supports. Build a control-to-evidence matrix before collection starts, and name the owner, source system and collection date for each item. Use the SP 800-53A assessment methods to plan what examine, interview and test steps will need to be shown. Keep the matrix under version control with the plan.

Unassigned implementation responsibility

CMS states that business owners are primarily responsible for evaluating the ARS and implementing its controls, and that contractors and sub-contractors supporting CMS missions must observe the baseline policy statements. Work stalls when no one knows whether the owner, the contractor or the platform team holds a given control. Assign each control to a named role in the system plan, and confirm contractor obligations in the contract before work begins.

Questions about CMS ARS and NIST 800-53

Is CMS ARS the same as NIST SP 800-53?

No, but they are closely linked. The CMS Acceptable Risk Safeguards (ARS) is CMS's own control set, and its controls correlate directly to SP 800-53 numbering, such as AC-1 and AC-2. CMS updated its change log in version 5.1 to match the Rev. 5 control statements, and ARS 5.2 carries a record of changes dated July 1, 2026. The ARS adds CMS-specific tailoring on top of the NIST and HHS baselines, so a system owner should work from the ARS text for CMS systems rather than assume the NIST baseline alone is enough. Check the current ARS version on the CMS security site before writing any control implementation statement.

How is the ARS baseline chosen for a CMS system?

The baseline follows the system's FIPS 199 categorization. Under FIPS 199 and FIPS 200, a system takes the high water mark across confidentiality, integrity and availability: it is low only if all three are low, moderate if at least one is moderate and none is high, and high if any one is high. The ARS makes the controls defined under the High, Moderate or Low baseline mandatory for that categorization. The system owner sets the impact levels with the business information owner, and that categorization drives everything after it. Any tailoring away from the baseline needs a documented, risk-based justification in the system security and privacy plan, and every control in the selected baseline must still be accounted for.

Who must comply with the CMS ARS?

CMS states that all CMS employees, contractors, sub-contractors and their facilities supporting CMS business missions must observe the baseline policy statements in its information security and privacy policy. Compliance therefore reaches beyond the federal workforce to any vendor that hosts, operates or supports a CMS system. Business owners carry primary responsibility for evaluating the ARS and implementing its controls for their systems. Contractors should read their contract clauses to confirm which ARS version applies, which systems are in scope and which deliverables, such as the security plan or assessment evidence, the contracting officer expects.

Can a contractor own the whole ARS control set?

A contractor can own implementation of the controls for the systems it operates, but it cannot take over accountability that belongs to the CMS business owner. Each control needs a named owner, and the system security and privacy plan must show whether a control is implemented by the contractor, inherited from a provider such as a cloud platform, or shared between parties. Physical, personnel and some governance controls often sit with the organization rather than the contractor, so the split should be written out control by control. Ask the contracting officer to confirm who owns each family before work starts, and treat any unassigned control as a gap to resolve.

What does ARS compliance ask of internal staff?

The work is mostly ongoing staff time, not a one-off project. Internal teams need to name control owners, keep policies and procedures current, run access reviews, manage change records, review logs and vulnerability scan results, and track plan of action and milestones items until they close. Staff also need to know the ARS requirements for their own role, which means training and records of that training. An organization that does not have these people in place will spend more on outside help, because consultants will still need internal owners to answer questions about how systems actually run. Plan staff time for the first authorization effort and again for each recurring assessment cycle.

Can an implementation partner issue an ARS attestation?

No. An implementation partner can prepare systems, configurations, documentation and evidence so that the organization can show how each control is met, but it cannot issue an audit report, attestation or certification. DeployOpen works this way: it prepares systems and evidence for compliance assessments, while independent assessors and the authorizing officials make the determinations. The organization owns its controls and its authorization decisions. Ask any partner to state in writing which deliverables it prepares and which findings will come from the independent assessment, and make sure the contract does not imply that the partner signs off on compliance.

What drives the cost of meeting ARS and NIST 800-53?

Cost depends mostly on scope, which means the number of systems, the impact level that sets the baseline, how many controls are inherited from a cloud or hosting provider, and how much evidence is missing today. Other drivers include the number of environments, the maturity of existing logging and vulnerability management, and whether the organization needs outside assessment support. Costs fall into one-time work, such as gap analysis, documentation and remediation, and recurring work, such as continuous monitoring, scanning, and annual assessments. NIST does not estimate compliance costs, so no industry figure applies to your case. Ask any quote to itemize these components and to state which systems, controls and assessment activities it covers.

Which parts of ARS compliance can be outsourced?

Several parts can be handed to an implementation partner, including platform build and hardening, configuration baselines, logging and monitoring setup, evidence collection tooling, documentation drafts, and remediation of technical findings. Security testing can also be contracted separately. Governance decisions, risk acceptance, control ownership and authorization decisions cannot be outsourced, because they belong to the organization and its authorizing officials. Independent assessment must come from an independent assessor. Divide the work into these three groups in the statement of work so that each deliverable has a clear owner.

How DeployOpen prepares ARS systems and evidence for assessment

DeployOpen works on CMS Acceptable Risk Safeguards (ARS) and NIST 800-53 by preparing the systems, controls and evidence that an independent assessor will test. The organization keeps ownership of its controls and its authorization decisions, and DeployOpen does not issue audit reports or certifications.

How we scope

Agree the system boundary, FIPS 199 categorization and ARS baseline in writing before work starts.
Map each applicable ARS control to the system component, owner and existing evidence it depends on.
Confirm which controls the CMS business owner, a shared service or the cloud provider will supply.

How we build

Deploy and harden self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks.
Configure logging, access control, configuration baselines and vulnerability scanning so they produce auditable records.
Document tailoring decisions and their risk-based justification in the system security and privacy plan.

How we hand over

Deliver the control implementation statements, procedures and evidence mapped to ARS control identifiers.
Run internal test activity against the SP 800-53A assessment procedures and record gaps in a plan of action and milestones.
Give your assessor a documented evidence package, and confirm with them which artifacts and sampling they expect.

How we support

Engage on a fixed-scope basis, with scope, deliverables and timelines agreed in writing before work starts.
Offer ongoing support, upgrades and continuous testing as a retainer after handover.
Review evidence again when the ARS version, the system or its boundary changes, as CMS updates its record of changes.

CMS Acceptable Risk Safeguards (ARS) and NIST 800-53