HIPAA Risk Assessment: Required Steps Under the Security Rule

HIPAA Risk Assessment: Required Steps Under the Security Rule

TL;DR

• The HIPAA Security Rule at 45 CFR 164.308(a)(1)(ii)(A) requires every covered entity and business associate to conduct an accurate and thorough risk analysis. This is a required implementation specification — there is no addressable alternative.
• Your risk analysis must cover the confidentiality, integrity, and availability of all ePHI your organization creates, receives, maintains, or transmits.
• OCR's published guidance identifies nine elements a complete risk analysis must address. Missing any one of them gives OCR grounds to call the analysis insufficient during an investigation.
• Risk analysis and risk management are two distinct requirements at (a)(1)(ii)(A) and (a)(1)(ii)(B). The analysis identifies and rates risks. Risk management is what you do about them. Both are mandatory.
• OCR settlement agreements frequently cite inadequate risk analysis. In 2024, Refuah Health Center paid a $450,000 settlement plus a $1.2 million cybersecurity investment requirement after a ransomware breach exposed 260,740 individuals' records, with risk analysis failures among the cited violations.

Who this is for

This guide is for privacy officers, security managers, compliance leads, and practice administrators at covered entities and business associates who need to build, update, or defend a HIPAA risk analysis. It focuses on the legal requirement, the methodology, and the documentation OCR expects to see — not on general security best practices.

What the Security Rule Actually Requires

The HIPAA Security Rule, codified at 45 CFR Part 164, Subpart C, applies to all covered entities and business associates. The risk analysis requirement sits at 45 CFR 164.308(a)(1)(ii)(A):

"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."

Two words in that sentence carry the most weight in enforcement actions: accurate and thorough. OCR does not accept assessments that exclude systems, rely on templates without customization, or treat a vulnerability scan as a substitute for a complete analysis.

Required vs. addressable — where risk analysis sits

The Security Rule divides implementation specifications into two categories. Addressable specifications allow an organization to implement an equivalent alternative if it is reasonable and appropriate for the organization's environment and documents that reasoning. Required specifications allow no such flexibility.

Risk analysis under 164.308(a)(1)(ii)(A) is required. So is risk management under 164.308(a)(1)(ii)(B). There is no alternative pathway, no size exemption, and no option to defer.

The January 2025 NPRM

HHS published a proposed rule in January 2025 (NPRM, HHS press release, Jan. 6, 2025) that would eliminate the addressable vs. required distinction entirely. Under the proposed rule, all Security Rule safeguards would become mandatory with limited exceptions. The NPRM has not been finalized as of the date of this article, but if it is, every gap your risk analysis identifies will require a written remediation plan — not just documentation that you considered an alternative.

The Nine Elements of a Complete Risk Analysis

HHS OCR has published guidance describing what makes a risk analysis accurate and thorough. That guidance identifies nine elements. An analysis missing any one of them is incomplete:

1. Scope of the analysis — The analysis must cover all ePHI your organization creates, receives, maintains, or transmits. This includes ePHI stored in all media types, all locations, and all systems — not just the EHR.

1. Data collection — You must document where ePHI flows: at rest, in transit, in backup systems, and in any temporary or incidental storage locations.

1. Identify and document threats — Identify reasonably anticipated threats to ePHI. The NIST SP 800-30 Rev. 1 threat catalog groups these as adversarial (ransomware, insider theft), accidental (misdirected email, misconfiguration), structural (hardware failure, software bugs), and environmental (power outage, natural disaster).

1. Identify and document vulnerabilities — Document weaknesses in your systems, processes, or training that a threat could exploit. This must include administrative, physical, and technical vulnerabilities, not only those discovered through network scanning.

1. Assess current controls — Document safeguards already in place and evaluate their effectiveness.

1. Determine the likelihood of threat occurrence — For each threat-vulnerability pair, estimate the probability that the threat exploits the vulnerability given existing controls.

1. Determine the potential impact — Assess the magnitude of harm if the threat exploits the vulnerability, including impact on the confidentiality, integrity, and availability of ePHI.

1. Determine the level of risk — Combine likelihood and impact to produce a risk rating for each identified risk.

1. Finalize documentation — Document the process, results, and actions taken. All personnel involved in the process should be identified, and management must review and sign off on the findings.

Scope and Asset Inventory

Getting the scope right is where many risk analyses fail before they reach the threat identification step.

Your inventory needs to include every system, application, and workflow that creates, receives, maintains, or transmits ePHI. That means:

• EHR systems and all connected modules, including patient portals and clinical decision support tools
• Cloud services — IaaS, PaaS, and SaaS platforms handling PHI (see our guide to HIPAA compliance for SaaS environments for what to document for each)
• Medical devices that store or transmit patient data, including imaging systems and connected monitors
• Mobile devices — phones, tablets, laptops, and removable media used by workforce members
• Communication systems — email servers, messaging platforms, telehealth tools, and fax infrastructure
• Backup and disaster recovery systems
• Business associate systems that receive ePHI from your organization

Create a data flow diagram that traces how ePHI moves between these components. This step regularly surfaces risks that were unknown before the analysis: unencrypted transfers between internal systems, ePHI stored in unapproved locations, or legacy platforms that IT had forgotten were still active.

For organizations managing more than a handful of systems, a living asset inventory becomes difficult to maintain manually. Many compliance teams use GRC software platforms to keep the inventory current and link it directly to risk records.

Identifying Threats and Vulnerabilities

Threat sources

Use an established catalog rather than building one from memory. NIST SP 800-30 Rev. 1, Appendix D provides a threat source taxonomy that OCR has consistently cited as an acceptable methodology. The four categories are:

• Adversarial — Ransomware operators, external attackers, disgruntled insiders, nation-state actors
• Accidental — Staff sending ePHI to the wrong recipient, misconfigured access controls, lost devices
• Structural — Hardware failures, software bugs, network outages
• Environmental — Power outages, floods, HVAC failures in server rooms

For each threat source, you need to document the threat's motivation or capability and the likelihood that it will attempt to exploit a vulnerability.

Vulnerabilities

A vulnerability is a weakness that a threat could exploit. Common examples in healthcare settings include:

• Servers and workstations running unpatched operating systems
• Workforce members who have not completed security awareness training
• Absence of multi-factor authentication on remote access systems
• Incomplete or missing audit logging
• Business associate agreements that lack required Security Rule provisions

OCR has consistently emphasized in enforcement actions that administrative and physical vulnerabilities matter as much as technical ones. An organization with strong network segmentation but no workforce training program still has material gaps.

Risk Rating and Prioritization

Once you have identified your threat-vulnerability pairs, assign a risk level to each using a likelihood-impact matrix. NIST SP 800-30 provides a three-tier scale that maps well to the Security Rule's language, though you may use any defensible scale as long as you document the methodology.

Example likelihood scale:

Example impact scale:

Combine these ratings to produce an overall risk level. High-likelihood, high-impact risks go to the top of your remediation queue. Low-likelihood, low-impact risks may warrant monitoring without immediate action, but must still be documented with that decision recorded.

Risk treatment options

For each identified risk, you have four responses:

1. Mitigate by implementing additional controls
2. Transfer through cyber insurance or contractual arrangements with third parties
3. Accept with documented management justification
4. Avoid by eliminating the activity or system that creates the risk

Every treatment decision must be documented. OCR does not expect organizations to achieve zero residual risk. What OCR expects is that every identified risk received a documented, informed decision — and that high-rated risks received prompt attention.

Documentation: What OCR Expects to Find

HIPAA does not prescribe a specific format. What it requires is that your documentation supports a finding that the analysis was accurate and thorough. In practice, OCR's investigations look for six things:

1. Methodology description. Explain what framework you used (NIST SP 800-30, NIST SP 800-66 Rev. 2, or equivalent), how you collected data, and how you calculated risk levels.

2. Asset inventory. A complete list of systems and data flows in scope, with the ePHI types each handles.

3. Threat and vulnerability catalog. Every identified threat-vulnerability pair, with supporting evidence for the likelihood and impact ratings.

4. Risk register. A centralized record of all identified risks, their ratings, assigned owners, and remediation status.

5. Management sign-off. Evidence that organizational leadership reviewed and approved the findings. This is not a formality — OCR scrutinizes whether leadership was actually engaged.

6. Remediation tracking. Documentation that you acted on findings. Identifying risks and filing the report without follow-through is, in enforcement terms, worse than a partial analysis: it establishes that the organization knew about the risks and chose not to address them.

Retention

The Security Rule requires retention of risk assessment documentation for a minimum of six years from the date of creation or the date it was last in effect, whichever is later. This derives from the general documentation retention requirement at 45 CFR 164.530(j).

Common Mistakes in HIPAA Risk Analyses

Treating it as a one-time event. The Security Rule requires an ongoing process. OCR's guidance states that risk analyses must be updated "regularly" and in response to environmental or operational changes. Most compliance programs target an annual full analysis with interim updates when significant changes occur: new systems, mergers, material incidents, or onboarding new business associates.

Confusing a vulnerability scan with a risk analysis. Running Nessus, Qualys, or a similar tool against your network is a useful input to the technical vulnerability identification step. It is not a risk analysis. A scanner does not assess administrative safeguards, physical controls, workforce training gaps, or business associate risks. It does not produce likelihood and impact ratings. It does not generate a risk register. A scan can supplement a risk analysis; it cannot replace one.

Excluding business associates. Your risk analysis must account for risks that business associates introduce. If a vendor stores your ePHI in a cloud environment with weak access controls, that risk belongs in your register. Business associate agreements are required under the Privacy and Security Rules, but they do not transfer your risk — they allocate responsibility.

Using generic templates without customization. Pre-built risk assessment templates can provide structural guidance. Submitting one with organization name fields filled in but no customization to reflect your actual environment does not constitute a thorough analysis. OCR's investigations look at whether the threats and vulnerabilities identified are plausible for the specific organization, and template answers that do not reflect real systems are a visible signal that the process was not genuinely performed.

Failing to include the right people. A risk analysis conducted only by IT misses clinical workflow risks and physical security gaps. One conducted only by compliance misses technical vulnerabilities. A thorough analysis requires input from IT, clinical operations, privacy officers, facilities management, and executive leadership. The methodology documentation should name who participated.

Identifying risks and taking no action. An organization that documents 40 high-rated risks and then does nothing about them has created a record of awareness without response. In OCR enforcement actions, that pattern — documented knowledge plus inaction — typically results in higher penalties than incomplete documentation would have.

Tools That Support the Process

HHS Security Risk Assessment (SRA) Tool. Free, developed jointly by ONC and OCR, available at healthit.gov. Covers administrative, physical, and technical safeguards through structured questions. The tool itself states that it is designed for small to medium-sized providers and "may not be appropriate for larger organizations." It is a solid starting point for smaller practices. It does not provide ongoing risk management tracking, integration with asset inventories, or scalability for multi-location organizations.

NIST SP 800-30 Rev. 1. The foundational methodology for information system risk assessments, published September 2012. Free to download from csrc.nist.gov. OCR has consistently cited it as an acceptable approach.

NIST SP 800-66 Rev. 2. Published February 2024, this guide specifically addresses HIPAA Security Rule implementation for regulated entities of all sizes. It maps HIPAA requirements to concrete implementation activities and cross-references the NIST Cybersecurity Framework. Available from csrc.nist.gov.

GRC platforms. For organizations managing risk assessments across multiple locations or business units, dedicated governance, risk, and compliance software handles ongoing data collection, risk scoring, evidence linking, and reporting. See our comparison of GRC software platforms for an overview of options by organization size.

Penetration testing and vulnerability scanning tools. Nessus, Qualys, Rapid7 InsightVM, and similar tools provide technical vulnerability data that feeds into the vulnerability identification step. They are inputs to a risk analysis, not substitutes.

Frequently Asked Questions

How often does the HIPAA Security Rule require a risk analysis?

The Security Rule does not state a fixed frequency. OCR's guidance describes risk analysis as an "ongoing process" that must be updated when environmental or operational changes affect ePHI. Most compliance programs treat this as: a full analysis annually, plus an interim update for any material change (new system, merger, security incident, new business associate relationship). The January 2025 NPRM would formalize an annual requirement if finalized, but that rule has not taken effect.

Can we use the HHS SRA Tool to satisfy the requirement?

The SRA Tool covers the core requirements of the Security Rule and can satisfy the requirement for small to medium-sized practices, with caveats. The tool itself states that it "may not be appropriate for larger organizations" and explicitly notes that its use "neither required by nor guarantees compliance with federal, state or local laws." For organizations with complex environments, multiple locations, or extensive business associate networks, the SRA Tool does not scale. It also does not support ongoing risk management tracking — completing the tool does not replace a risk register or remediation plan.

Does the risk analysis require a third-party assessor?

No. The Security Rule does not require external consultants. Internal staff with relevant qualifications can conduct a defensible analysis. That said, external assessors bring documented objectivity, which carries weight when OCR investigates — an internal analysis conducted by the same team that owns the systems being assessed faces obvious conflict-of-interest questions. Many organizations alternate: internal reviews annually, with an external assessment every two or three years.

What is the difference between a risk assessment and a gap analysis?

A gap analysis compares your current security posture against a defined set of requirements — such as the HIPAA Security Rule safeguards — and identifies where you fall short. It answers: what are we missing? A risk analysis goes further: it evaluates threat sources, vulnerabilities, likelihood, and potential impact to produce risk ratings. It answers: what could go wrong, how likely is it, and how bad would it be? Gap analyses are useful diagnostic tools. Only the risk analysis satisfies the 45 CFR 164.308(a)(1)(ii)(A) requirement.

What are the penalties for failing to conduct an adequate risk analysis?

Civil monetary penalties under HIPAA are tiered by culpability. Based on 2026 inflation-adjusted figures published by HHS, Tier 1 (reasonable efforts, no knowledge of violation) starts at $145 per violation with an annual cap of $2,190,294. Tier 4 (willful neglect, not corrected) starts at $73,011 per violation, with the same annual cap applying per violation category. Beyond civil penalties, OCR frequently requires corrective action plans with mandatory reporting obligations for one to three years. Advocacy Health Care Network settled for $5.5 million in a case that included risk analysis failures; North Memorial Health Care paid $1.5 million in March 2016 for the same underlying issue.

Sources

1. 45 CFR 164.308(a)(1)(ii)(A) — HIPAA Security Rule, Administrative Safeguards, Risk Analysis. Electronic Code of Federal Regulations. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308

1. HHS, "HIPAA Security Rule." U.S. Department of Health & Human Services. https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html

1. NIST Special Publication 800-30 Rev. 1, "Guide for Conducting Risk Assessments," September 2012. National Institute of Standards and Technology. https://csrc.nist.gov/pubs/sp/800/30/r1/final

1. NIST Special Publication 800-66 Rev. 2, "Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource Guide," February 2024. National Institute of Standards and Technology. https://csrc.nist.gov/pubs/sp/800/66/r2/final

1. HHS, "HHS Proposes Modifications to the HIPAA Security Rule to Strengthen Cybersecurity of the Health Care Sector," January 6, 2025. https://www.hhs.gov/about/news/2025/01/06/hhs-proposes-modifications-hipaa-security-rule-strengthen-cybersecurity-health-care.html

1. ONC/OCR, "Security Risk Assessment Tool," healthit.gov. Accessed 2026-05-12. https://www.healthit.gov/topic/privacy-security-and-hipaa/security-risk-assessment-tool

1. HIPAA Journal, "HIPAA Enforcement," accessed 2026-05-12. https://www.hipaajournal.com/hipaa-enforcement/ (Refuah Health Center $450K settlement; Comstar LLC $75K OCR settlement; Advocate Health Care Network $5.5M settlement; North Memorial Health Care $1.5M settlement)

1. HIPAA Journal, "HIPAA Violation Fines," accessed 2026-05-12. https://www.hipaajournal.com/hipaa-violation-fines/ (2026 inflation-adjusted civil money penalty tiers)

1. 45 CFR 164.530(j) — Documentation retention requirement. Electronic Code of Federal Regulations. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.530

Sources used

1. 45 CFR 164.308(a)(1)(ii)(A) — accessed 2026-05-12
2. 45 CFR Part 164, Subpart C — accessed 2026-05-12
3. NPRM, HHS press release, Jan. 6, 2025 — accessed 2026-05-12
4. NIST SP 800-30 Rev. 1 — accessed 2026-05-12
5. 45 CFR 164.530(j) — accessed 2026-05-12
6. healthit.gov — accessed 2026-05-12
7. csrc.nist.gov — accessed 2026-05-12
8. 2026 inflation-adjusted figures published by HHS — accessed 2026-05-12

Last reviewed: 2026-05-12. This article was prepared by the Security Compliance Guide Editorial Team. We use AI to draft initial summaries of publicly available cybersecurity compliance documentation, then verify every claim against primary sources before publication. We are not licensed auditors, attorneys, or compliance consultants. For binding decisions, consult a qualified professional. See our editorial standards for full sourcing rules.