CMS Promoting Interoperability and the Security Risk Analysis Attestation

The program name has changed three times

What started as Meaningful Use under the HITECH Act became the Medicare and Medicaid EHR Incentive Programs, then the Promoting Interoperability Programs, and now (for eligible clinicians) the Promoting Interoperability performance category of the Merit-based Incentive Payment System (MIPS). For eligible hospitals and critical access hospitals it remains the Medicare Promoting Interoperability Program.

Across all of those names, one measure has carried through unchanged in spirit: the Security Risk Analysis measure.

What the SRA measure requires

The CMS Security Risk Analysis tipsheet describes the measure. Eligible clinicians and eligible hospitals must:

Conduct or review a security risk analysis in accordance with the requirements in 45 CFR 164.308(a)(1), including addressing the security (to include encryption) of ePHI created or maintained by certified electronic health record technology (CEHRT) in accordance with requirements under 45 CFR 164.312(a)(2)(iv) and 45 CFR 164.306(d)(3), and implement security updates as necessary and correct identified security deficiencies as part of the provider's risk management process.

In plain English: each reporting period, conduct or review a Security Risk Analysis covering all ePHI in the practice (not just the CEHRT-resident data) and address encryption decisions. Then act on the findings as part of the risk management process.

Each reporting period means each year for most filers

The Promoting Interoperability reporting period for most filers is a calendar year (or a defined 90-day or 180-day window depending on the program track in a given year — check the current year's CMS specifications). The SRA measure must be satisfied for that reporting period.

A practice that conducted an SRA in 2024 and attests for 2025 has not satisfied the measure for 2025 by pointing to the 2024 document. The "or review" language allows for a refresh rather than a from-scratch redo, but the refresh has to be conducted during the relevant reporting period and dated accordingly.

What the attestation actually says

The attestation is a yes/no on having conducted or reviewed the SRA, plus a date. There is no upload of the analysis itself at attestation time. CMS does not see the document until an audit.

The practice's responsibility is to retain the document so it is available if CMS audits the attestation. CMS audit selection runs on a sampling basis. Audits typically request:

• The dated risk analysis itself
• Evidence of risk management actions taken during the reporting period
• Documentation of encryption decisions under 164.312(a)(2)(iv)(2)(iv))
• Evidence of how the practice addressed identified deficiencies

What CMS does in an audit

CMS conducts pre-payment and post-payment audits through contractors. The post-payment process generally allows several years for review. A failed audit results in recoupment of incentive payments and (for MIPS) potential adjustment of payment.

The CMS Promoting Interoperability audit page describes the process. For the SRA measure specifically the most common audit findings are:

• Risk analysis not conducted during the reporting period
• Risk analysis missing required elements (no documented encryption decision, no risk management actions)
• Risk analysis not signed or dated

These are the same gaps OCR finds. The CMS and OCR records reinforce each other.

Scope: all ePHI, not just CEHRT

A common audit failure is a SRA that covers only the EHR data and ignores the rest of the practice's ePHI (laptops, removable media, email, RCM, billing service, telehealth, RPM). The CMS measure explicitly references all ePHI created or maintained by certified EHR technology, but the underlying HIPAA Security Rule risk analysis at 164.308(a)(1)(ii)(A)(1)(ii)(A)) covers all ePHI the covered entity holds. CMS auditors expect the SRA to cover the full scope.

Encryption specifically

The SRA measure singles out encryption. The risk analysis must include a documented decision on encryption of ePHI at rest and in transit under 164.312(a)(2)(iv)(2)(iv)) and 164.312(e)(2)(ii)(2)(ii)). A risk analysis that says nothing about encryption fails the measure even if the practice is in fact encrypted.

What is "implementing security updates as necessary"

The third part of the measure asks the practice to act on the findings. This is the Security Rule's risk management standard at 164.308(a)(1)(ii)(B)(1)(ii)(B)). Auditors look for evidence of remediation work tied to the analysis findings — closed items in a risk register, training events, policy updates, technical deployments.

A defensible SRA-for-attestation package

A practice attesting to the SRA measure should have, by the end of the reporting period:

• A dated risk analysis covering the reporting period
• A risk management plan with items addressed during the year
• Encryption decisions documented under the relevant Security Rule sections
• Signature by the Security Official
• Retention plan for at least six years per 164.316(b)(2)(i)(2)(i))

That document set covers both the CMS audit and an OCR audit, which is the practical economy: one binder, multiple audiences.

Restraint about claims

Conducting an SRA is one part of the broader compliance program. It does not certify the practice. It satisfies the CMS measure when conducted within the reporting period and retained for audit, but the measure is not a compliance certification.

How D3rx fits

D3rx SRA Binder Studio produces a dated, source-cited SRA aligned to the CMS Promoting Interoperability measure language and the underlying 164.308(a)(1)(1)) requirements, including explicit encryption decisions and a risk management plan. It is a point-in-time administrative documentation aid; the practice remains responsible for the substance and for any CMS attestation.

Next steps

See where your practice currently stands with the free 5-question readiness check, or review the full workflow and pricing on the main SRA page.