One yes/no question decides whether your practice earns 25 points or zero. The security risk analysis MIPS measure sits inside the Promoting Interoperability performance category, and answering "no" — or answering "yes" without the paperwork behind it — zeroes out the entire category. For a group already hovering near the performance threshold, that single toggle is the difference between a positive payment adjustment and a negative one two years down the road.

This is a working guide for the person who actually has to produce the document: the practice administrator, privacy officer, or compliance lead. It covers what CMS requires, the deadline that governs it, who owns each step, and what the evidence file looks like when a data validation auditor asks for it.

The Security Risk Analysis MIPS Measure Is Pass/Fail, Not Partial Credit

Promoting Interoperability is worth 25% of the MIPS final score. Most measures in that category are scored on a numerator/denominator basis — you get points proportional to performance. The security risk analysis measure does not work that way.

It is a required attestation. You answer yes or no. A "yes" earns zero bonus points; it simply keeps the category alive. A "no" — or a failure to attest at all — results in a score of zero for all of Promoting Interoperability. Twenty-five points gone.

The measure language tracks the HIPAA Security Rule directly. You must conduct or review a security risk analysis in accordance with 45 CFR 164.308(a)(1), including addressing the security — encryption included — of electronic protected health information created or maintained by your certified EHR technology (CEHRT). You must also implement security updates as necessary and correct identified deficiencies as part of your risk management process.

That last clause matters more than most practices realize. The measure is not satisfied by producing a risk analysis and filing it. It is satisfied by producing a risk analysis and acting on what it found.

The Attestations That Travel With It

The security risk analysis is one of several required attestations in Promoting Interoperability. You will also attest to the High Priority Practices SAFER Guide self-assessment, and to the Prevention of Information Blocking statements and the ONC Direct Review attestation. Each has its own documentation trail. Do not let a clean risk analysis file distract you from the SAFER Guide self-assessment, which requires its own completed worksheet dated inside the performance year.

When Does the Security Risk Analysis Have to Be Completed for MIPS?

Conduct or review the security risk analysis during the calendar year of the performance period. For the 2026 performance year, that means the analysis must be conducted or reviewed at some point between January 1, 2026 and December 31, 2026. Corrective actions identified by the analysis should be underway or complete before you attest. Data submission for the 2026 performance year opens in January 2027 and closes March 31, 2027, and the resulting payment adjustment applies to Medicare Part B claims in 2028.

A risk analysis dated November 2025 does not support a 2026 attestation. Neither does one dated February 2027, even if you complete it before the submission deadline. Verify the exact language against the current-year measure specification sheet in the CMS Quality Payment Program resource library before you sign anything — CMS refreshes these specifications annually.

CEHRT Is the Floor. Your HIPAA Obligation Is the Ceiling.

The MIPS measure asks about ePHI "created or maintained by CEHRT." Read literally, that is a narrower scope than the Security Rule requires. Read practically, it is a trap.

The Security Rule at 164.308(a)(1)(ii)(A) requires an accurate and thorough assessment of risks to all ePHI your practice creates, receives, maintains, or transmits. That includes the scanner in the back office, the billing clearinghouse portal, the imaging drive, the front desk workstation, staff phones with the scheduling app installed, the recall texting tool your marketing coordinator signed up for, and the laptop your billing contractor takes home.

If you scope your analysis to the EHR alone, you may technically satisfy the attestation and still be sitting on an unaddressed Security Rule violation. OCR has been explicit for years that an incomplete-scope risk analysis is not a risk analysis. Build one analysis that covers everything, then map the CEHRT-specific findings to your MIPS file. You do the work once.

Start With an Asset Inventory You Can Defend

Every risk analysis that falls apart under scrutiny fails at the same place: nobody can prove the inventory was complete. Before you rate a single risk, produce a written list of every system, device, application, and physical location where ePHI lives or moves. Include the data flows between them and the vendors who touch them.

Date the inventory. Name the person who compiled it. Note what was excluded and why. An auditor reading a risk analysis with no inventory behind it has no way to judge whether the assessment was thorough, and neither do you.

A Nine-Step Workflow With Owners and Dates

Here is the sequence that produces a defensible file for a small-to-midsize practice. Assign a name to each step, not a department.

  1. Designate the owner. Your Security Official under 164.308(a)(2). One named person. Document the designation in writing.
  2. Build or refresh the asset and vendor inventory. Practice administrator plus IT. Two to five business days for most practices.
  3. Confirm your CEHRT edition and certification ID. Pull the CMS EHR Certification ID from the certified health IT product list. You need it for submission anyway.
  4. Identify threats and vulnerabilities per asset. Ransomware, insider misuse, lost devices, misconfigured cloud storage, unpatched firmware, vendor breach, physical theft.
  5. Rate likelihood and impact. Use a consistent scale and write down what each level means. "High" with no definition is not a rating.
  6. Document existing safeguards. Encryption at rest and in transit, MFA, audit logging, role-based access, backup and restore testing, workforce training completion.
  7. Produce the risk register. Each finding gets a risk level, a remediation action, an owner, and a target date.
  8. Execute remediation and log it. Patch dates, configuration screenshots, policy revisions, training rosters. This is your risk management step, and CMS asks about it explicitly.
  9. Sign, date, and retain. Security Official signature plus practice owner acknowledgment.

Most practices that treat this as a real project finish in three to six weeks. Most practices that treat it as a form finish in an afternoon and cannot defend it eighteen months later.

If step seven is where you always stall — and for practices without a dedicated compliance staffer, it usually is — a platform that generates the risk analysis report, risk register, and matching policy set from your actual environment removes the blank-page problem and gives you a consistently formatted artifact to sign each year. What matters is that the output reflects your systems, your vendors, and your remediation decisions, not a generic template.

What the Evidence File Looks Like in a CMS Data Validation Audit

CMS conducts data validation and audits on MIPS submissions. If yours is selected, you supply documentation supporting every attestation. Retain your MIPS documentation for six years from the end of the performance period or the date of submission, whichever is later. That six-year window happens to match the HIPAA documentation retention requirement at 164.316(b)(2), so keep one archive.

Your security risk analysis MIPS folder should contain:

  • The completed risk analysis report, dated inside the performance year, with the assessor named
  • The asset and data-flow inventory it was built on
  • The risk register with severity ratings, remediation owners, and target dates
  • Evidence of completed remediation — ticket numbers, invoices, patch logs, revised policies with effective dates
  • Your CMS EHR Certification ID and the CEHRT version in use during the performance period
  • The High Priority Practices SAFER Guide self-assessment, separately dated
  • Screenshots or a report from your submission confirming the attestation as filed

Name the folder by performance year. When the request arrives fourteen months after submission, the administrator who handles it may not be the one who built the file.

Four Ways Practices Actually Fail This Measure

The vendor questionnaire substitute. Your IT managed service provider runs a network scan and emails a two-page "security assessment." That is a vulnerability scan, not a risk analysis. It does not address administrative or physical safeguards, workforce access, or business associates.

The rollover date. A six-clinician orthopedic group completed a thorough analysis in September 2024, changed the date on the cover page to 2026, and attested. No new inventory, no reassessment after they added a remote scheduling service. If the underlying content is unchanged, the review did not happen.

Findings with no follow-through. The analysis flags unencrypted laptops as high risk. Nothing changes. The measure requires correcting identified deficiencies as part of risk management, and an unremediated high-risk finding sitting in your own document is the strongest evidence against you.

Scope that stops at the EHR. The practice assessed the EHR and skipped the standalone billing system, the fax server, and the three cloud tools the office manager expensed. The attestation may pass; the Security Rule obligation does not.

Your Business Associates Are Part of the Analysis

Every vendor that creates, receives, maintains, or transmits ePHI on your behalf belongs in the risk analysis as a risk vector — and needs a current, signed business associate agreement on file. Auditors and OCR investigators ask for the vendor list and the corresponding agreements together.

If your inventory surfaces a vendor with no executed agreement, close that gap before you attest. A signature-ready business associate agreement takes minutes to produce and is far cheaper than explaining its absence during a breach investigation.

Passing MIPS Does Not End at the Attestation

OCR has run a dedicated enforcement initiative focused specifically on failures to conduct a compliant risk analysis, and risk analysis deficiencies remain among the most frequently cited findings in its resolution agreements. The MIPS attestation and the Security Rule obligation are the same underlying work — but OCR's scope is broader and its consequences are not measured in payment adjustment points.

Two resources are worth your time. The SRA Tool from HHS and ONC is free, downloadable, and structured around the Security Rule standards — reasonable for a solo or small practice with a simple environment. NIST Special Publication 800-66 Revision 2 maps Security Rule requirements to concrete cybersecurity practices and is the reference an auditor will recognize.

Note also that even if your Promoting Interoperability category is reweighted — small practices and certain clinician types may qualify — the HIPAA risk analysis requirement does not go away. Reweighting excuses the attestation, not the obligation.

Do This Before December 31

Pull last year's risk analysis today and check three things: the date, the asset inventory, and whether the remediation items closed. If any of the three is stale, you have four months to fix it before the 2026 performance year ends.

If you would rather not rebuild the document set from scratch, generate your risk analysis, risk register, and supporting policies in one pass, sign them, and file the package where the next administrator can find it. Then put a recurring calendar reminder for next September so this never becomes a December problem again.