The OCR data request letter is usually three or four pages. Item 3 almost always reads some version of this: "A copy of the most recent risk analysis conducted by the covered entity pursuant to 45 C.F.R. § 164.308(a)(1)(ii)(A), including the date of completion and the individuals involved." You have 30 days from the date on that letter, sometimes less. If what you send back is a vendor's twelve-question checklist with a date from 2021, the investigation stops being about the incident and starts being about your compliance program. That is why a security risk analysis HIPAA requires is the single most consequential document your practice maintains — and the one most often missing, stale, or too thin to survive a read.

This piece is for the person who has to produce that document: the owner, administrator, privacy officer, or security officer whose name sits in the policy binder. Not theory. Who does what, on what cycle, and what the paper trail looks like when someone asks.

What Is a Security Risk Analysis Under HIPAA?

A security risk analysis under HIPAA is a documented, organization-wide assessment of the risks and vulnerabilities to the confidentiality, integrity, and availability of all electronic protected health information your organization creates, receives, maintains, or transmits. It is required by 45 CFR 164.308(a)(1)(ii)(A) — a required implementation specification, not an addressable one. It applies to every covered entity and every business associate regardless of size, and it must be completed, written down, and updated.

It is not a questionnaire, not a network scan, and not a policy purchase. A scan tells you a server is unpatched. A risk analysis tells you which ePHI that server holds, what threats could reach it, how likely that is, what the impact would be, and what your resulting risk rating is.

The Nine Elements OCR Grades You Against

OCR's Guidance on Risk Analysis Requirements under the HIPAA Security Rule lists nine elements. Investigators read your document looking for them. If your report is silent on any of them, expect a follow-up request.

  1. Scope — all ePHI, in all forms and locations, including portable media and vendor-hosted systems.
  2. Data collection — where ePHI lives, who touches it, how it moves. Documented, not assumed.
  3. Identify and document threats and vulnerabilities — human, natural, environmental, technical.
  4. Assess current security measures — what you already have in place and whether it is configured and used.
  5. Determine likelihood of occurrence — a rating, with a basis for it.
  6. Determine potential impact — how many records, what sensitivity, what operational damage.
  7. Determine the level of risk — likelihood × impact, expressed consistently across findings.
  8. Finalize documentation — the written report, dated and attributable.
  9. Periodic review and updates — evidence that this is a cycle, not a one-time event.

For methodology, NIST SP 800-66 Revision 2 maps Security Rule standards to practical safeguards and is the closest thing to a defensible reference framework for a small or mid-sized practice. It is free, and citing it in your report costs you nothing.

Step One Is an Asset Inventory, and Most Practices Skip It

You cannot assess risk to systems you have not listed. Before anyone rates a single threat, someone in your practice has to walk the building and the vendor list and write down every place ePHI sits.

A workable inventory row has: asset name, type, physical or cloud location, what ePHI it holds or transmits, who administers it, whether it is encrypted at rest, whether a BAA is signed, and who to call when it breaks.

What Turns Up on the First Pass

  • The multifunction copier at the front desk with a 250 GB internal hard drive holding scanned insurance cards from the last four years.
  • A retired biller's laptop in the storage closet, still holding an offline copy of a claims export.
  • The appointment-reminder texting service nobody has a signed agreement with.
  • Two staff phones with the practice email account and no screen lock policy enforced.
  • A radiology workstation running an operating system that stopped receiving patches.
  • A cloud drive one provider set up personally to move images between locations.

Every one of those is a finding. None of them appear in a generic template. This is exactly the gap OCR's enforcement work on risk analysis failures has focused on — organizations that produced a document but whose document never covered the systems actually breached. Cross-check your inventory against the HHS breach portal for practices your size; the recurring causes are ransomware on unsegmented networks, unencrypted laptops, and vendor incidents. Those categories should appear by name in your threat list.

A Worked Example: Rating One Finding End to End

Asset: Front-desk scanner/copier, on the clinical VLAN, internal drive not encrypted, no BAA with the leasing company, lease expires in 14 months.

ePHI involved: Scanned IDs, insurance cards, referral packets. Estimated 6,000+ documents retained on device.

Threat/vulnerability: Device returned to lessor at end of lease with drive intact; unauthorized retrieval of stored images. Also: unauthenticated access to the device's web console from the clinical network.

Current controls: Physical placement behind the counter. Nothing else. Console password is the factory default.

Likelihood: Medium — lease returns are routine and the default-credential exposure is trivially discoverable on an internal network.

Impact: High — thousands of individuals, identity-grade data, reportable breach with media notice if it exceeds 500 residents of a state.

Risk level: High.

Remediation (this is risk management, 164.308(a)(1)(ii)(B)): Change console credentials and disable remote management by Sept 5, owner: IT contractor. Enable drive overwrite-after-job by Sept 5. Execute a BAA with the leasing vendor by Sept 30, owner: administrator. Add certificate-of-drive-destruction to the lease return checklist, owner: administrator, effective now.

Ten findings written to that standard beat two hundred checkbox answers. If any of those remediation items involves a vendor that touches ePHI and you don't have paper on them, a signature-ready business associate agreement is the fastest way to close that specific gap before your next review cycle.

How Often You Have to Redo It

The Security Rule does not name an interval. It requires review and update as needed. In practice, treat it as annual plus event-driven, and be able to show both.

Annual: a full refresh with a new date, new signatures, and a comparison against last year's open items.

Event-driven triggers that require an update regardless of where you are in the cycle:

  • New EHR, practice management system, or patient-facing portal
  • A new location, an acquisition, or a merged practice's systems joining yours
  • Adding telehealth, remote scribes, or remote coding staff
  • Any security incident or breach, however small
  • A new business associate handling a material volume of ePHI
  • A vendor's own breach notification to you
  • Significant staffing change in the security officer role

If you attest to the Promoting Interoperability performance category under MIPS, note the separate deadline: the security risk analysis measure must be completed or reviewed during the calendar year of your EHR reporting period. A December 2024 analysis does not support a 2026 attestation. CMS audits of that measure ask for the dated report, the remediation plan, and evidence of action on deficiencies. Guidance and the free HHS Security Risk Assessment Tool are worth reviewing before you build your own format.

Risk Analysis, Risk Management, and Gap Assessment Are Three Different Documents

Practices lose points here constantly. A gap assessment compares your controls against the Security Rule's standards — useful, but it is not a risk analysis, because it does not evaluate likelihood or impact against your specific assets. A risk analysis produces rated findings. Risk management is what you do about them: a plan with owners, dates, and closure evidence.

OCR asks for all three, in that order. A risk analysis with no corresponding management plan reads as a document produced for an auditor rather than a program that runs.

What the Documented Evidence File Actually Contains

Keep this as a single folder, named by year, with retention of six years from creation or last effective date per 164.316(b)(2)(i).

  • The dated risk analysis report, naming the individuals who conducted it and the methodology used
  • The asset and ePHI inventory used as its scope, with a version date
  • The threat and vulnerability catalog with likelihood, impact, and risk ratings
  • The risk management plan: finding, action, owner, due date, status, closure date
  • Evidence of closure — screenshots, invoices, configuration exports, signed BAAs, disposal certificates
  • Meeting minutes or a signed memo showing leadership reviewed and accepted the results
  • The prior year's report, for comparison
  • Policy and procedure versions in effect during the period

That folder is the deliverable. Assembling it by hand, then rebuilding it every year while the practice sees patients, is where most compliance programs quietly stall. If your last analysis is more than a year old or you are staring at a blank template, tools that generate the risk analysis report, policies, and full compliance document set get you to a defensible baseline in an afternoon instead of a quarter — and give you a consistent format to update next year rather than starting over.

Four Ways Practices Fail This, in Order of Frequency

1. Scope limited to the EHR

Your EHR vendor's SOC 2 report covers their infrastructure. It says nothing about your workstations, your Wi-Fi, your copier, your staff phones, or your imaging box. Scope means all ePHI you create, receive, maintain, or transmit.

2. No dates, no names

An undated report with no author is not evidence. Every version gets a completion date and the names of the people who did the work.

3. Findings identified, nothing closed

The second-worst position is having no risk analysis. The worst is having one that flags an unencrypted laptop fleet three years running with no remediation entry. That documents willful neglect in your own handwriting.

4. Delegated entirely to the IT contractor

Your IT vendor can assess technical safeguards. They cannot assess your workforce sanction policy, your BAA inventory, your minimum-necessary practices, or your paper-to-scan workflow. Administrative and physical safeguards are yours. Split the work explicitly and document who covered which sections.

Your Next 30 Days

Days 1–7: Assign the security officer role in writing if it is vague. Pull the last risk analysis and check its date. Start the asset inventory — walk every room, list every device, then reconcile against your vendor payments to find services nobody remembered.

Days 8–17: Build the threat list per asset. Rate likelihood and impact on a consistent scale. Do not soften ratings to make the report look better; the report is not a grade, it is a work order.

Days 18–24: Write the risk management plan. Every high and medium finding gets an owner and a date. Fix the free ones immediately — default passwords, missing screen locks, unrestricted local admin rights.

Days 25–30: Finalize, sign, and date the report. Book the leadership review. Put next year's kickoff on the calendar now, and set a standing quarterly 30-minute check on the open-items list.

If a breach happens after that, you will be answering questions about the incident. If you skip it, you will be answering questions about the last five years. Start your inventory this week, and if the documentation load is what has stopped you before, build the report and policy set in one pass so next August is an update rather than a scramble.