The OCR data request letter runs two pages. Item four is the one that matters: a copy of the most recent risk analysis conducted by the covered entity, including the date of completion and all supporting documentation. The response window is measured in weeks. If what you send back is a vendor's twelve-question online quiz with a PDF certificate attached, you have not answered the question — and the investigator will say so in writing.

This is a working guide to how to conduct a HIPAA risk assessment that survives that letter. It is written for the person who will actually run it: the practice administrator, the designated Security Officer, the compliance lead who inherited the binder. You will get the scope, the method, the roles, the calendar, and a description of what the finished evidence file looks like on the shelf.

What the Rule Requires, in Plain Terms

The obligation lives at 45 CFR 164.308(a)(1)(ii)(A). It is a required implementation specification, not an addressable one — there is no "we considered it and documented why not" path. The text asks you to 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 carry the weight. Accurate means it reflects your actual environment, not a template's assumptions. Thorough means all ePHI, everywhere it lives — including the laptop in the billing manager's car and the imaging drive in the back closet. All means all.

The companion requirement at 164.308(a)(1)(ii)(B) is risk management: implementing security measures sufficient to reduce identified risks to a reasonable and appropriate level. A risk analysis with no remediation plan attached is half an artifact. OCR's guidance on risk analysis spells out the elements it expects to find.

What a Risk Analysis Is Not

  • Not a gap assessment. Checking whether you have a policy for each Security Rule standard tells you about paperwork, not risk.
  • Not a penetration test. A pen test finds technical weaknesses in scope. It does not evaluate paper records workflows, vendor access, or physical safeguards.
  • Not a certification. No product or consultant can certify you under HIPAA. HHS does not endorse or accredit compliance vendors. Anyone selling you a government-recognized seal is selling you something that does not exist.

How to Conduct a HIPAA Risk Assessment in Nine Steps

The short answer, for the person who needs the sequence before the detail:

  1. Define scope. Every location, system, and workflow that creates, receives, maintains, or transmits ePHI.
  2. Inventory ePHI assets. Systems, devices, media, and third parties, with data flows between them.
  3. Identify threats. Human, natural, and environmental — ransomware, insider snooping, lost device, flood, power loss.
  4. Identify vulnerabilities. The specific weaknesses each threat could exploit in your environment.
  5. Assess current controls. What you actually do today, verified, not what the policy says.
  6. Rate likelihood and impact. Use a consistent scale and write down the reasoning.
  7. Assign a risk level to each finding. Typically likelihood × impact, producing low/moderate/high/critical.
  8. Build the risk management plan. Owner, action, target date, and status for every moderate-and-above finding.
  9. Document, approve, and retain. Signed, dated, and kept six years per 164.316(b)(2).

Steps one through five take the most calendar time. Steps six through nine take the most argument.

Step One in Practice: The ePHI Inventory Nobody Has

Start here because everything downstream depends on it, and because most practices discover their inventory is wrong within the first afternoon.

Walk the building. Physically. Open the closet in the back hallway. Ask the front desk what happens to a fax that arrives after 5 p.m. Ask the biller which spreadsheet she keeps on her desktop for aging claims. Ask the office manager whether the old server that was "decommissioned" in 2023 was wiped, and who has the certificate.

Your inventory should capture, for each asset: what it is, where it lives, what ePHI it holds, who administers it, whether the data is encrypted at rest, whether it is backed up, and who outside your organization can touch it. That last column is where your business associate list gets reconciled against reality — and where practices routinely find a transcription service or a marketing agency operating without a signed agreement in the file. If you find one, close it fast; a signature-ready business associate agreement takes minutes to generate and stops a finding from aging into a violation.

The Assets Practices Forget

  • Multifunction copiers with internal hard drives
  • Voicemail systems and after-hours answering services
  • Personal phones running a texting or scheduling app
  • Digital imaging modalities with embedded operating systems no one patches
  • Cloud storage accounts opened by a departed employee
  • Backup drives in a home office
  • Patient portal messages exported for a records request

Threats, Vulnerabilities, and the Difference That Matters

A threat is the actor or event. A vulnerability is the opening. Ransomware is a threat; an unpatched remote access tool with a shared administrator password is the vulnerability. Write both, separately, on every finding. Investigators read for that distinction, and so should you — because remediation attaches to the vulnerability, not the threat.

For threat catalogs and rating methodology, NIST Special Publication 800-66 Revision 2, the cybersecurity resource guide for implementing the HIPAA Security Rule, is the most useful free document in this space. It maps Security Rule requirements to concrete practices and points to NIST SP 800-30 for the risk assessment mechanics. You do not need to adopt NIST wholesale. You do need a defensible method, and borrowing one beats inventing one.

A Worked Example

Asset: Front-desk scanner, configured to email scanned intake forms to a shared staff inbox.
Threat: Interception or unauthorized access to email in transit and at rest.
Vulnerability: Scans transmit unencrypted over SMTP; the shared inbox has four users, one shared password, no MFA, and no retention limit — 1,900 messages going back three years.
Current controls: Workstation screen lock. Nothing else.
Likelihood: High. Impact: High — the inbox contains full demographics, insurance data, and clinical history.
Risk level: Critical.
Remediation: Reconfigure scanner to deposit directly into the record system; enable MFA on the mailbox; purge and set 30-day retention. Owner: IT vendor plus Office Manager. Target: 45 days.

That is one row. A ten-provider primary care group typically generates 60 to 120 of them. If your assessment produced eleven findings and nine were "low," you did not look hard enough.

Who Does What, and How Long It Takes

You need a designated Security Official under 164.308(a)(2). That person owns the analysis. They do not do it alone.

  • Security Official: owns scope, method, final ratings, and the signed report.
  • Practice owner or administrator: approves the risk management plan and funds it. This signature is the one OCR looks for.
  • IT vendor or MSP: supplies patch status, encryption status, backup verification, access logs, and network topology. Ask in writing; keep the response.
  • Department leads: describe actual workflows. Front desk, billing, clinical, and records each get an interview.
  • HR: confirms termination checklist execution for the last twelve months.

Realistic calendar for a single-site practice with fewer than 25 staff: two weeks for inventory and interviews, one week for control verification, one week for scoring and drafting, one week for leadership review and sign-off. Six weeks, start to finish, at a few hours per week. Multi-site groups should plan on ten to twelve.

Assembling that documentation set by hand — the analysis, the risk register, the remediation plan, the underlying policies each finding references — is where most practices stall out around week four. Tools that generate the risk analysis report and the supporting policy set from your own inputs collapse the drafting phase without outsourcing the judgment calls, which still belong to you.

How Often You Have to Redo It

The Security Rule does not say "annually." It requires periodic review and updates in response to environmental or operational changes. In practice, three triggers apply:

Annually, at minimum. Anything longer and you cannot credibly call it current.

On material change. New record system, new location, telehealth platform swap, merger, a shift to remote billing staff, or a new business associate with broad access. Update the affected sections and re-date them.

After any security incident. Including incidents that did not rise to a reportable breach. The analysis is where you record what the incident revealed.

Separately, if you participate in the Medicare Promoting Interoperability Program or the MIPS Promoting Interoperability performance category, CMS requires that the security risk analysis be conducted or reviewed within the calendar year of your performance period. A December 2024 assessment does not support a 2026 attestation. Auditors check the date first.

What the Evidence File Looks Like

When the request arrives, you should be able to produce a single package containing:

  1. The risk analysis report, dated and signed by the Security Official and an owner or executive
  2. The scope statement, naming every location and system assessed
  3. The ePHI asset inventory and data flow description
  4. The full risk register — every finding, rating, and rationale, including low-rated ones
  5. The risk management plan with owners, target dates, and current status
  6. Evidence of completed remediation: change tickets, invoices, screenshots, configuration exports
  7. Interview notes and the source documents your IT vendor provided
  8. Prior-year analyses, showing progression

Item six separates practices that pass from practices that pay. A plan with fourteen open items and no movement in eighteen months is worse than no plan — it establishes that you knew.

Five Failures That Show Up in Enforcement

Scope limited to the record system. The analysis covers the EHR and stops. Email, imaging, backups, and paper-to-digital workflows go unexamined.

Delegated entirely to the IT vendor. Your MSP can assess technical safeguards. It cannot assess your workforce sanction policy, your minimum-necessary practices, or your BAA coverage. Those are yours.

No ratings, only observations. A narrative that lists concerns without likelihood, impact, and a resulting risk level is not a risk analysis.

Findings with no owner. "Practice should implement MFA" is not remediation. "Office Manager to enable MFA on all mailboxes by October 15" is.

Never revisited. Browse the OCR breach portal for entities your size and note how often the underlying facts trace to a known, unaddressed weakness.

Free Tooling Worth Using

The joint ONC/OCR Security Risk Assessment Tool is free, downloadable, and structured around the Security Rule's own standards. For a small practice with a patient administrator, it is a legitimate way to run the exercise. Its limitation is that it produces answers, not a governed document set — you still have to build the register, the remediation plan, the policies each finding points to, and the retention discipline around all of it.

Start This Week

Block two hours. Walk the building with a notebook and start the asset inventory. That single artifact will tell you more about your exposure than any questionnaire, and it is the foundation every other step rests on.

When you are ready to turn those notes into a dated, signed, defensible package, automate the risk analysis report and the full compliance document set so your time goes into fixing findings rather than formatting them. The remediation is the part that actually protects your patients — and the part an investigator will ask you to prove.