An OCR data request lands in your inbox after a stolen laptop report. It asks for "the most recent risk analysis conducted in accordance with 45 CFR 164.308(a)(1)(ii)(A)." You send two things: a printout from a free assessment tool your former IT vendor ran in 2022, and the three-page memo your privacy officer wrote last month explaining why the laptop incident was not reportable. Neither one answers the question.

That mix-up is what the hipaa risk assessment vs risk analysis confusion costs. These are two different deliverables, required by two different rules, on two different clocks. This article separates them, tells you who inside your practice owns each, and describes what the documented evidence actually looks like when someone asks for it.

HIPAA Risk Assessment vs Risk Analysis: The Short Answer

A risk analysis is the Security Rule requirement at 45 CFR 164.308(a)(1)(ii)(A). It is an enterprise-wide, forward-looking evaluation of risks and vulnerabilities to the confidentiality, integrity, and availability of all electronic protected health information you create, receive, maintain, or transmit. It is a required implementation specification, not optional, and it produces a written report plus a remediation plan.

A risk assessment, in the strict regulatory sense, is the four-factor evaluation at 45 CFR 164.402 that you perform after an impermissible use or disclosure of PHI. Its only job is to determine whether there is a low probability that the PHI has been compromised. If you cannot demonstrate low probability, the incident is a breach and notification obligations start.

  • Risk analysis: Security Rule, ePHI only, proactive, practice-wide, ongoing, feeds your risk management plan.
  • Risk assessment (four-factor): Breach Notification Rule, all PHI including paper and verbal, reactive, incident-specific, feeds your notification decision.
  • Overlap: both must be documented in writing and retained six years. Both get requested during an OCR investigation.

Everyone, including federal agencies, uses "risk assessment" loosely to mean the Security Rule exercise. That is fine in conversation. It is not fine in your document titles or your policy manual, because the words map to different obligations and different retention triggers.

Why the Government's Own Tool Adds to the Confusion

ONC and OCR publish a free desktop application called the Security Risk Assessment (SRA) Tool. It is designed for small and medium practices, and it is a legitimate starting point. Its name says "assessment" while it exists to help you satisfy the "analysis" requirement.

NIST does the same thing. NIST SP 800-66 Revision 2, the cybersecurity resource guide for implementing the HIPAA Security Rule, walks through a risk assessment methodology drawn from SP 800-30 and maps it to Security Rule standards. The vocabulary differs; the obligation is the Security Rule's.

Practical rule for your practice: when a payer, an auditor, or CMS asks for a "security risk assessment," they almost always mean the 164.308(a)(1)(ii)(A) risk analysis. When your incident log says "risk assessment," it should mean the four-factor breach determination. Pick one convention per document type and enforce it in file names.

What Makes a Risk Analysis Defensible

OCR's Guidance on Risk Analysis Requirements lays out the elements OCR looks for. Treat these as your table of contents, because investigators effectively do.

Scope and asset inventory

Every system, device, application, and medium that touches ePHI. Servers, workstations, laptops, tablets, phones with clinical apps, imaging modalities, the ultrasound cart with an embedded hard drive, scan-to-email copiers, backup drives, cloud EHR, e-fax, patient texting, remote coder home offices, and every business associate holding your data.

A risk analysis limited to "the EHR" is the single most common finding OCR cites. If your inventory does not name the copier and the cloud file share, your scope is incomplete and the whole report is discountable.

Threats and vulnerabilities, identified and documented

Pair each asset with realistic threats: ransomware, phishing-driven credential theft, insider snooping, lost device, vendor compromise, flood, extended power loss, misdirected fax. Then name the vulnerability that lets the threat succeed, such as shared logins at the front desk or an unencrypted backup drive in a desk drawer.

Current security measures, likelihood, impact, risk level

Document the controls already in place, then rate likelihood and impact for each threat-vulnerability pair, then assign a risk level. High, medium, low is sufficient if you define the criteria and apply them consistently. What OCR wants to see is reasoning, not a color-coded grid produced with no visible logic.

Finalized documentation and periodic review

Dated, signed, version-controlled. Then the piece practices skip: 164.308(a)(1)(ii)(B) risk management. Each high and medium risk needs an owner, a planned action, a target date, and a follow-up entry showing what happened. A risk analysis with no remediation trail is evidence that you identified the problem and left it alone, which is worse than a thin analysis.

If assembling that package from scratch is the reason your last analysis is two years stale, this is exactly the gap that automated HIPAA risk analysis and policy generation is built to close: structured questionnaire, scored findings, a written report with the OCR elements in order, and the matching policy set. The value is not the PDF, it is that next year's update takes hours instead of a quarter.

The Four-Factor Breach Risk Assessment, Worked

An impermissible use or disclosure of unsecured PHI is presumed to be a breach unless you demonstrate a low probability of compromise using the four factors at 164.402. Skipping the analysis means the presumption stands.

Scenario: your biller emails a 40-line aging report with patient names, dates of birth, CPT codes, and balances to the wrong practice's billing manager. The recipient replies within 20 minutes: "Wrong office, I deleted it, here is confirmation."

  1. Nature and extent of the PHI. Names, DOB, procedure codes, balances. Financial and diagnostic inference, no SSN. Moderate sensitivity, 40 individuals.
  2. Unauthorized person who received it. A covered entity's workforce member subject to HIPAA, not a random consumer address. Lowers probability.
  3. Whether PHI was actually acquired or viewed. The recipient opened the message. Acquisition happened. This factor does not help you.
  4. Extent to which risk has been mitigated. Written attestation of deletion from a HIPAA-regulated recipient within the hour. Meaningful mitigation.

Documented conclusion, signed by the privacy officer, with the attestation email attached: low probability of compromise, not a reportable breach, logged in the incident register. Change one fact, say the address belongs to a personal Gmail account with no reply, and the conclusion flips to reportable, individual notice within 60 days of discovery, and the annual small-breach log to HHS.

Notice what the four-factor assessment is not. It does not evaluate whether your controls are adequate. It does not update your risk register. It is a decision memo about one event. Your hipaa risk assessment vs risk analysis filing convention should keep these in separate binders: incident files here, security management program there.

Who Owns What, and On What Clock

Risk analysis: annual, plus event-driven

The Security Rule does not print the word "annual." It requires review and updates as needed, which in practice means at least once every 12 months and whenever something material changes: new EHR or clinic location, a merger, a new remote-work arrangement, a new class of connected device, a ransomware incident, or a significant vendor swap.

Two hard dates drive real behavior. First, if you attest under CMS Promoting Interoperability or MIPS, the security risk analysis measure requires the analysis to be conducted or reviewed during the calendar year of your reporting period, with documentation retained. Read the current-year measure specification on the CMS site before you attest, because supporting details change. Second, HHS published a proposed overhaul of the Security Rule in January 2025 that would tighten documentation, asset inventory, and update cadence expectations. Practices that already run a dated annual cycle will absorb a final rule without drama.

Owner: the Security Official named in your policies. Contributors: IT or MSP for technical controls, practice manager for physical and workforce controls, privacy officer for the vendor and BAA inventory. Sign-off: owner plus practice principal.

Four-factor risk assessment: immediately, always

Every reported incident involving PHI gets one, even the obvious non-events, because "we determined it was not a breach" is only credible with a memo behind it. Target 5 business days from discovery to a written determination so the 60-day notification window stays comfortable.

Owner: the Privacy Official. Front desk and clinical staff owe you the report; the assessment is not theirs to make. Train them on one sentence: report it to the privacy officer the same day, do not decide.

The Evidence File an Auditor Would Accept

  • Current risk analysis report, dated within 12 months, with named scope and asset inventory.
  • Prior years' reports, six-year retention, so the trend is visible.
  • Risk management plan showing each finding, owner, action, target date, and closure evidence, such as a screenshot confirming full-disk encryption is on.
  • Meeting minutes or email showing leadership reviewed the results.
  • Incident register with a four-factor memo for each entry and mitigation artifacts.
  • Business associate agreements matching every vendor named in the analysis. Missing paperwork is a fast finding, and a signature-ready business associate agreement closes that gap faster than drafting from a template you found online.
  • Workforce training records tied to the risks you identified.

Three Failure Patterns to Kill This Quarter

The vendor scan mistaken for a risk analysis. A penetration test, a network vulnerability scan, or a security questionnaire from your MSP is input, not output. None of them cover paper, workforce, physical security, or business associates.

The analysis that stops at the EHR. Your cloud EHR vendor's own compliance posture is theirs. Your obligation covers everything else touching ePHI in your building and on your staff's devices.

The four-factor memo written after the deadline. A determination dated 70 days after discovery, for an incident you then reported, tells an investigator your incident response process is reconstructed rather than operated. Date and sign in real time.

Settle the terminology this week: rename your files, fix the two policy paragraphs that use the words interchangeably, and put both obligations on the calendar with named owners. Then, if your current risk analysis is stale or was never scoped past the EHR, generate a documented risk analysis and matching policy set and start the remediation log the same day. The next records request or incident is not the moment to learn which document you were supposed to have.