What the HIPAA Security Rule requires
The requirement sits in the first administrative safeguard, the security management process standard at 45 CFR 164.308(a)(1). Its first implementation specification tells covered entities and business associates 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 the covered entity or business associate.”
The second, risk management, requires security measures “sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level.” The regulation marks both as Required, so the flexibility that applies to addressable specifications doesn't apply to them.
A note on terms: the regulation says “risk analysis.” NIST SP 800-66 Rev. 2 uses risk analysis for what the rule requires and risk assessment for the process used to determine the level of risk. In everyday use, a HIPAA risk assessment and a security risk analysis refer to the same obligation.
| Specification | Citation | What it asks for |
|---|---|---|
| Risk analysis | 164.308(a)(1)(ii)(A) | An accurate and thorough assessment of risks and vulnerabilities to the confidentiality, integrity and availability of ePHI |
| Risk management | 164.308(a)(1)(ii)(B) | Security measures that reduce those risks and vulnerabilities to a reasonable and appropriate level |
| Sanction policy | 164.308(a)(1)(ii)(C) | Appropriate sanctions for workforce members who don't follow security policies and procedures |
| Information system activity review | 164.308(a)(1)(ii)(D) | Regular review of records such as audit logs, access reports and security incident tracking reports |
Scope: all the ePHI you create, receive, maintain or transmit
The general requirements at 164.306(a) apply to “all electronic protected health information the covered entity or business associate creates, receives, maintains, or transmits.” A risk analysis that covers only the electronic health record system, or only the main office, leaves gaps the rule doesn't allow.
Business associates are in scope in their own right. Section 164.302 applies the Security Rule to covered entities and business associates alike, and 164.308(b)(2) lets a business associate pass ePHI to a subcontractor only after obtaining satisfactory assurances that the subcontractor will safeguard it.
NIST SP 800-66 Rev. 2 describes a scope with a physical boundary and a logical one covering every device, medium and network that holds or carries ePHI, wherever it is. It specifically calls out teleworkers, service providers with remote access, removable media, mobile devices and connected medical devices. A typical inventory includes:
- Clinical, billing and practice management systems, and the databases behind them
- Cloud services and software vendors that store, process or transmit ePHI
- Email, messaging, file sharing and backup systems
- Laptops, phones, tablets, removable media and connected medical devices
- Business associates, subcontractors and the connections they use
How to do a HIPAA risk assessment, step by step
The Security Rule doesn't prescribe a method, and NIST SP 800-66 Rev. 2 notes that no single methodology works for every regulated entity. It says its own steps should be customized and don't have to run in a fixed order; some can run at the same time. The sequence below follows the NIST guidance.
Inventory ePHI and map how it moves
Find every place ePHI is generated, where it enters the organization (for example, through web portals), where it flows, where it's stored and where it leaves. NIST's guidance also asks whether ePHI goes to cloud or other service providers, how access is controlled, and whether it's encrypted in storage and in transit.
This step sets the quality of everything after it: a system missing from the inventory means its threats and vulnerabilities are missing too.
Identify reasonably anticipated threats and vulnerabilities
List the threat events and sources that apply to you: intentional (phishing, ransomware, theft), accidental (misdirected email, data entry errors), natural (floods, storms) and environmental (power failures). NIST SP 800-66 Rev. 2 specifically asks organizations to consider phishing, ransomware and insider threats.
Then identify the vulnerabilities and predisposing conditions each threat could exploit, such as unpatched systems, shared accounts or a flood-prone facility. A questionnaire can't find technical vulnerabilities, so NIST recommends pairing it with a method such as vulnerability scanning.
Record the safeguards already in place
For each system and process, note the administrative, physical and technical controls that already protect ePHI, and whether they work as intended. Be candid about controls that exist only on paper: a policy nobody follows is a finding, not a safeguard.
Rate likelihood and impact
Likelihood is the probability that a threat exploits a given vulnerability; impact is the size of the harm if the confidentiality, integrity or availability of ePHI is lost. Use a simple scale, such as low, moderate and high, and define each level in writing so different reviewers rate the same way.
NIST suggests that a business impact analysis helps with impact ratings, because it evaluates and records how critical each organizational asset, including ePHI, is.
Rate the risks, record them and keep the documentation
The output of the analysis is a documented list of risks, each tied to a threat and vulnerability pair, with a rating leadership can act on.
Assign risk levels and build a risk register
Combine each likelihood rating with its impact rating to reach a risk level, for example with a simple matrix. NIST SP 800-66 Rev. 2 suggests recording the results in a risk register: every threat and vulnerability pair, its likelihood and impact ratings, and the overall risk to ePHI.
A useful register also names an owner for each risk and, once treatment is decided, the planned action and target date. NIST recommends sharing the results with leadership, whose decisions drive risk management.
Document the analysis and keep it for 6 years
Section 164.316 requires written (which may be electronic) records of the Security Rule's policies and procedures, and of any action, activity or assessment the rule requires to be documented. Keep that documentation for 6 years from the date it was created or the date it was last in effect, whichever is later, make it available to the people who carry out the procedures, and review it periodically.
- The scope, inventory, data flows and vendors covered
- The method and the rating scales used
- Each threat and vulnerability pair with its likelihood, impact and risk level
- Who performed the analysis, when, and what evidence was used
- Leadership's decision on how each risk will be treated
From risk analysis to risk management
Risk analysis finds and rates risks; risk management, the second required specification, reduces them to a reasonable and appropriate level. NIST SP 800-30 Rev. 1 names the usual responses: accept, avoid, mitigate, share or transfer.
Addressable specifications fit here. Under 164.306(d)(3), each one must be assessed; if it's reasonable and appropriate, it must be implemented, and if not, the organization documents why and implements an equivalent alternative measure if that is reasonable and appropriate. Addressable doesn't mean optional: encryption and decryption at 164.312(a)(2)(iv) is addressable, while unique user identification and an emergency access procedure are required.
When choosing safeguards, 164.306(b)(2) lets an organization weigh its size, complexity and capabilities, its technical infrastructure, the costs of security measures, and the probability and criticality of potential risks to ePHI. Cost is one factor among several. NIST's guidance says that if an unacceptable risk can't be adequately treated in a cost-effective manner, it should be avoided, which may mean significantly redesigning the systems or processes that handle ePHI.
- Mitigate: add or strengthen safeguards, such as multi-factor authentication, encryption, logging or training.
- Avoid: stop or redesign the activity, for example by no longer keeping ePHI on a system that can't be secured.
- Share or transfer: move part of the risk through contracts or insurance; the organization's own Security Rule obligations stay with it.
- Accept: record leadership's decision to accept a risk within its stated risk tolerance, with the reasoning.
How often to do a HIPAA risk assessment
The Security Rule sets no fixed interval for repeating the risk analysis. Three provisions keep it current instead:
- Evaluation, 164.308(a)(8): a periodic technical and nontechnical evaluation, based first on the standards and then in response to environmental or operational changes affecting the security of ePHI.
- Documentation updates, 164.316(b)(2)(iii): review documentation periodically and update it as needed after such changes.
- Maintenance, 164.306(e): review and modify security measures as needed to keep protection reasonable and appropriate.
A practical cadence
NIST SP 800-66 Rev. 2 says risk assessment should be an ongoing activity, not a one-time task, because threats and vulnerabilities change. A practical approach is a full review on a regular schedule, such as yearly, plus a targeted update after significant changes like these. Other programs can set their own cadence; NIST's guide cites the Medicare Promoting Interoperability Program's annual risk assessment requirement.
- A new electronic health record, billing or practice management system
- A new cloud provider, location, merger or acquisition
- A new business associate or subcontractor that handles ePHI
- A security incident or a significant change in how staff work
The HHS SRA Tool and other government resources
The Security Risk Assessment (SRA) Tool from the Office of the National Coordinator for Health IT (ONC) and the HHS Office for Civil Rights (OCR) is a downloadable Windows application, also offered as a spreadsheet workbook, that walks users through the assessment. As of September 27, 2026, the current version is 3.7. Its stated audience is small and medium providers, and it may not be appropriate for larger organizations.
The tool page is direct about its limits: “Use of this tool is neither required by nor guarantees compliance with federal, state or local laws.” NIST SP 800-66 Rev. 2 adds that a tool's output is only as good as the information entered, so an established method should still be followed.
NIST SP 800-66 Rev. 2, Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide (February 2024), is written for regulated entities of all sizes. It contains the risk assessment method summarized above, risk management guidance, and a catalog mapping each Security Rule standard to NIST Cybersecurity Framework outcomes and NIST SP 800-53 controls.
How the 2025 proposed rule would change this
On January 6, 2025, HHS published a proposed rule, HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information (90 FR 898, RIN 0945-AA22). Comments closed on March 7, 2025. As of September 27, 2026, the Federal Register lists only the proposed rule for that RIN; it hasn't been finalized or withdrawn, so the current rule still applies.
Among other changes, HHS proposed requiring written documentation of the policies and procedures used to comply with the Security Rule and of every action, activity or assessment it requires. It also proposed a written technology asset inventory and a network map of how ePHI moves, reviewed at least once every 12 months and when the environment or operations change; HHS said these would illuminate considerations for the risk analysis. Other proposals include removing the distinction between required and addressable specifications, with limited exceptions, and requiring vulnerability scanning at least every six months and penetration testing at least once every 12 months.
If finalized as proposed, a final rule would take effect 60 days after publication, with a standard compliance date 180 days after that.
Recognized security practices
Public Law 116-321, enacted January 5, 2021, requires HHS to consider whether a covered entity or business associate had recognized security practices in place for not less than the previous 12 months when it makes determinations about fines, the length and extent of audits, and agreed remedies under the Security Rule. Recognized security practices include standards and guidelines developed under the NIST Act and approaches under section 405(d) of the Cybersecurity Act of 2015; NIST SP 800-66 Rev. 2 notes that both the NIST Cybersecurity Framework and the 405(d) Health Industry Cybersecurity Practices qualify.
Adopting these practices is voluntary: an entity isn't liable for choosing not to, and the law gives HHS no authority to increase fines or audits because it didn't. The law also doesn't limit enforcement of the Security Rule or change any obligation under it. A risk analysis that maps safeguards to a recognized framework can help show which practices were in place, and for how long.