What does a HIPAA security risk analysis need to cover?

A HIPAA security risk analysis is an accurate and thorough assessment of the risks and vulnerabilities to the confidentiality, integrity and availability of the electronic protected health information (ePHI) an organization holds. The Security Rule requires it of covered entities and business associates, but does not prescribe a method. HHS guidance fills that gap by listing the elements any method must include. This guide walks through those elements, how often to revisit the analysis and what OCR's recent enforcement says about getting it wrong.

What does the Security Rule actually require?

The requirement sits in the security management process standard at 45 CFR 164.308(a)(1). That standard requires policies and procedures to "prevent, detect, contain, and correct security violations," and it has four required implementation specifications:

• Risk analysis (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."
• Risk management (164.308(a)(1)(ii)(B)). Implement security measures sufficient to reduce those risks and vulnerabilities to a reasonable and appropriate level.
• Sanction policy (164.308(a)(1)(ii)(C)). Apply appropriate sanctions to workforce members who do not follow security policies.
• Information system activity review (164.308(a)(1)(ii)(D)). Regularly review records such as audit logs, access reports and security incident tracking reports.

All four are marked "Required," so none can be set aside as addressable. Two other provisions shape how the analysis is done. Section 164.306(b) gives you flexibility in choosing security measures, but requires you to take into account your size, complexity and capabilities, your technical infrastructure, the costs of security measures, and "the probability and criticality of potential risks" to ePHI. Section 164.316(b) requires that any action, activity or assessment the rule requires be documented in writing, which may be electronic.

The risk analysis is not a stand-alone exercise. HHS calls it "the first step" in identifying and implementing safeguards. Its results drive decisions across the rule, including addressable specifications such as encryption, where you must document why a measure is or is not reasonable and appropriate for you (HHS guidance).

Which elements does HHS expect in every risk analysis?

OCR's Guidance on Risk Analysis Requirements under the HIPAA Security Rule states that there is no single method or "best practice" that ensures compliance, and that some example steps are outlined in NIST SP 800-30. It then lists elements that a risk analysis "must incorporate, regardless of the method employed." In order, they are:

1. Scope of the analysis. All ePHI the organization creates, receives, maintains or transmits, on every kind of electronic media. HHS gives examples from a single workstation to complex networks across multiple locations. Location and source do not narrow the scope.

2. Data collection. Identify where ePHI is stored, received, maintained or transmitted. HHS suggests reviewing past and existing projects, interviewing staff and reviewing documentation. What you gather must be documented.

3. Identify and document potential threats and vulnerabilities. List the reasonably anticipated threats, which HHS groups as natural, human and environmental. Then list the technical and non-technical vulnerabilities that a threat could trigger or exploit. Non-technical vulnerabilities include missing or ineffective policies and procedures.

4. Assess current security measures. Document the safeguards in place, whether the measures the rule requires are present, and whether current measures are configured and used properly.

5. Determine the likelihood of threat occurrence. The output should document every threat and vulnerability combination with a likelihood estimate.

6. Determine the potential impact of threat occurrence. Assess the magnitude of harm if a threat exploits a vulnerability. HHS allows qualitative methods, quantitative methods or a combination.

7. Determine the level of risk. Assign a risk level to every threat and vulnerability combination, for example from the likelihood and impact values. The output is the risk levels and a list of corrective actions for each.

8. Finalize documentation. The rule requires the analysis to be documented but does not require a specific format. HHS describes this documentation as "a direct input to the risk management process."

The guidance closes with a ninth point that is not a one-time step: periodic review and updates. The analysis should be ongoing, so you can tell when security measures need to change.

What does the scope need to include in practice?

Scope is where many analyses fall short, because ePHI tends to spread beyond the electronic health record. When we collect data for an analysis, we look for ePHI in:

Where ePHI often lives	What to check
Clinical and practice management systems	Hosting model, who administers them, remote access paths
Email and file sharing	Mailboxes, shared drives, sync clients, external sharing settings
Endpoints	Laptops, desktops, tablets and phones, including personal devices used for work
Medical and connected devices	Imaging, lab and monitoring equipment that stores or transmits data
Backups and archives	On-premises and cloud backups, retention, who can restore
Vendors and business associates	Billing, transcription, IT support, cloud hosting, software providers
Interfaces and exports	Data feeds to labs, payers and portals; spreadsheets and reports

HHS's own sample questions, adapted from NIST SP 800-66, include whether vendors or consultants create, receive, maintain or transmit ePHI. Systems a business associate runs for you still belong in your analysis, and business associates must perform their own analysis of the ePHI they hold.

Many of these locations live in cloud services. If your email and files sit in Microsoft 365, our Microsoft 365 hardening baseline is a useful companion when you assess current security measures.

How often should the risk analysis be updated?

The Security Rule does not set a fixed interval. HHS guidance says the rule "does not specify how frequently to perform risk analysis," and that some organizations perform it annually or as needed, depending on their environment. The rule itself sets two related duties:

• Documentation updates (164.316(b)(2)(iii)). Review documentation periodically, and update it as needed, in response to environmental or operational changes affecting the security of ePHI.
• Evaluation (164.308(a)(8)). Perform a periodic technical and nontechnical evaluation, including in response to environmental or operational changes, of how well your security policies and procedures meet the rule.

HHS lists triggers that should prompt a fresh look at risk: a security incident, a change in ownership, turnover in key staff or management, and plans to adopt new technology. Reviewing the analysis at least yearly, and again whenever one of those triggers occurs, leaves far less to reconstruct when a regulator or auditor asks for it.

Keep each version. Section 164.316(b)(2)(i) requires required documentation to be retained for six years from the date of its creation or the date when it last was in effect, whichever is later.

Why does OCR keep citing risk analysis failures?

OCR, the HHS office that enforces the HIPAA Rules, runs what it calls its Risk Analysis Initiative, a series of enforcement actions focused on this requirement. Its March 5, 2026 settlement with MMG Fusion, a software company acting as a business associate, is one example. Among the potential violations OCR listed was failing to conduct an accurate and thorough risk analysis of the ePHI the company held (HHS).

The corrective action plan in that settlement shows what OCR expects once it is involved. The company committed to:

1. Conduct an accurate and thorough risk analysis of the potential risks and vulnerabilities to its ePHI.
2. Develop and implement a risk management plan to address the risks identified.
3. Periodically conduct, and update as needed, the risk analysis and risk management plan.

Those three commitments mirror the rule. They are also the work an organization can do on its own terms before an investigation, instead of under a monitored plan after one.

What would the proposed Security Rule change?

On January 6, 2025, HHS published a notice of proposed rulemaking to modify the Security Rule (90 FR 898). The comment period closed on March 7, 2025. As of late October 2026, the Federal Register shows it as a proposed rule, and no final rule has been published. The current Security Rule remains in force.

The proposal would make risk analysis more prescriptive. Among other changes, HHS proposed:

• A written technology asset inventory and a network map showing how ePHI moves into, through and out of your electronic information systems, reviewed at least once every 12 months and when your environment or operations change.
• A written risk analysis with specified content, including threats, vulnerabilities, current security measures, likelihood, impact and risk level for each threat and vulnerability, plus an assessment of risks from business associate arrangements, reviewed at least once every 12 months.
• Removing the choice not to implement an addressable specification, so organizations would implement it or adopt a documented reasonable alternative.

The proposal could change before any final rule, or not be finalized. Most of the proposed risk analysis content already appears in the 2010 HHS guidance, so an analysis built on those elements now is unlikely to be wasted work.

Which tools and frameworks can help?

HHS does not endorse a particular risk analysis model. Three public resources are widely used:

• NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments. HHS guidance draws its definitions of threat, vulnerability and risk from SP 800-30, and points to it for example steps.
• NIST SP 800-66 Rev. 2. Published in February 2024, this resource guide explains how to implement the Security Rule, including risk assessment and risk management activities.
• The HHS Security Risk Assessment Tool. Built by ONC with OCR for small and medium-sized providers. HealthIT.gov notes that it may not suit larger organizations, that its use is not required, and that using it does not by itself establish compliance.

A tool gives your analysis structure. It does not replace accurate scope, interviews with the people who run your systems, or technical evidence. Technical testing such as vulnerability scanning and a penetration test can supply that evidence for the vulnerability and current-measures steps. The current rule does not require either by name.

Where to start

1. Name the owner. Section 164.308(a)(2) requires a designated security official. If no one in the organization has the time or background, a virtual CISO can lead the work while leadership keeps oversight.
2. Inventory your ePHI. List every system, device, vendor and data flow that touches it, using the table above as a prompt.
3. Work through the HHS elements. Document threats, vulnerabilities and current measures, then rate likelihood, impact and risk level for each combination.
4. Write the risk management plan. Assign an owner and target date to each corrective action, starting with the highest risks.
5. Set the review cycle. Schedule a periodic review, list the change triggers that prompt an earlier one, and keep each version for six years.

Our HIPAA risk analysis and compliance work covers each of these steps, and our notes for healthcare organizations cover the sector's wider security pressures. If you want a second view on whether your current analysis would hold up, talk to us.