If your organization builds, operates, or connects to a system that touches Medicare, Medicaid, or CHIP data, the CMS cybersecurity requirements you have to meet come from several layers stacked on top of each other: HIPAA and HITECH set the health-data floor, FISMA and NIST set the federal-system floor, and CMS layers its own Acceptable Risk Safeguards (or MARS-E for exchanges) on top. Cloud services add FedRAMP. Miss any of it and you face civil penalties reaching $2,190,294 per violation category per year, criminal exposure up to ten years, and loss of authorization to connect at all.
The Rules That Apply to You
Two federal statutes do most of the work.
HIPAA is the starting point. The Privacy Rule limits how protected health information can be used or disclosed and enforces a minimum-necessary standard on sharing. The Security Rule, which governs electronic PHI, requires administrative, physical, and technical safeguards to protect confidentiality and integrity. The HITECH Act of 2009 extended those obligations, and the civil and criminal liability that comes with them, to business associates: the vendors and contractors handling PHI on behalf of a covered entity.1U.S. Department of Health and Human Services. Summary of the HIPAA Security Rule For anyone in the CMS contracting chain, that matters: HITECH is why a subcontractor two steps removed from CMS still carries the same statutory duties.
The Federal Information Security Modernization Act (FISMA) is the other pillar. FISMA requires every federal agency to run an agency-wide information security program covering all systems and data, report status to the Office of Management and Budget, and undergo annual independent assessment by an inspector general.2CMS Information Security and Privacy Program. Federal Information Security Modernization Act3CIO.GOV. Federal Information Security Modernization Act (FISMA) To satisfy FISMA, CMS systems follow National Institute of Standards and Technology (NIST) standards, specifically the security controls catalog in NIST SP 800-53 selected through the NIST Risk Management Framework.4National Institute of Standards and Technology. NIST Risk Management Framework
CMS-Specific Baselines: ARS and MARS-E
CMS doesn’t stop at the NIST catalog. It publishes its own tailored baseline.
The CMS Acceptable Risk Safeguards (ARS) define the minimum security and privacy controls every CMS-connected system must implement. ARS controls map to the NIST SP 800-53 families but add CMS-specific parameters and supplemental controls where the agency’s risk profile is higher than the federal floor. Business owners can tailor certain controls to their mission, but the baseline itself is mandatory. The 20 control families cover access management, audit logging, incident response, supply chain risk, and more. A system that doesn’t meet the ARS baseline won’t get, or keep, authorization to connect to CMS infrastructure. Every stakeholder is covered: contractors, state agencies, business associates.5Centers for Medicare & Medicaid Services. CMS Acceptable Risk Safeguards (ARS)
If you’re a state-based health insurance exchange, a state Medicaid or CHIP agency, or an entity administering the Basic Health Program, your controlling standard is MARS-E, the Minimum Acceptable Risk Standards for Exchanges. MARS-E addresses the security and privacy mandates of the Affordable Care Act at 45 CFR 155.260 and 155.280. It shares the ARS foundation (NIST SP 800-53) and incorporates FedRAMP guidance for cloud-based systems.6Centers for Medicare & Medicaid Services. MARS-E Volume I: Harmonized Security and Privacy Framework v 2.2 Connecting to the federal data hub means meeting MARS-E.
Getting and Keeping Authority to Operate
No CMS system goes live without an Authority to Operate (ATO). An independent assessor reviews the security plan, examines documentation, interviews stakeholders, and runs technical tests including vulnerability scans and penetration testing. Assessment results must be delivered within 30 days of completion, documented in a Security Assessment Report.7CMS Information Security and Privacy Program. RMH Chapter 4: Security Assessment and Authorization
Traditional ATOs expired every three years. CMS has been shifting to an Ongoing Authorization (OA) model that swaps periodic re-authorization for continuous monitoring, using automated feeds from the CMS Continuous Diagnostics and Mitigation program and the Cybersecurity Integration Center. A system that stays compliant across the OA metrics keeps operating without manual re-approval.8CMS Information Security and Privacy Program. Ongoing Authorization (OA)
Slip on any one of the five OA metrics and the system owner and information system security officer get a 30-day grace period to fix it. Miss that window, and the system is dropped from OA and placed on a one-year traditional ATO with a remediation list attached.8CMS Information Security and Privacy Program. Ongoing Authorization (OA)
Cloud Systems and FedRAMP
Cloud services holding federal data must be authorized through the Federal Risk and Authorization Management Program (FedRAMP) at the appropriate impact level before they can connect to CMS systems.9CMS Information Security and Privacy Program. Federal Risk and Authorization Management Program (FedRAMP) FedRAMP has three levels:
- Low, for systems with no sensitive personally identifiable information.
- Moderate, for systems where a breach could cause serious harm to agency operations, finances, or individuals.
- High, for health systems, financial systems, and other environments where compromise could be severe or catastrophic, including threats to life.
Because CMS systems handle health and financial data, most CMS cloud deployments land at Moderate or High. One narrow exception: a private cloud operated solely for CMS use, implemented within a managed CMS general services system, and not providing services to external entities, can run without a separate FedRAMP authorization.9CMS Information Security and Privacy Program. Federal Risk and Authorization Management Program (FedRAMP)
API and Interoperability Obligations
The CMS Interoperability and Prior Authorization final rule (CMS-0057-F) requires impacted payers to stand up APIs built on the HL7 Fast Healthcare Interoperability Resources (FHIR) standard by January 1, 2027.10Centers for Medicare & Medicaid Services. CMS Interoperability and Prior Authorization Final Rule Each API endpoint is a new surface to secure.
The 21st Century Cures Act prohibits information blocking but carves out a security exception. Restricting access to electronic health information isn’t information blocking if the practice is directly related to safeguarding confidentiality, integrity, and availability; tailored to specific security risks; and implemented consistently and without discrimination.11HealthIT.gov. Information Blocking Exceptions Fact Sheet Additional exceptions cover situations where sharing could cause patient harm, where privacy laws prohibit disclosure, or where fulfilling the request is technically infeasible.
Breach Notification Deadlines
When unsecured PHI is breached, the clock starts. A business associate must notify the covered entity without unreasonable delay and no later than 60 calendar days after discovery.12eCFR. 45 CFR 164.410 – Notification by a Business Associate The covered entity then notifies affected individuals, HHS, and, in larger breaches, the media.
Size determines the reporting pattern:
- 500 or more individuals affected: notify HHS at the same time as affected individuals, and alert prominent media outlets serving the relevant state or jurisdiction.13eCFR. 45 CFR 164.408 – Notification to the Secretary
- Fewer than 500 individuals affected: log the breach and report it to HHS within 60 days after the end of the calendar year in which it was discovered.13eCFR. 45 CFR 164.408 – Notification to the Secretary
Individual notifications go out without unreasonable delay and no later than 60 days after discovery, and must describe the breach, the types of information involved, mitigation steps, and contact information.14U.S. Department of Health and Human Services. Breach Notification Rule
Penalties for Getting It Wrong
The HHS Office for Civil Rights (OCR) enforces HIPAA’s privacy and security requirements. Civil penalties are adjusted for inflation annually. The 2026 figures, effective January 28, 2026, use a four-tier structure keyed to culpability:15GovInfo. Federal Register, Volume 91 Issue 18 – 2026 Civil Monetary Penalties Inflation Adjustment
- Tier 1, did not know: $145 to $73,011 per violation, calendar-year cap of $2,190,294.
- Tier 2, reasonable cause: $1,461 to $73,011 per violation, same annual cap.
- Tier 3, willful neglect corrected within 30 days: $14,602 to $73,011 per violation, same annual cap.
- Tier 4, willful neglect not timely corrected: $73,011 to $2,190,294 per violation, with the same $2,190,294 annual cap.
Per-violation math adds up quickly when a single deficiency touches thousands of records. Beyond fines, OCR typically requires a corrective action plan addressing every compliance gap identified in the investigation.16U.S. Department of Health and Human Services. How OCR Enforces the HIPAA Privacy and Security Rules
Criminal conduct is referred by OCR to the Department of Justice.17U.S. Department of Health and Human Services. Enforcement Process Under 42 U.S.C. 1320d-6:
- Knowingly obtaining or disclosing PHI in violation of the Privacy Rule: fines up to $50,000 and up to one year in prison.
- Violations under false pretenses: fines up to $100,000 and up to five years in prison.
- Violations committed with intent to sell, transfer, or use the data for commercial advantage, personal gain, or malicious harm: fines up to $250,000 and up to ten years in prison.18Office of the Law Revision Counsel. 42 U.S. Code 1320d-6 – Wrongful Disclosure of Individually Identifiable Health Information
What’s Changing: The Proposed Security Rule Overhaul
On December 27, 2024, OCR published a Notice of Proposed Rulemaking that would be the most significant update to the HIPAA Security Rule since its adoption. As of mid-2025, the current Security Rule remains in effect while rulemaking continues.19U.S. Department of Health and Human Services. HIPAA Security Rule Notice of Proposed Rulemaking Fact Sheet
The biggest shift is structural. The proposal would eliminate the distinction between “required” and “addressable” implementation specifications. Under today’s rule, an organization can decide that a safeguard like encryption isn’t “reasonable and appropriate” for its environment, document that judgment, and implement an alternative. The proposed rule would make virtually all specifications mandatory with only limited exceptions, and encryption of ePHI at rest and in transit would be an explicit requirement rather than something you can assess your way out of.20Federal Register. HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information
Other significant proposals: multi-factor authentication for access to ePHI systems, with a 180-day compliance window after any final rule takes effect; a technology asset inventory and network map updated at least every 12 months; written incident response plans with mandatory testing; the ability to restore critical systems within 72 hours of a loss; annual compliance audits; and a requirement that business associates verify and certify their technical safeguards to covered entities every 12 months.19U.S. Department of Health and Human Services. HIPAA Security Rule Notice of Proposed Rulemaking Fact Sheet
For CMS contractors and partners already operating under the ARS, many of these controls are effectively in place. The heavier lift, if the rule finalizes near its proposed form, is the documentation and certification overhead.