The Security Risk Analysis measure on your Promoting Interoperability attestation is a single yes/no box. What sits behind that box is a dated, signed document set that has to survive an OCR data request two or three years later — usually after a breach nobody saw coming.

If you're hunting for an SRA tool HIPAA regulators actually recognize, start with the free Security Risk Assessment Tool published jointly by the HHS Office for Civil Rights and the federal health IT office. It's a downloadable application aimed at small and medium practices, and it walks you through the Security Rule's risk analysis requirement question by question. This article covers who in your practice owns it, what it produces, where it stops short, and what the finished evidence file needs to contain before you check that box.

Is the SRA Tool HIPAA-Required? No. Is a Risk Analysis? Yes.

No regulation names a product. The requirement lives at 45 CFR 164.308(a)(1)(ii)(A), which obligates every covered entity and business associate to conduct "an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information" it creates, receives, maintains, or transmits.

The federal SRA Tool is one way to structure that assessment. A spreadsheet, a consultant's report, or a platform-generated document can satisfy the same requirement if it is accurate, thorough, scoped to all ePHI, and written down. HHS does not certify, endorse, or approve any compliance product — including its own tool. Running the software proves nothing by itself; producing a defensible analysis and acting on it does.

Two separate obligations follow. The analysis under 164.308(a)(1)(ii)(A), and risk management under 164.308(a)(1)(ii)(B) — implementing measures sufficient to reduce the identified risks to a reasonable and appropriate level. Practices routinely complete the first and skip the second. That gap is what turns a completed assessment into a finding.

Who Owns This in a 12-Person Practice

Name the roles before you download anything. An assessment with no named owner drifts for six months and then gets completed in a panic the week before attestation.

Security Officer — owns the file

Your designated Security Official under 164.308(a)(2) runs the sessions, records answers, and signs the final report. In most independent practices this is the practice administrator or office manager, not the IT vendor. If your policy manual names someone who left in 2023, fix that first.

IT vendor or MSP — supplies the technical facts

They provide the device inventory, encryption status per endpoint, backup schedule and last successful restore test, firewall and patching posture, and the list of accounts with administrative rights. Send them the questions in writing and keep the reply. Their email becomes evidence.

Practice owner or managing physician — approves and funds

Someone with budget authority has to sign the remediation plan. A risk labeled "high" with no funded fix and no target date reads worse in an investigation than a risk you never identified.

Front-desk and clinical leads — describe reality

They tell you what actually happens: the shared login at the check-in station, the personal phone used to photograph a wound, the fax cover sheet nobody reads, the laptop that goes home on Fridays. Written policy is not the input here. Observed workflow is.

What the SRA Tool HIPAA Workflow Actually Walks You Through

Download the current version directly from the federal Security Risk Assessment Tool page. There's a Windows desktop application and a spreadsheet workbook for practices on Mac or Linux. Both are free, and neither transmits your answers anywhere — the file lives on your machine, which means you are responsible for backing it up and controlling who can open it.

Recent versions move through a series of content sections covering the basics of your practice, policies and documentation, workforce security, data handling, physical security, vendors and business associates, and contingency planning. Each section pairs multiple-choice questions with plain-language explanations of the underlying Security Rule citation and references to related NIST controls.

The asset inventory step nobody wants to do

The tool asks you to enumerate every device and system that touches ePHI. This is the step that gets skipped, and it's the step that makes the whole analysis credible. You cannot assess risk to data you haven't located.

For a small practice, the honest inventory is longer than expected: workstations, laptops, tablets, the server or cloud EHR connection, the backup appliance, the imaging modality with an embedded Windows install, the copier hard drive, the cloud fax service, the phone system with voicemail transcription, the practice's email accounts, personal phones with the scheduling app installed, and any USB drive that has ever held a patient export.

Vendor inventory and the BAA cross-check

The vendor section asks who receives, stores, or transmits your ePHI. Run the list against your executed Business Associate Agreements. Every practice I've reviewed finds at least one vendor with access and no signed agreement — usually a transcription service, an answering service, a marketing firm with CRM access, or an IT contractor who was hired before anyone thought about it.

Close those gaps as you find them. If you need to paper a relationship quickly, a six-step Business Associate Agreement wizard will produce a signature-ready PDF or DOCX the same afternoon, which is faster than waiting three weeks for a vendor's legal team to send their version.

Where the Free Tool Stops and Your Work Begins

The tool generates a summary report with risk ratings by area. That report is an input to your risk analysis. It is not, on its own, the complete documentation an investigator expects.

Three things it will not do for you:

  • It won't verify your answers. If you click "yes, all laptops are encrypted" without checking, the report says your laptops are encrypted. OCR checks.
  • It won't write your remediation plan. You have to convert each identified risk into a task with an owner, a target date, and a completion record.
  • It won't produce your policies. The Security Rule requires written policies and procedures under 164.316, retained six years. The assessment identifies which ones you're missing; it doesn't draft them.

That last gap is where most practices stall. You finish the assessment in October, discover you're missing eleven policies and a sanctions procedure, and the file sits untouched until next year's attestation deadline. If that's the pattern in your office, a platform that generates the risk analysis report and the matching policy set from one intake collapses the gap between finding a problem and having documentation that addresses it. The analysis and the remediation artifacts come out of the same workflow instead of two separate projects nine months apart.

The Evidence File an Investigator Will Ask For

When OCR opens a compliance review after a breach report, the risk analysis request arrives early. Assemble the folder now so you're not reconstructing it under a 30-day response deadline.

  1. The completed assessment — exported as PDF, with the completion date visible and the assessor named.
  2. The asset inventory as of the assessment date, including which assets hold or transmit ePHI.
  3. The vendor list mapped to executed BAAs, with effective dates.
  4. The risk management plan — each identified risk, the rating, the chosen mitigation, the responsible person, the target date.
  5. Evidence of completed remediation — encryption reports, MFA rollout confirmations, training rosters with signatures, restore test results.
  6. Approval signature from the practice owner or governing body, dated.
  7. Prior years' analyses, retained at least six years, so the reviewer can see the trend.

HHS's own guidance on risk analysis spells out the required elements: scope, data collection, identification of threats and vulnerabilities, assessment of current security measures, likelihood and impact determination, risk level assignment, and documentation. Structure your file to mirror those headings and the reviewer's job becomes easy — which is exactly what you want.

A Six-Week Schedule That Actually Finishes

Blocking two hours a week beats scheduling one eight-hour day that gets cancelled. Here's a schedule that works for a practice of roughly ten to twenty staff:

Week 1: Confirm your Security Officer designation in writing. Download the tool. Email the IT vendor the technical questionnaire with a two-week deadline.

Week 2: Build the asset inventory. Walk every room. Open the closet with the old server in it.

Week 3: Build the vendor list from your accounts payable ledger — not from memory. Pull every BAA and note the missing ones.

Week 4: Work through the policy, workforce, and data sections with the IT responses in hand.

Week 5: Complete physical security and contingency planning. Verify your last backup restore test; if there isn't one, that's a finding, and you write it down as a finding.

Week 6: Export the report. Convert every gap into a dated task. Owner signs. File the package and calendar the next review.

Three Mistakes That Turn a Finished Assessment Into a Finding

Scoping it to the EHR only

Your EHR vendor's SOC 2 report covers their infrastructure, not your practice. ePHI also lives in email, in text messages between clinicians, on the imaging workstation, in the billing clearinghouse portal, and in the spreadsheet someone built for recall outreach. Scope to the data, not the software.

Treating it as an annual checkbox

The Security Rule requires periodic review and update — and material change is the real trigger. New location, new EHR, a merger, a shift to remote scheduling staff, a ransomware scare, a new remote-access tool: each one warrants an update memo appended to the file. Dated memos between full assessments show continuous compliance far better than one annual PDF.

Identifying risks and funding nothing

OCR launched a focused enforcement initiative on the risk analysis requirement, and the resolutions that have followed share a pattern: entities that suffered a hacking or ransomware incident and could not produce evidence of a compliant, current analysis. A documented high risk with no mitigation and no target date is a written admission. Either fund the fix, or document the specific compensating control and the business rationale — in writing, signed.

Aligning With NIST Without Hiring a Consultant

If you want more structure than the free tool provides, NIST publishes a resource guide for implementing the HIPAA Security Rule — SP 800-66 Revision 2. It's not a mandate, and you don't need to adopt it wholesale. Use its risk assessment tables to sanity-check your likelihood and impact ratings, and use its mapping to standard security controls when your cyber liability carrier asks what framework you follow.

Note also that HHS proposed significant updates to the Security Rule in a January 2025 rulemaking, including a mandatory asset inventory and network map, tighter encryption expectations, and removal of the addressable/required distinction. Whatever the final form, the direction is clear: written inventories and verified controls, not attestations of good intent. Building those artifacts now is not wasted effort.

Your Next Step

Pick a date this week, name the Security Officer in writing, and start the asset inventory. If assembling the full document set — analysis, risk management plan, and the policy library that has to back it up — is what keeps stalling, generate your HIPAA risk analysis and supporting policy documents in one pass and spend your hours on remediation instead of formatting. The attestation box takes a second to check. The file behind it is what you're actually building.