Every year, I get some version of the same call. A practice manager or a compliance lead has just been told to run their annual security risk assessment, someone points them to the ONC's SRA Tool, and within ten minutes they are stuck. They are on a Mac. The installer will not run. Nobody warned them.

I have led more than 700 security risk assessments over the past two decades, for practices, health systems, and business associates across the country. A meaningful share of them started the ONC's tool on their own before they called me. Most of those did not finish it. Not because the content defeated them, but because a risk assessment done right needs the right tools, the right timing relative to audits and system changes, and someone who can read an ambiguous answer and know what it means for that organization's risk posture.

That moment tells you almost everything you need to know about where this tool sits in 2026: genuinely useful content, wrapped in architecture that has not kept pace with how healthcare organizations run today.

I recently sat through Altarum's walkthrough of SRA Tool version 3.7, along with the live Q&A that followed. Some of what I heard was reassuring. Some of it confirmed exactly the concerns I have been raising with clients for years. Here is the honest accounting, and what I think it would take to fix it.

What the Tool Still Gets Right

The content underneath the interface is solid, and it has been kept current. Every question in the seven-section assessment is mapped to a specific HIPAA Security Rule citation, along with references to NIST Cybersecurity Framework 2.0, the Health Industry Cybersecurity Practices, and the Healthcare and Public Health Cybersecurity Performance Goals. That is a real regulatory backbone, mapped to statute and framework at the question level.

Version 3.7 shows the tool is still being maintained with intent. It adds new education and reference material tied to remote access and telework, multi-site and multi-facility scope, and a modernized asset inventory that now explicitly names cloud and SaaS platforms, mobile devices, medical and OT/IoT devices, and vendor-hosted systems. That reflects where ePHI lives today, not where it lived when the tool was first built.

The tool also does something government software rarely does: it tells you its own limits. New "tool scope transparency" language reminds users that a survey-style assessment may not surface every risk in their environment and recommends supplementing it. An honest disclaimer about a compliance tool's boundaries is rarer than it should be.

One more thing deserves real credit: everything entered into the SRA Tool stays local. Nothing is transmitted to DHHS, ONC, or OCR. For a tool that collects a detailed map of an organization's assets, vendors, and security gaps, that is the right default. It also happens to be the root cause of the tool's biggest limitation, which is where the critique starts.

The Architecture Problem Nobody Has Fixed

Local-only storage means the SRA file lives on one machine. The tool does support multiple named user accounts, so more than one person can contribute to an assessment with attribution. Access, though, is sequential rather than concurrent. Altarum confirmed this directly in the Q&A: if one person is entering data and needs a second person to continue, they email or Teams-share the raw file, and the second person opens it locally to pick up where the first left off. For a solo practitioner, that is workable. For any organization running an assessment across IT, compliance, and department leadership, which is most of the organizations that need this, it is a workflow built for passing a document around, not for a team working together.

The platform story is worse. The SRA Tool for Windows runs on 64-bit Windows 7, 8, 10, and 11, and that is the whole list. The accommodation for everyone else is a separate Excel workbook, which ONC's own product page describes as intended for "users who do not have access to Microsoft Windows or otherwise need more flexibility." Read that plainly: the interactive wizard, the branching logic, the built-in reporting are the real product, and everyone outside the Windows ecosystem gets a spreadsheet instead.

Installation adds a third layer of friction. Administrative privileges are required to install the SRA Tool, which means a solo practice or a small group without dedicated IT has to find someone who can install software with elevated rights before they can even start. That collides directly with how ONC and Altarum describe the tool's own audience. The deck's own subtitle calls this "Overview for Small and Medium Practices." The tool was built to reach the people least equipped to install Windows software with admin rights, hand a file between coworkers, or stand up a Mac workaround. It asks exactly that of them anyway.

The Missing Benchmark

The most consequential gap is the one that would be easiest to fix and has gone unaddressed the longest: there is no built-in way to compare this year's assessment against last year's. Every completed SRA generates its own Summary, Risk, Detailed, and Remediation reports, but nothing in the tool tracks trend or closes the loop on whether last year's remediation happened.

Altarum confirmed this directly in the Q&A, suggesting users run prior and current exports through an outside AI tool to build that comparison themselves. That is a reasonable workaround, not a plan. A tool positioned as the reference standard for demonstrating a maturing security program to OCR should build that comparison in, rather than leave every organization to construct its own benchmarking pipeline, assuming they even retained the prior year's exports.

This is where the distinction matters most: completing the SRA Tool supports a defensible risk analysis. Demonstrating compliance, and showing real improvement year over year, are separate achievements, ones the tool was never built to track on its own.

What Modernizing This Tool Requires

None of the problems above are exotic. Every one of them was solved by commercial compliance and GRC software a decade ago. Bringing the SRA Tool forward is not a research project. It is a decision to build it like it is 2026.

The single highest-leverage fix is architectural: ship the tool as a browser application, not a Windows installer. Running it through a login rather than a downloaded executable would eliminate the Windows-only limitation, the admin-rights install barrier, and the "one laptop has the file" fragility in one move. Everything else on this list matters, but this is the fix that resolves three separate complaints at once.

From there:

  • Support Real, Concurrent Collaboration. Replace the emailed file with account-based, role-permissioned access, so IT, compliance, and an outside consultant can work the same assessment at the same time, with a visible record of who changed what. Named user accounts inside a single file were the right instinct. A shared, permissioned workspace is the finished version of that instinct.
  • Build Benchmarking Into The Reporting Engine. Every assessment should compare automatically against the prior cycle: what closed, what is still open, what is new. That is the difference between a tool that produces a report and a tool that documents a maturing security program, which is the standard OCR is evaluating against.
  • Keep The Local-Only Option, and Add An Encrypted Cloud Option Beside It. Some organizations will always want data that never leaves their premises, and that choice should stay available. Others need multi-user access and automatic version history more than they need on-premises storage. A tool built for 2026 offers both, hosted in an environment that meets the same security bar it is asking covered entities to meet.
  • Open The Data. A PDF report is built for reading, not reuse, and pulling structured findings back out means re-keying them by hand. The Excel export is more usable, but with no API and no defined schema behind it, someone still has to open the file and map it into whatever governance or vendor risk platform receives it. An API and a stable data schema would let that happen automatically instead of by hand every cycle.

The Path Forward

ONC and Altarum have already told us who this tool is for: organizations with small budgets and few staff. That framing raises the bar for the architecture. A Windows-only application that requires admin rights to install and a manual file handoff to collaborate is a reasonable ask for an enterprise with a dedicated IT department. It is a real barrier for the solo practice or small group this tool claims to serve.

The Security Rule has required an accurate and thorough risk assessment since HIPAA § 164.308(a)(1)(ii)(A) was written. The obligation has not changed. The tools available to meet it should have moved a lot further than they have.

Fixing the architecture will remove the friction that causes people to give up before they finish. A seasoned assessor's judgment in reading what the answers mean for that organization's risk is a separate skill, one software has not replaced yet. Both matter, and after more than 700 of these, I can tell you which one is harder to build into software.

It's time to bring this tool into the century it is being used in.