When the Office for Civil Rights opens an investigation after a breach report, the data request letter is short and predictable. Near the top: a copy of your most recent risk analysis, including the date it was completed and the risk management plan adopted in response. Not your policy binder. Not your training sign-in sheets. The risk analysis. If your practice cannot produce a dated, scoped, signed HIPAA security risk assessment, the investigation stops being about the lost laptop and starts being about your entire security program.

This is the explainer for the person who has to actually produce that document — the practice owner, the designated security official, the office manager wearing three hats. It covers what the rule requires, who does each piece, what the finished evidence package looks like, and the specific gaps that turn a good-faith effort into a finding.

What 164.308(a)(1)(ii)(A) Actually Obligates You to Do

The Security Rule's administrative safeguards open with the Security Management Process standard. Its first required implementation specification — required, not addressable — is risk analysis: conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by your organization.

Three words in that sentence do most of the work. Accurate means it reflects your actual environment, not a generic template. Thorough means all ePHI, everywhere it lives, not just the EHR. And held by means the ePHI on the copier hard drive, in the billing contractor's portal, on the physician's personal phone, and in the cloud backup you forgot you were paying for.

The very next specification, 164.308(a)(1)(ii)(B), is risk management — reducing the risks you identified to a reasonable and appropriate level. A risk analysis with no remediation plan attached is half a deliverable. OCR's guidance on risk analysis requirements spells out the elements it expects to see, and it has been publicly available for years, which is why "we didn't know what was required" lands badly.

How Often Do You Need a HIPAA Security Risk Assessment?

The Security Rule sets no fixed interval. It requires that your analysis be ongoing and updated as your environment changes. In practice, plan on a full assessment once every 12 months, plus a documented update whenever any of these happen:

  • You switch EHR, billing, or practice management systems
  • You add a location, an acquired practice, or a telehealth platform
  • You experience a security incident or breach, including one at a vendor
  • You add or remove a business associate with access to ePHI
  • You move servers to the cloud, or move staff to permanent remote work
  • You adopt new devices — tablets at intake, remote monitoring, imaging equipment

If you attest to the Security Risk Analysis measure under the Medicare Promoting Interoperability or MIPS programs, you also commit to completing or reviewing the analysis within the calendar year of the performance period. A December 2024 assessment does not support a 2026 attestation. Confirm the current-year specification on the CMS Promoting Interoperability program page before you check that box.

The Seven Steps, and Who Owns Each One

1. Build the ePHI inventory (security official + IT vendor)

List every system, device, and service that creates, receives, maintains, or transmits ePHI. Include the fax server, the ultrasound machine with a hard drive, the front desk's shared email inbox, the appointment reminder service, and the laptop your billing manager takes home. For each entry, record where the data sits, who has access, and whether it's encrypted at rest.

Most failed assessments fail here. A scope limited to "the EHR" is not thorough, and OCR has repeatedly treated incomplete scope as a substantive deficiency rather than a paperwork issue.

2. Map data flows (security official)

Draw how ePHI moves: intake tablet to EHR, EHR to clearinghouse, clearinghouse to payer, EHR to cloud backup, imaging to referral partner. A one-page diagram is enough. It exposes the transmission points where encryption either exists or doesn't.

3. Identify threats and vulnerabilities (security official + IT vendor)

For each asset, name realistic threats: ransomware through phishing, stolen device, insider snooping, misdirected fax, vendor compromise, flood or power loss. Then name the vulnerabilities that let the threat succeed — no MFA on remote access, local admin rights for all users, unpatched workstation, no audit log review.

4. Assess current controls (IT vendor, verified by security official)

Document what's already in place and whether it's actually working. "We have antivirus" is a claim. "Endpoint protection deployed to 14 of 16 workstations; two kiosk PCs excluded, verified 2026-07-30" is a finding.

5. Rate likelihood and impact (security official + owner)

Use a simple, consistent scale — low/medium/high on both axes — and write down the reasoning. The scale matters less than applying it the same way across every asset and being able to explain it later.

6. Produce the risk register (security official)

One row per risk: asset, threat, vulnerability, existing control, likelihood, impact, risk level. This is the artifact that makes an assessment reviewable.

7. Write the risk management plan (owner signs)

Every medium and high risk gets an assigned owner, a remediation action, a target date, and a status. Risks you accept get a written rationale from the owner. Unassigned risks are the ones that show up in an investigation two years later, unchanged.

A Worked Example: One Row From a Three-Provider Clinic

Asset: Billing manager's practice-owned laptop, used from home three days a week.
Threat: Theft or loss outside the office.
Vulnerability: Full-disk encryption not verified; device connects to the EHR over a VPN with password only.
Existing controls: Screen lock at 10 minutes; endpoint protection installed.
Likelihood: Medium. Impact: High — cached claim files include roughly 400 patient records.
Risk level: High.
Remediation: Enable and screenshot-verify BitLocker; enforce MFA on VPN; move claim exports to a mapped network share. Owner: IT vendor. Target: 2026-09-15. Status: in progress.

That single row is worth more than forty pages of narrative boilerplate, because it shows analysis, a decision, an owner, and a date. If the laptop later walks out of a coffee shop, encryption verification is also what determines whether you're doing breach notification at all under the breach notification rule's safe harbor for secured PHI.

The Five Gaps That Turn Your Assessment Into a Finding

  1. Partial scope. EHR only. No copiers, no personal phones, no vendor-hosted portals, no paper-to-scan workflows.
  2. No risk management plan. Risks identified, nothing assigned, no dates.
  3. Undated or unsigned. A document with no completion date and no approver cannot be tied to a compliance period.
  4. Template blanks. "[Practice Name]" still in the header, or generic risk ratings that match no real asset.
  5. One and done. A 2019 assessment sitting in a shared drive while the practice has since moved to the cloud and added two locations.

Read a few resolution agreements on the OCR breach portal and the pattern is unmistakable: the reported incident is the entry point, and the failure to conduct an enterprise-wide risk analysis is what broadens the corrective action plan. OCR's risk analysis enforcement focus has produced a steady stream of settlements against small and mid-sized providers, not just health systems.

What the Finished Documentation Package Contains

When someone asks for your risk analysis, hand over one folder with these items, each dated:

  • Scope statement — locations, systems, and time period covered, plus anything excluded and why
  • ePHI asset inventory and data flow diagram
  • Threat and vulnerability worksheet with control assessment
  • Risk register with likelihood, impact, and risk level
  • Risk management plan with owners, target dates, and current status
  • Evidence of remediation — screenshots, vendor tickets, configuration reports
  • Approval page signed by the owner or security official
  • Prior year's assessment and a short delta memo describing what changed

Keep all of it for six years from creation or last effective date, per 164.316(b)(2). That retention clock is why a spreadsheet named "risk stuff FINAL v3" on someone's desktop is a liability.

If assembling that package from scratch is what's been stalling you for two quarters, tooling helps. A platform that generates your risk analysis report, risk register, and matching policy set from structured answers about your environment will get you to a defensible draft in an afternoon instead of a month — and it keeps the prior versions, which is the part practices consistently lose. No product, this one included, is government-certified; what tooling buys you is a complete, dated, consistent record you can defend.

Don't Forget the Vendor Half

Your inventory will surface services holding ePHI that have no signed agreement on file — the transcription contractor, the answering service, the IT firm with domain admin. Each of those is a gap in both your risk analysis and your paperwork. Close them as you go; a signature-ready Business Associate Agreement takes minutes and belongs in the same folder as the assessment that identified the vendor.

Free Tools, and Where They Stop

ONC and OCR publish a downloadable Security Risk Assessment Tool aimed at practices with 10 or fewer providers. It's genuinely useful for the question-by-question walkthrough and it produces a report. What it does not do is maintain your asset inventory year over year, track remediation to closure, or generate the policies that correspond to your findings. Plan on owning those pieces yourself.

For a deeper mapping of Security Rule requirements to specific safeguards, NIST's implementation guidance for the HIPAA Security Rule, SP 800-66 Revision 2, is the reference to keep open. It is long, but the risk assessment sections give you defensible language for likelihood and impact definitions.

What's Coming to the Security Rule

HHS published a proposed overhaul of the Security Rule in January 2025 that would tighten exactly the areas practices skip: a written risk analysis with enumerated required elements, a maintained asset inventory, a network map, and mandatory MFA and encryption with narrow exceptions. Verify the rule's current status before you build a timeline around it — but note that every proposed element is something a thorough assessment already covers. Building your inventory and network map now is not speculative work.

Your Next 30 Days

Week 1: Name the security official in writing. Pull the vendor list from accounts payable and flag anyone touching ePHI.
Week 2: Walk every room with your IT vendor. Build the asset inventory, including the machines nobody claims.
Week 3: Score risks, write the register, draft the management plan with real owners and dates.
Week 4: Owner signs and dates the approval page. Calendar the first remediation review for 30 days out and the next full assessment for 12 months out.

The practices that survive an OCR data request are not the ones with zero risks. They're the ones that can show a dated HIPAA security risk assessment, a plan that assigned each risk to a person, and evidence that the plan moved. If you'd rather not build that record in a spreadsheet, start with an automated risk analysis and document set and spend your time on the remediation instead of the formatting.