One checkbox on your CMS submission decides whether 25% of your MIPS final score survives. The promoting interoperability security risk analysis measure is a yes/no attestation, and a "no" — or a "yes" you cannot defend in an audit — zeroes out the entire Promoting Interoperability performance category. There is no partial credit, no curve, and no appeal based on how good your other measures looked.

This article is for the person who has to actually produce that documentation: the practice owner, the privacy officer, the administrator who signs the attestation. It covers what the measure requires, the calendar you are working against for the CY2026 performance year, who does each step, and what an auditable file looks like when CMS or OCR asks.

What the Promoting Interoperability Security Risk Analysis Measure Actually Requires

The measure points straight back to HIPAA. To attest "yes," you must conduct or review a security risk analysis that meets the requirements at 45 CFR 164.308(a)(1)(ii)(A), implement security updates as necessary, and correct identified deficiencies. The analysis must include the security — including encryption — of electronic protected health information created or maintained by your certified EHR technology.

Two things trip up practices here. First, the analysis is not limited to the EHR. It must cover ePHI everywhere it lives in your organization: the billing clearinghouse connection, the scanner that emails PDFs to the front desk, the clinical staff member's laptop, the backup drive in the closet, the imaging vendor's portal, the text-based appointment reminder tool nobody documented.

Second, "correct identified deficiencies" is a separate obligation from finding them. A risk analysis that lists twelve findings with no remediation plan and no evidence of action is an incomplete attestation, not a completed one. HIPAA's risk management standard at 164.308(a)(1)(ii)(B) requires you to reduce risks to a reasonable and appropriate level, and CMS expects to see that loop closed.

Who Attests, and Under Which Program

MIPS eligible clinicians and groups report the Promoting Interoperability performance category through the Quality Payment Program, where it is weighted at 25% of the final score. Eligible hospitals and critical access hospitals report under the Medicare Promoting Interoperability Program through the Hospital Quality Reporting system. The security risk analysis measure appears in both, worded nearly identically, and the underlying HIPAA requirement is the same either way.

The CY2026 Calendar You Are Working Against

The Promoting Interoperability performance period is a continuous window within the calendar year — 180 days for recent program years; confirm the exact length in the final rule that applies to your reporting year. Your risk analysis timing keys off the calendar year, not the performance window.

  • Any point in CY2026: Conduct or review your security risk analysis. It may occur before, during, or after your selected performance window, as long as it falls within the same calendar year as the performance period.
  • By December 31, 2026: Finish it. Waiting until January to "complete" a CY2026 analysis creates an argument you do not want to have with an auditor.
  • January 2 – March 31, 2027: The MIPS data submission window for the CY2026 performance year. Hospitals attest on the deadline CMS publishes in HQR, generally in the first quarter.
  • Through 2033: Retain the analysis, the remediation evidence, and the supporting artifacts. CMS expects six years of supporting documentation; HIPAA requires six years from creation or last effective date, whichever is later.

If you are a small practice pursuing a Promoting Interoperability hardship exception, note the trap: the exception relieves you of the CMS attestation, not of the HIPAA risk analysis. The Security Rule applies to every covered entity regardless of MIPS status. Check the current application window on the QPP portal — it typically closes at the end of the calendar year.

Assigning Ownership Before December

Name people, not departments. A workable split for a 12-provider practice looks like this:

  1. Privacy/security officer — owns the analysis, the scope statement, the final risk register, and the sign-off date.
  2. Practice administrator — produces the asset and vendor inventory, confirms every business associate agreement is current and signed.
  3. IT contact or MSP — supplies encryption status by device, patch and backup evidence, firewall and access-log configuration, EHR audit-log settings.
  4. Clinical lead — validates workflow reality: what staff actually do with USB drives, personal phones, and the printer in the hallway.
  5. Owner or board designee — approves the remediation plan and the budget attached to it.

What Counts as a Security Risk Analysis for Promoting Interoperability?

A qualifying analysis is an organization-wide, documented assessment of risks and vulnerabilities to the confidentiality, integrity, and availability of all ePHI your practice creates, receives, maintains, or transmits — including ePHI in your certified EHR. It must identify assets and data flows, name specific threats and vulnerabilities, evaluate existing controls, assign likelihood and impact, produce a risk rating, and document remediation. A vendor security questionnaire, a penetration test, a HIPAA training certificate, or an EHR certification statement is not a risk analysis.

The Nine Elements Your File Needs

HHS guidance describes the components of a compliant risk analysis. Build your document around them so an auditor can map your file to the regulation without translation:

  • Scope — every location, system, and medium holding ePHI, including remote work and portable devices.
  • Data collection — a written inventory of where ePHI is created, received, stored, and transmitted.
  • Threats and vulnerabilities — specific and named: unpatched remote access, shared front-desk logins, unencrypted laptops, phishing exposure, vendor portal credentials that outlived the employee.
  • Current security measures — what you already have in place and whether it works as configured.
  • Likelihood of occurrence — reasoned, not decorative.
  • Potential impact — patient count, data types, operational downtime.
  • Risk level — a rating each finding can be sorted and prioritized by.
  • Documentation — dated, versioned, and signed.
  • Periodic review and update — evidence that this year's version reflects this year's environment.

The last element matters more than practices expect. A CY2026 analysis that is a find-and-replace of the CY2024 date, with the same twelve findings still open, tells an auditor the remediation obligation was never met. It also produces a documented admission that you knew about a risk for three years and did nothing.

If assembling that file from scratch is what keeps getting pushed to December, it is worth using tooling built for it. Platforms that automate HIPAA risk analysis reports and the supporting policy set get you to a dated, structured, defensible document in hours rather than pushing the entire burden onto whoever has the fewest patients scheduled that week. The free ONC/OCR Security Risk Assessment Tool is another legitimate starting point, particularly for smaller practices willing to invest the staff hours.

Three Ways Practices Fail This Measure

1. Confusing a Vendor Attestation With Your Analysis

Your EHR being certified under the ONC Health IT Certification Program says something about the software. It says nothing about your network, your staff, your physical security, or your configuration choices. No vendor can perform your organization's risk analysis for you, and no vendor certification substitutes for it.

2. Scoping to the EHR Only

The measure specifically calls out ePHI in certified EHR technology, which practices misread as a ceiling. It is a floor. Skip the fax server, the transcription vendor, or the cloud storage folder where the biller keeps spreadsheets, and your analysis is incomplete under HIPAA — which means your attestation rests on a document that does not meet the standard it cites.

3. No Signed BAA Behind an Inventoried Vendor

Your risk analysis will surface vendors touching ePHI. Every one of them needs a current business associate agreement, and gaps found during the analysis need to close before you attest. If you find an unpapered vendor in October, resolve it — a signature-ready business associate agreement is a same-week fix, not a next-year project.

The Enforcement Backdrop in 2026

OCR has been running an enforcement initiative focused specifically on the risk analysis requirement, producing a steady series of settlements against organizations that could not show they had ever completed a compliant, organization-wide analysis. The pattern is consistent: a breach report arrives, OCR asks for the risk analysis, and the entity produces a checklist, a vulnerability scan, or nothing at all.

HHS has also proposed a substantial Security Rule overhaul that would tighten expectations around asset inventories, network mapping, and periodic reassessment. Whatever its final form and timing, the direction is clear — write your analysis so it would survive under stricter rules than the ones in force today. NIST SP 800-66 Rev. 2 remains the best free reference for structuring the work, and CMS keeps current measure specifications on its Promoting Interoperability Programs pages.

Your Pre-Attestation Checklist

  • Analysis dated within CY2026 and signed by a named individual
  • Scope statement covering all ePHI, not just the EHR
  • Asset and vendor inventory attached, with BAA status per vendor
  • Risk register with ratings, owners, and target dates
  • Remediation evidence for high-rated findings — tickets, invoices, screenshots, policy revisions
  • SAFER Guides self-assessment completed and documented for the same year
  • Everything filed where you can retrieve it in 2033, not on one person's desktop

Do the analysis in September or October, not the week of the submission deadline. You need runway to fix what you find, because the promoting interoperability security risk analysis attestation certifies both that you looked and that you acted. If you want the documentation set assembled and dated before the CY2026 window closes, start your risk analysis and policy package now and spend the remaining months closing findings instead of writing the report.