HIPAA Security Risk Assessment: Who Needs One and What to Review

First confirm whether HIPAA applies to your organization

“We handle health information” is a reason to investigate, not a complete HIPAA applicability decision. Covered entities include health plans, health care clearinghouses, and health care providers that conduct specified transactions electronically. Some businesses performing functions or services for covered entities are business associates, with certain HIPAA obligations applying directly to them.¹

A clinic, billing service, software provider, and consumer wellness business can have different roles. Determine the organization's activities, relationships, and data flows before choosing a checklist. Do not treat a customer's request for a business associate agreement as the entire analysis of status or duties.

This guide addresses the security risk analysis of electronic protected health information, commonly called ePHI. It offers an original preparation method, not a legal opinion, certification, or substitute for organization-specific professional advice.

What the risk analysis is meant to establish

HHS guidance calls for an accurate and thorough assessment of potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI. The scope includes relevant information wherever the regulated organization creates, receives, maintains, or transmits it. HHS does not prescribe one universal method or document format.²

For the working team, that means producing a defensible account of the information, the ways it could be harmed, the safeguards actually in place, and the actions needed. Purchasing software or checking every box in a generic form does not answer those questions by itself.

NIST SP 800-66 Revision 2 offers a practical resource for understanding safeguards, with implementation questions and mappings to other security references. It is supporting guidance rather than a replacement for the Security Rule.³

Map ePHI before scoring risks

Begin with interviews and walkthroughs. Ask how a patient record moves from appointment to clinical care, billing, storage, sharing, and disposal. Ask what happens when the normal system is unavailable. The unexpected workarounds often matter as much as the main application.

An original inventory can use these fields:

Include portable devices, remote access, backups, file exports, scanning stations, and relevant service providers. A diagram is helpful when it shows trust boundaries and alternate paths; it need not resemble a complex technical architecture drawing.

Keep actual patient information out of the working template whenever synthetic descriptions suffice. Store supporting evidence under appropriate access controls. The risk-analysis project should not create a new uncontrolled collection of sensitive records.

Use scenarios rather than vague labels

“Cyberattack” is too broad to guide corrective work. Write a scenario that connects a threat, a weakness, an affected workflow, and a consequence.

For example: “An unauthorized person uses an account that should have been removed to export patient documents from the scheduling system.” That statement points to account lifecycle, export permissions, monitoring, and response. It also identifies what the team needs to investigate before assigning a risk level.

Consider accidental disclosure, inappropriate internal access, unavailable records, damaged data, and failure of physical or technical protections. Avoid assuming that every problem comes from an outside attacker or that confidentiality is the only concern.

Choose a likelihood and impact method the team can explain. Record the reasoning and uncertainty, not only a score. A numerical value based on undocumented guesses creates precision without reliability.

A fictional clinic example

A fictional six-person clinic uses a hosted clinical system and a separate billing service. During interviews, staff reveal that an appointment list is exported each morning to a shared desktop folder. The technical system's security settings do not describe who can reach this copy.

The team records the following original analysis entry:

The team does not declare the entire clinic safe after changing folder permissions. It confirms the change, considers related copies, and asks whether the workflow can avoid the export altogether. The example illustrates a method; its treatment must be adapted to actual clinical, operational, and legal needs.

Connect analysis to management decisions

An analysis that ends with a list of weaknesses is unfinished operational work. Assign an action owner, an expected result, a due date, and the person authorized to evaluate completion. Distinguish implemented safeguards from proposals awaiting approval.

Use the remediation-plan template for the action record. A closure test should examine the identified risk: can an unauthorized account still reach the export, and can authorized staff still perform the necessary task? “Ticket closed” is not the same evidence.

Where management accepts a remaining risk, document the rationale, authority, conditions, and review trigger. Acceptance is not a way to waive an applicable legal requirement. Seek qualified guidance when the proposed decision concerns whether a required safeguard can be handled differently.

Review safeguards across the whole workflow

Organize discussion around people and procedures, the physical environment, and technical protections. Useful preparation questions include:

• Can each person explain their responsibility for protecting the information?
• Can the organization show how access is granted, changed, and removed?
• What happens to records when a device is lost or a service is unavailable?
• Who investigates unusual access, and what records support that investigation?
• Are backup and recovery assumptions tested against the required workflow?
• Which service-provider responsibilities are documented, and which remain uncertain?

These are original investigation prompts, not a reproduction of regulatory specifications. Where a Security Rule implementation specification is “addressable,” do not read that as automatically optional. The current HHS summary explains that organizations must evaluate what is reasonable and appropriate and document applicable decisions or alternatives.⁴

Keep current rules separate from proposals

As checked October 1, 2026, HHS continues to describe the Security Rule modernization as a notice of proposed rulemaking and states that the current rule remains in effect. Do not present proposed detailed requirements as already enacted obligations.⁵

HHS risk-analysis guidance does not establish a universal annual analysis frequency. Review needs depend on the environment and changes; the process should remain ongoing. New systems, material workflow changes, incidents, or newly identified vulnerabilities can prompt an update.²

A team may choose an annual full review plus event-driven updates as its internal operating rhythm. Label that choice accurately, and confirm any additional commitments that arise from contracts or other applicable requirements.

Frequently asked questions

Does using a HIPAA-oriented vendor complete the analysis?

No. The organization's configurations, users, transfers, physical environment, and workarounds still matter. Evaluate the particular service and responsibilities rather than relying on a marketing label.

Is the official assessment tool useful?

It can structure preparation, particularly for smaller organizations. HHS links its Security Risk Assessment Tool from the risk-analysis guidance. Tool output still needs accurate inputs, appropriate scope, and follow-through.²

Can a small practice perform the initial inventory itself?

It can gather workflow facts and evidence. Technical assessment and legal applicability questions may require qualified help. Record what the team knows and what remains unverified instead of filling gaps with assumptions.

Does completing this checklist establish compliance?

No. This guide helps organize questions and corrective work. The adequacy of the organization's analysis and safeguards requires assessment against its actual circumstances and applicable requirements.

Sources and references

1. HHS Office for Civil Rights. Covered Entities and Business Associates (2024-08-21). HIPAA applicability depends on covered-entity or business-associate status, not merely holding health-related information. ↩

2. HHS Office for Civil Rights. Guidance on Risk Analysis. Current OCR explanation of ePHI scope, documentation and ongoing risk analysis. ↩ ↩² ↩³

3. NIST. SP 800-66 Rev. 2: Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide (2024-02-14). Practical resource and mappings for regulated entities; it does not replace the rule or determine applicability. ↩

4. HHS Office for Civil Rights. Summary of the HIPAA Security Rule (2026-08-07). Current HHS summary, last reviewed August 7, 2026, explaining required and addressable implementation specifications. ↩

5. HHS Office for Civil Rights. HIPAA Security Rule NPRM (2024-12-27). HHS describes the modernization as proposed and says the current Security Rule remains in effect. ↩