The Risk Analysis: What OCR Expects, How to Do One, and Why Organizations Fail

Rule versions described: the HIPAA Security Rule at 45 CFR Part 164, Subpart C, as first published February 20, 2003 (68 FR 8334) and amended by the Omnibus Rule of January 25, 2013 (78 FR 5566), current eCFR text read October 28, 2026; OCR's Guidance on Risk Analysis of July 14, 2010 (page last reviewed August 12, 2026); NIST SP 800-30 Rev. 1 (September 2012) and NIST SP 800-66 Rev. 2 (February 14, 2024); and the proposed Security Rule update (90 FR 898, January 6, 2025), which is not final. Rules and guidance change. Check the regulator's current text before relying on any point.

Ask a HIPAA investigator which single document matters most in a security case, and the answer will almost always be the risk analysis. It is the first thing OCR, the Office for Civil Rights at the U.S. Department of Health and Human Services (HHS), asks for after a ransomware attack, a stolen laptop or a hacked email account. It is the document most often missing, outdated or too thin to count. And it is the foundation for almost every other decision the Security Rule asks an organization to make, from whether to encrypt laptops to how fast to patch a server.

This lesson goes deeper than a general risk assessment course. If you want the general method for assessing business risk and mapping data in any small or medium business, start with Privacy and Security for Small and Medium Businesses, lesson 3: Risk Assessment and Data Mapping, and for the major frameworks (NIST CSF, CIS Controls, ISO 27001, SOC 2), see lesson 4: Security Frameworks and Standards. Module 109 adds the HIPAA-specific parts: what the regulation says word for word, what OCR expects to see, which federal tools exist for health care, how the proposed rule would change things, and how the enforcement cases play out. For the safeguards themselves, see lesson 3 on the Security Rule and the proposed update. For a start-to-finish example in a small practice, see lesson 9, the small clinic walkthrough. If HIPAA itself is new to you, read the overview in Privacy and Data Security Laws, lesson 3: Health Privacy, HIPAA and Beyond first.

Why the risk analysis matters more than any other HIPAA document

The Security Rule is deliberately flexible. It does not tell a three-doctor clinic and a 40-hospital system to buy the same products or follow the same steps. Instead, it tells each organization to figure out its own risks and choose "reasonable and appropriate" protections, considering its size, complexity, technical setup, costs, and the probability and criticality of the risks it faces.¹⁰ That flexibility has a price: an organization can only justify its choices if it has done the analysis that the choices are supposed to rest on.

That is why the risk analysis sits at the center of so many decisions:

• Addressable specifications. About half of the Security Rule's implementation specifications are labeled "addressable," which does not mean optional. For each one, the organization must assess whether it is reasonable and appropriate; if it is not, the organization must document why and put in place an equivalent measure if one is reasonable.¹⁰¹¹ That assessment is a product of the risk analysis. Encryption at rest, for example, is addressable today. An organization that skips it without a documented risk-based reason is exposed.
• Risk management. The organization must reduce risks "to a reasonable and appropriate level." It cannot know what is reasonable without first measuring the risk.¹
• Breach investigations. When OCR investigates a breach report, it routinely asks for the most recent risk analysis and the ones before it. The question is whether the organization had identified the weakness the attacker used, and if so, what it did about it.
• Penalties. Federal law requires HHS to consider recognized security practices in place during the prior 12 months when setting fines and audit outcomes.⁹ A documented risk analysis tied to such practices is the best evidence an organization can offer.

The record shows how often organizations fall short. In OCR's 2016 to 2017 audit program, the most recent audit round for which OCR has published results, auditors rated 63 covered entities on the risk analysis requirement. None received the top rating of 1 (fully compliant) and only 9 (14 percent) received a 2. On risk management, only 4 of 63 covered entities (6 percent) rated a 1 or 2. Among 41 business associates, 7 (17 percent) rated 1 or 2 on risk analysis. The report, released in December 2020, said entities "generally failed to" identify and assess the risks to all of the ePHI in their possession, and that some "incorrectly assumed that a purchased security product satisfied all Security Rule requirements."¹² OCR's report to Congress for 2024 says "OCR did not initiate any audits in 2024 due to a lack of financial resources."¹³ Around the turn of 2025, trade press reported that OCR planned to resume audits of 50 covered entities and business associates, focused on "selected provisions of the HIPAA Security Rule most relevant to hacking and ransomware attacks."¹⁴ This lesson found no published results from that round as of October 28, 2026. So for now, most enforcement still comes from complaints, breach reports and the targeted Risk Analysis Initiative described below.

Source: OCR, 2016 to 2017 HIPAA Audits Industry Report, December 2020. Percentages as printed by OCR; they may not total 100 because of rounding.¹²

What the rule actually requires

The Security Management Process standard

The risk analysis lives in the first administrative safeguard, the Security Management Process standard at 45 CFR 164.308(a)(1)(i), which requires covered entities and business associates to "implement policies and procedures to prevent, detect, contain, and correct security violations." Under it sit four implementation specifications, all four labeled required:¹

1. 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."
2. Risk management, 164.308(a)(1)(ii)(B): "Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with" the general requirements of 164.306(a).
3. Sanction policy, 164.308(a)(1)(ii)(C): apply appropriate sanctions against workforce members who fail to comply with security policies.
4. Information system activity review, 164.308(a)(1)(ii)(D): regularly review records of system activity, such as audit logs, access reports and security incident tracking reports.

The text has been essentially the same since the original Security Rule was published on February 20, 2003, with compliance required by April 20, 2005 for most covered entities.¹⁵ The 2013 Omnibus Rule added "or business associate," making business associates directly responsible for doing their own risk analysis rather than only promising to protect data by contract.¹⁶

Reading the words closely

Each phrase in the risk analysis specification carries weight, and OCR's guidance and enforcement records treat them that way:

• "Accurate and thorough." Accurate means the analysis matches reality: the systems listed exist, the controls described are actually turned on, the vendors named are the ones in use. Thorough means nothing that holds ePHI is left out. OCR's resolution agreements regularly use the phrase "failed to conduct an accurate and thorough risk analysis" as the finding.⁶¹⁷
• "Potential risks and vulnerabilities." The analysis looks forward. It is about what could happen, not only what has happened.
• "Confidentiality, integrity, and availability." The analysis covers all three. A ransomware attack that encrypts the EHR (electronic health record) is an availability and integrity problem even if no data leaves the building. Clinics that think of HIPAA only as privacy tend to skip availability risks, such as untested backups or a single internet connection.
• "Electronic protected health information." ePHI is protected health information transmitted by or maintained in electronic media.¹⁸ The Security Rule covers only ePHI. Paper charts and spoken conversations fall under the Privacy Rule's general safeguards requirement instead, though many organizations include them in one combined assessment anyway.
• "Held by." OCR reads this broadly to mean all ePHI the organization creates, receives, maintains or transmits, wherever it sits, including on vendors' systems, laptops at home and phones in pockets.²

Documentation and retention under 164.316

The risk analysis must be in writing. 45 CFR 164.316 requires organizations to keep the policies and procedures used to comply with the Security Rule in written form (which may be electronic), and to keep a written record of any action, activity or assessment the rule requires.¹⁹ Three implementation specifications, all required, apply to that documentation:

• Time limit: keep it for 6 years from the date of its creation or the date it was last in effect, whichever is later. A 2019 risk analysis that was replaced in 2023 must be kept until 2029.
• Availability: make it available to the people responsible for carrying out the procedures it covers.
• Updates: review it periodically and update it as needed in response to environmental or operational changes affecting the security of ePHI.

In practice, this means an organization under investigation can be asked for every risk analysis from the past six years. A single analysis done in 2018 and never touched again is a common finding. So is a folder of old reports with no record of what was done about them.

Flexibility is not an exemption

Small organizations sometimes read the Security Rule's flexibility as a pass. It is not. Section 164.306(b) lets an organization consider its size, complexity and capabilities; its technical infrastructure, hardware and software; the costs of security measures; and the probability and criticality of potential risks.¹⁰ Every one of those factors requires analysis to apply. OCR's guidance says small organizations "tend to have more control within their environment" and fewer variables to consider, so their analysis may be simpler, but it must still exist and still cover all ePHI.² OCR has settled with practices as small as Northeast Surgical Group ($10,000, January 15, 2025) and software vendors such as MMG Fusion ($10,000, March 5, 2026), each with a corrective action plan monitored by OCR (three years in MMG's case).²⁰²¹

Analysis versus management: two different jobs

The two required specifications are easy to blur, and OCR cites them separately. Risk analysis is diagnosis: find and rate the risks. Risk management is treatment: decide what to do about each risk, do it, and track it. NIST SP 800-66 Rev. 2 puts it this way: the risk analysis produces "a listing of applicable threat/vulnerability pairs as well as the overall risk rating of each pair," and risk management decides which of those exceed the organization's risk tolerance and must be reduced.⁴ An organization can have an excellent analysis and still fail the management requirement if the findings sit in a drawer. Several OCR corrective action plans require both: a new analysis, then a written, organization-wide risk management plan to address what it finds.²²²³²⁴

A risk analysis is not a gap assessment or a compliance checklist

Three documents are often confused. Each has value, but only one satisfies 164.308(a)(1)(ii)(A).

The difference shows up in enforcement. A gap assessment might say "access control: met, unique user IDs in place." A risk analysis asks what happens if a front desk login shared by three people is phished, rates that scenario, and records it. Ambry Genetics, which paid $700,000 in September 2026, was cited both for an inadequate risk analysis and for not assigning unique user IDs; a real risk analysis is meant to surface exactly that kind of weakness before an attacker does.²³

OCR's 2010 guidance: the nine elements

On July 14, 2010, OCR published its Guidance on Risk Analysis Requirements under the HIPAA Security Rule, the first in a planned series of Security Rule guidance materials. HHS still posts it, and the page was last reviewed August 12, 2026.² It is short, and it is the closest thing to an official checklist of what a risk analysis must contain. It does not mandate a method. It says there is "no single method or 'best practice' that guarantees compliance with the Security Rule," and that the guidance is "not intended to provide a one-size-fits-all blueprint."² But it lists elements that OCR expects every risk analysis to include, whatever method is used.

The guidance borrows its vocabulary from NIST. A vulnerability is "[a] flaw or weakness in system security procedures, design, implementation, or internal controls" that could be exercised and result in a security breach; vulnerabilities can be technical (a server missing patches) or non-technical (no written procedure for ending a former employee's access). A threat is the potential for a person or thing to exercise a specific vulnerability; threats may be natural (floods, fires), human (hackers, careless staff, dishonest insiders) or environmental (power failures, water leaks). Risk is a function of the likelihood that a given threat will exercise a particular vulnerability and the resulting impact on the organization.²³

Element 1: scope that covers all ePHI

The analysis must cover all ePHI the organization creates, receives, maintains or transmits, in all forms of electronic media, such as hard drives, CDs and DVDs, smart cards and other storage devices, personal digital assistants (today, smartphones and tablets), portable media and transmission media.² This is where most failed analyses go wrong. Typical gaps: the analysis covers the EHR but not the billing server; covers the main office but not the satellite clinic; covers company devices but not the provider who charts from a personal tablet; covers systems the clinic runs but not the ones vendors run on its behalf. Version 3.7 of the HHS SRA Tool added a scope question asking about every location where ePHI is handled for exactly this reason.⁵

Element 2: data collection

"An organization must identify where the e-PHI is stored, received, maintained or transmitted," the guidance says. Methods include reviewing past and existing projects, interviewing staff, and reviewing documentation.² In a small practice, that means walking the office, opening the server closet, looking at what is plugged into the network, reading vendor contracts and asking each person how they actually do their job. The front desk will tell you about the scanner that emails documents to a shared inbox; the billing lead will tell you about the spreadsheet of unpaid accounts on her desktop. The section on asset inventories below explains what to collect.

Element 3: identify and document threats and vulnerabilities

Organizations "must identify and document reasonably anticipated threats to e-PHI," and the vulnerabilities that, if exploited, could lead to a risk of improper access or disclosure.² "Reasonably anticipated" is the test. For health care in 2026, the federal government's own list of the most common threats is a good start. The HHS 405(d) program's Health Industry Cybersecurity Practices (HICP, 2023 edition) names five: social engineering (phishing), ransomware, loss or theft of equipment or data, insider data loss (accidental or malicious), and attacks against network connected medical devices that may affect patient safety.²⁵ OCR's own breach statistics point the same way: in calendar year 2024, hacking or IT incidents accounted for 534 of 663 large breach reports (81 percent) and 99 percent of the people affected.²⁶ Natural and environmental threats (fire, flood, extended power loss, a failed internet line) belong on the list too, because availability is part of the requirement.

Element 4: assess current security measures

The organization should assess and document the security measures it uses, and whether they are configured and used properly.² The words "configured and used properly" matter. Multi-factor authentication (MFA) that is licensed but switched off for some accounts is not a control. A backup that has never been restored is an assumption, not a measure. A policy that staff have never read does not reduce risk. This is the place for a gap assessment against the Security Rule standards or a framework, and for technical evidence such as vulnerability scan results.

Element 5: determine the likelihood of threat occurrence

"The Security Rule requires organizations to take into account the probability of potential risks to e-PHI," the guidance says, and the output should document all threat and vulnerability combinations with likelihood estimates.² Likelihood is usually rated on a scale (high, medium, low, or 1 to 5) using evidence: how often this kind of attack hits similar organizations, whether there have been near misses, how exposed the system is, and how strong existing controls are.

Element 6: determine the potential impact

Impact is the harm if the threat succeeds: unauthorized access to or disclosure of ePHI, permanent loss or corruption of ePHI, temporary loss or unavailability, and loss of physical assets. The guidance allows "either a qualitative or quantitative method or a combination of the two methods."² In health care, impact includes patient safety (a clinic that cannot see allergies or medication lists), the number of patients affected, the sensitivity of the data (substance use disorder records, mental health notes, HIV status), legal notice duties, and the cost of downtime.

Element 7: determine the level of risk

The organization assigns a risk level to each threat and vulnerability combination, for example by "assigning a risk level based on the average of the assigned likelihood and impact levels," and lists the corrective actions to be performed to reduce each level.² Many organizations multiply instead of averaging (a 1 to 5 likelihood times a 1 to 5 impact gives a score from 1 to 25), and NIST shows a lookup matrix. Any of these can work if it is defined in writing and applied consistently.

Element 8: finalize documentation

"The Security Rule requires the risk analysis to be documented but does not require a specific format."² The documentation is what OCR will read, and it feeds directly into the risk management plan. It should show the method, the scope, who took part, the inventory, the threat and vulnerability pairs, the ratings and the reasoning behind them, and the date.

Element 9: periodic review and updates

The process should be ongoing. The current rule "does not specify how frequently to perform risk analysis," and the guidance notes that some organizations review annually or as needed, such as every two or three years, depending on circumstances. It also lists events that should prompt an update: security incidents, changes in ownership, turnover in key staff or management, and plans to bring in new technology or business operations.² As explained below, the January 2025 proposed rule would replace that flexibility with a firm "at least once every 12 months" floor, if it is finalized.⁷

The NIST SP 800-30 method in plain terms

OCR's guidance cites NIST Special Publication 800-30, and most professional HIPAA risk analyses follow some version of it. Revision 1, Guide for Conducting Risk Assessments, was published in September 2012 and remains current.³ It was written for federal agencies, so parts of it are heavy going, but the core method fits on one page.

The four steps

1. Prepare for the assessment. Decide the purpose (a first baseline, an update after a merger, a check on a new system), the scope (which offices, systems and vendors), the assumptions and constraints, the sources of threat and vulnerability information, and the risk model and scales you will use. Writing these down first is what makes the results comparable from year to year.
2. Conduct the assessment. NIST breaks this into six tasks: identify threat sources; identify threat events those sources could cause; identify vulnerabilities and predisposing conditions; determine likelihood; determine impact; and determine risk as a combination of the two.
3. Communicate the results. Share the findings with the people who make decisions and the people who will fix things, in a form they can use. NIST's Appendix K gives a sample outline for a risk assessment report.
4. Maintain the assessment. Monitor the risk factors over time and update the assessment when things change, rather than starting from scratch each time.

Sources, events and predisposing conditions

NIST separates the threat source (who or what: a criminal ransomware group, a careless employee, a storm) from the threat event (what happens: a phishing email that steals a password, a misaddressed fax, a burst pipe over the server). It also adds the idea of a predisposing condition, a feature of the organization or its setting that makes an event more or less likely to cause harm, such as a clinic in a flood plain, or a stand-alone system with no network connection, which lowers the chance of a network attack.³⁴ Appendices D through F of SP 800-30 list sample threat sources, threat events and vulnerabilities, and are useful prompts when a team is staring at a blank page.

Scales and tiers

SP 800-30 offers qualitative scales (very low, low, moderate, high, very high), semi-quantitative scales (for example 0 to 10 or 0 to 100 mapped onto those labels), and fully quantitative methods.³ Most health care organizations use qualitative or semi-quantitative scales, because hard probability data for a specific clinic rarely exists. NIST also describes three tiers at which risk can be assessed: the organization as a whole, the mission or business process, and the individual information system. A hospital system will work at all three; a small practice mostly works at the system and process level, with the owner making the organization-level decisions about how much risk is acceptable.

NIST SP 800-66 Rev. 2: the HIPAA companion

On February 14, 2024, NIST published Revision 2 of SP 800-66, Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource Guide, replacing the 2008 Revision 1.⁴ It is written for HIPAA covered entities and business associates, it is free, and it is the most useful single federal document on doing a HIPAA risk analysis. It does not change the law and is not mandatory, but OCR investigators and outside assessors read it.

A seven-step risk assessment

Section 3.2 adapts the SP 800-30 method into seven steps, noting that "there is no single methodology that will work for all regulated entities" and that the steps need not be done in strict order:⁴

1. Prepare for the assessment: understand where ePHI is created, received, maintained, processed and transmitted; where it enters (for example through web portals), where it flows, where it is stored and where it leaves. The scope should cover the physical location and a "logical boundary" that includes teleworkers, remote vendors with access, removable media, laptops and mobile devices, and medical and Internet of Things devices that store or transmit ePHI. NIST also suggests a business impact analysis to rank how critical each system is.
2. Identify reasonably anticipated threats, specifically including phishing, ransomware and insider threats, using sources such as information sharing and analysis centers (ISACs), vendor information, insurance data and crime statistics.
3. Identify potential vulnerabilities and predisposing conditions, using internal sources (prior assessments, vulnerability scans, penetration tests, audit reports) and external ones (vendor notices, the National Vulnerability Database).
4. Determine the likelihood that a threat will exploit a vulnerability, considering both the chance the threat occurs and the chance it succeeds against existing controls.
5. Determine the impact of a threat exploiting a vulnerability, including harm to individuals, to operations and to the organization's finances and reputation.
6. Determine the level of risk, for example with a risk-level matrix. NIST prints a simple three by three matrix and a more detailed five by five version.
7. Document the results, preferably in a risk register, and share them with leadership, "whose review can be crucial to the organization's ongoing risk management."

A footnote in that section makes a point many readers miss: the preparation step should consider online tracking technologies on websites and apps, and whether portals or other products collect PHI. HHS has separate guidance on tracking tools.⁴²⁷

Risk tolerance and the move to risk management

Section 4 turns the analysis into management. It introduces risk appetite (the broad statement from leadership about how much risk the organization will accept) and risk tolerance (the specific acceptable level; an illustrative tolerance might be that no risk rated moderate or higher may stay untreated beyond 90 days). Any threat and vulnerability pair rated above the tolerance must be addressed. If no reasonable control can bring a risk within tolerance, leadership may revisit the tolerance through a documented exception process, or, if the risk cannot be treated cost-effectively, avoid it, which can mean redesigning a system or process. NIST suggests recording these decisions in the same risk register, with remediation plans, timelines and responsible people.⁴

The key activities for the Security Management Process

Section 5 walks through every Security Rule standard with "key activities," descriptions and sample questions. For the Security Management Process standard, Table 8 lists nine key activities, which make a practical work plan:⁴

Mappings and resources in the appendices

Appendix C has risk assessment tables of sample threat sources and events. Appendix D maps each Security Rule standard and implementation specification to NIST Cybersecurity Framework subcategories and NIST SP 800-53 security controls, which helps an organization that already uses a framework show how it meets HIPAA.⁴ The framework comparison itself is covered in lesson 4 of the small and medium business module. Section 3.4 is also blunt about tools: a questionnaire such as the SRA Tool "cannot identify technical vulnerabilities," so it should be paired with something that can, such as vulnerability scanning, and use of any tool "does not necessarily equate to compliance."⁴

Start with the asset inventory and the data flow map

You cannot assess risks to data you have not found. Both OCR's guidance (elements 1 and 2) and NIST (key activity 1) start with an inventory, and OCR's corrective action plans increasingly spell it out. Bryan County Ambulance Authority's 2024 corrective action plan, for example, required a new accurate and thorough risk analysis that includes a complete asset inventory.²⁴ OCR's recent settlement announcements end with the same first recommendation: map where ePHI resides in your systems and how it enters, moves through and leaves them.¹⁷²² The current Security Rule does not say "inventory" or "map" in its text, but in the preamble to the 2025 proposal HHS wrote that "an accurate and thorough risk analysis requires a regulated entity to perform an inventory of its technology assets," even though the current regulatory text does not say so.⁷

What goes in the inventory

For each system or device that creates, receives, maintains or transmits ePHI, record what it is, what version, where it is, who is responsible for it, what ePHI it holds, who can reach it, and which vendor (if any) runs it. The proposed rule would require exactly these core fields: "identification, version, person accountable, and location of each technology asset."⁷ In a typical small or mid-sized practice, the list includes the categories below. Each is a place where OCR cases and breach reports have found ePHI that an organization forgot it had.

Two vendor points deserve emphasis. First, OCR's cloud computing guidance (October 6, 2016) says a cloud service provider that stores ePHI is a business associate even if it holds only encrypted data and has no key, and that where the provider stores data, including offshore, should be considered in the risk analysis.²⁸ Second, the vendor's risks become your risks. In calendar year 2024, breaches involving business associates were 16 percent of large breach reports but affected 85 percent of the people in those reports, about 207 million.²⁶ The largest single incident was the ransomware attack on Change Healthcare, a clearinghouse and business associate, which OCR's FAQ puts at about 192.7 million people.²⁹ A risk analysis that treats every vendor as someone else's problem misses where most of the exposure now sits.

Drawing the data flow map

An inventory says where data rests. A data flow map shows how it moves: in from patients, labs and hospitals; around the office between workstations, servers and devices; and out to payers, pharmacies, vendors and backups. The proposed rule calls this a "network map that illustrates the movement of electronic protected health information," including how ePHI "enters and exits" systems and "is accessed from outside of such information systems."⁷ A small clinic does not need special software. A clear drawing on one page, with a date and an owner, is enough to start, and is far better than nothing. The example below is fictional but typical.

Places ePHI hides

Experienced assessors check a short list of places that clinics usually forget:

• Copier and fax hard drives. Many multifunction machines keep images of every page they scan, copy or fax. When the lease ends, the drive goes with the machine unless someone arranges to wipe or destroy it.³⁰
• Shared inboxes and scan-to-email folders. Documents scanned "to the EHR" often land first in an email inbox or network folder and stay there for years.
• Exports and reports. Spreadsheets of appointments, unpaid balances or quality measures saved to desktops and USB drives.
• Voicemail. Messages from patients describing symptoms, forwarded to personal email for convenience.
• Personal phones. Photos of wounds or rashes taken to show a colleague, and texts about patients.
• Old systems. The retired EHR kept "read only" on a server in the closet, often unpatched because no one owns it any more.
• Web tracking tools. Analytics and advertising code on portal or appointment pages that can send information to third parties.²⁷
• Medical device workstations. PCs that run ECG, spirometry or imaging software, sometimes on old operating systems that only the device maker may update.

A worked risk register for a 12-person clinic

To make the method concrete, here is a worked example. The clinic is fictional: a family practice in a small Idaho town with 3 clinicians, 9 staff, about 6,800 active patients, a cloud-hosted EHR with a patient portal, an on-site Windows server for practice management and billing, a local backup appliance, cloud email, VoIP phones, two provider laptops used for charting from home, an ECG machine and a spirometer connected to one workstation, an outside billing company and an outside IT provider. The practice manager is also the designated security official. The register below is an illustration of format and reasoning, not a template to copy: a real clinic's entries depend on its own systems.

The rating scales

Before rating anything, the clinic writes down its scales, so the same rating means the same thing next year. Likelihood: 1 rare (not expected in the next several years), 2 unlikely, 3 possible (could happen in the next year or two), 4 likely (expected in the next year), 5 almost certain (happening now or repeatedly). Impact: 1 minimal (no ePHI exposure, minutes of disruption), 2 minor (a few records, a few hours), 3 moderate (dozens of patients or a day of disruption), 4 major (hundreds or thousands of patients, several days of disruption, a reportable breach), 5 severe (most of the patient base, a week or more without records, possible patient harm). Score: likelihood times impact, 1 to 25. Bands: 1 to 4 low, 5 to 9 moderate, 10 to 14 high, 15 to 25 critical. Risk tolerance, approved by the owner: no critical risk stays untreated for more than 30 days; no high risk for more than 90 days; moderate risks are treated or formally accepted within 6 months.

NIST's own example matrices use labels rather than multiplication, and OCR's guidance gives averaging as an example.⁴² Multiplying is popular because it spreads scores out and makes ranking easy, but it is a choice, not a rule. Whatever method you use, document it.

The register

L = likelihood, I = impact, both 1 to 5. Fictional example for teaching; ratings depend on each organization's facts.

Reading the results

Several lessons come out of even this small example:

• The top risks are ordinary. Email without MFA, a shared login, backups on the same network, an unpatched server with remote access exposed. These match the root causes OCR cites in its ransomware and phishing settlements.¹⁷²³
• Impact drives some ratings more than likelihood. The EHR and the backups score critical mainly because losing them would be severe, not because an attack is certain.
• Some risks are about privacy, not hacking. The tracking tag and the voicemail forwarding are not attacks at all, but each can be an impermissible disclosure.
• Not every risk is fixed by technology. The offboarding checklist and fax number checks are procedures. They cost staff time, not money.
• Accepting a risk is allowed if it is documented. The device workstation cannot be upgraded quickly, so the clinic reduces the risk by separating it and records why the remaining risk is acceptable for now.

From register to risk management plan

The register is the risk analysis output. The risk management plan is what satisfies 164.308(a)(1)(ii)(B). For a small clinic it can be the same spreadsheet with more columns: status, date completed, evidence (for example "MFA enforcement report saved to the compliance folder on 11/20"), residual score after treatment, and any formal acceptance signed by the owner. NIST describes this approach: a register "that records assessment findings, remediation plans, timelines, responsible parties, and other relevant information."⁴ Four treatment choices are standard: mitigate (add or improve controls), transfer (share the financial consequence, for example through insurance or contract, though HIPAA duties cannot be transferred), avoid (stop the activity, such as retiring the old server) and accept (live with a risk inside the tolerance, in writing). The plan should be reviewed at a set interval and every time the analysis changes.

The HHS Security Risk Assessment Tool

HHS offers a free tool built for exactly this job. The Security Risk Assessment (SRA) Tool was developed by the Office of the National Coordinator for Health IT (now ASTP, the Assistant Secretary for Technology Policy) with OCR, and is hosted on HealthIT.gov.⁵

Who it is for

The tool's page says plainly: "The target audience of this tool is medium and small providers," and it "may not be appropriate for larger organizations."⁵ NIST says the same: it was "primarily developed to assist small and medium-sized regulated entities."⁴ Hospitals, health systems and large health plans usually need a more detailed method and often an outside assessor, though the tool's question set can still be a useful cross-check.

What it covers and how it works

The tool walks the user through multiple-choice questions about the organization's safeguards, with threat and vulnerability assessment, asset and vendor management sections, and built-in education and references for each question. It comes in two formats: a Windows desktop application (64-bit Windows 7, 8, 10 or 11; the installer is 72.5 MB) and an Excel workbook (218 KB) that replaced the old paper version. The application produces reports that can be saved and printed. Data entered stays on the user's computer: "HHS does not collect, view, store, or transmit any information entered into the SRA Tool."⁵ A user guide for version 3.7 is posted alongside it.³¹

Version 3.7

The download page shows version 3.7, "Last Updated: September 18, 2026." Changes listed include new and revised questions, responses and education, among them a scope question covering every location that handles ePHI, a question on remote access and telework, a modernized asset inventory, and possible review triggers for updating an assessment; minor report updates; and updated software libraries that "include bug fixes and potential vulnerability mitigation."⁵ The page does not state the exact release date of 3.7, so treat September 18, 2026 as the date the page was last updated.

Limits

• It is not proof of compliance. "Use of this tool is neither required by nor guarantees compliance with federal, state or local laws."⁵
• It cannot see your network. As a questionnaire, it "cannot identify technical vulnerabilities," so pair it with vulnerability scanning.⁴ Free external scanning is available to health care organizations from CISA's Cyber Hygiene service, which covers internet-facing systems.³²
• Output depends on input. Answering "yes" to "Do you have MFA?" when it is on for only some users produces a report that is wrong in exactly the way OCR looks for. NIST warns that tool output "is only as good as the information put into the tool."⁴
• It does not do the risk management for you. The report lists risks; someone still has to plan, fund and track the fixes.

Using it well

1. Build the asset inventory and data flow map first, so the tool's inventory and vendor sections are complete.
2. Gather the people who know the systems: the practice manager, a clinician, the billing lead and the IT provider.
3. Answer from evidence. Open the admin console and check whether MFA is on; do not guess.
4. Add the results of an external vulnerability scan and any internal scan your IT provider can run.
5. Export the report, then build the risk management plan from it, with owners and dates.
6. Save the report, the evidence and the plan together, dated, for at least six years under 164.316.¹⁹

When to update the analysis

The current rule requires periodic review and updates "as needed" in response to environmental or operational changes, and keeps the measures themselves under review: 164.306(e) requires that security measures be reviewed and modified as needed to continue providing reasonable and appropriate protection.¹⁰¹⁹ OCR's 2010 guidance and NIST both describe the analysis as ongoing.²⁴ In practice, a defensible schedule has two parts: a fixed review date and a list of triggers.

Events that should trigger an update

• New systems or major changes: a new EHR, a move to the cloud, a new patient portal, telehealth, a new phone system, or adding an artificial intelligence (AI) tool that processes patient data.
• New vendors: any new business associate, or a vendor that changes how it handles your data.
• Mergers, acquisitions and new locations: buying a practice, joining a group, opening a satellite clinic. OCR's guidance lists changes in ownership as an update trigger.²
• Security incidents and breaches: the analysis should be revisited after any significant incident, and lessons learned fed back in. OCR's 2026 settlement announcements recommend exactly that.¹⁷²²
• Turnover in key roles: a new practice manager, security official or IT provider.
• New threat information: a widely exploited flaw in a product you use, or a federal alert about attacks on your sector.
• Changes in law: for example a final version of the Security Rule update.

What the proposed rule would add

On January 6, 2025, HHS published a notice of proposed rulemaking (NPRM) to strengthen the Security Rule, 90 FR 898.⁷ It would turn much of today's guidance into explicit text. The proposed risk analysis standard (proposed 164.308(a)(2), printed at 90 FR 1012 to 1013) would require a written assessment that includes, at a minimum: a review of the technology asset inventory and network map; identification of all reasonably anticipated threats; identification of potential vulnerabilities and predisposing conditions; an assessment and documentation of current security measures; a reasonable determination of likelihood and of potential impact for each threat exploiting each vulnerability; an assessment of risk level for each; and an assessment of the risks posed by entering into or continuing each business associate arrangement, based on written verification from the business associate.⁷ The written assessment would have to be reviewed, verified and updated "at least once every 12 months" and when changes occur, including new technology, patches and upgrades, newly recognized threats, mergers, security incidents and relevant changes in law.⁷

Sources: current 45 CFR 164.308 and 164.306; proposed 164.308(a)(1), (a)(2) and (a)(5) at 90 FR 1012 to 1013; HHS NPRM fact sheet, December 27, 2024.¹⁷³³

Status matters here. As of October 28, 2026, the overhaul is still a proposal. Comments closed March 7, 2025. HHS's latest regulatory agenda lists the rule as a long-term action with final action projected for July 2027, after an earlier projection of May 2026 passed without a final rule.⁸³⁴ Many vendor websites describe a "2026 HIPAA Security Rule" as if it were in force. It is not. The current rule, with its one-sentence risk analysis requirement, is the one OCR enforces. But because the proposal mostly describes what OCR already expects, an organization that builds its analysis to the proposed list loses nothing if the rule changes or never does. Lesson 3 covers the rest of the proposal: the Security Rule and the proposed update.

OCR's Risk Analysis Initiative

Risk analysis failures have shown up in OCR settlements for well over a decade. The record $16 million Anthem settlement of October 15, 2018, which followed cyberattacks that began with spear phishing and exposed the ePHI of almost 79 million people, included a finding that Anthem "failed to conduct an enterprise-wide risk analysis."³⁵ What changed in late 2024 was that OCR began picking investigations specifically to test the risk analysis requirement and announcing each result as a numbered action in its Risk Analysis Initiative.

How the initiative began

The first announced action came on October 31, 2024: Bryan County Ambulance Authority in Oklahoma paid $90,000 after a ransomware attack in November 2021 that affected about 14,273 patients. OCR found it had not conducted a compliant risk analysis and imposed a three-year corrective action plan. OCR has described the initiative as a way to focus select investigations on compliance with the Security Rule's risk analysis provision.²⁴ This lesson could not find a separate HHS announcement giving a formal launch date.

The numbered actions so far

By April 23, 2026, OCR said it had completed 13 Risk Analysis Initiative investigations.¹⁷ The Spencer Gifts group health plan settlement of June 18, 2026 was announced as the 14th.⁶ Later 2026 settlements with OSF HealthCare and Ambry Genetics also cited risk analysis failures but did not carry an initiative number, so the safe statement is "at least 14 actions as of June 18, 2026."²²²³ Selected cases:

HHS's own release numbers the neurology practice settlement as the 8th initiative action. Northeast Surgical Group and Guam Memorial are counted as the 4th and 7th initiative actions in compiled lists by secondary sources; OCR's list confirms their amounts and dates.³⁷²⁰

What the corrective action plans require

The money gets the headlines, but the corrective action plans (CAPs) do the work. They typically run two or three years under OCR monitoring and follow a pattern: conduct an accurate and thorough risk analysis; submit it to OCR for review; develop and implement a risk management plan to address what it finds; revise policies and procedures; and train the workforce.^6222324 In other words, the remedy for not doing a risk analysis is being required to do one under federal supervision, and to report on it. For a small organization, that oversight can cost more in time than the payment.

What OCR recommends

OCR's 2026 settlement announcements repeat a short list of recommendations. The first two are about the risk analysis itself: identify where ePHI is located in your systems and how it enters, moves within and leaves them; and conduct accurate and thorough risk analyses periodically and maintain a plan to address the risks found. The rest describe controls that a good analysis would usually point to: audit controls and regular review of system activity, authentication to make sure only authorized users reach ePHI, encryption of ePHI in transit and at rest where appropriate, feeding lessons learned from incidents back into the security management process, and role-specific HIPAA training.¹⁷²²

The link to the Recognized Security Practices law

Since January 5, 2021, federal law has given organizations a reason to document their security practices beyond avoiding a finding. Public Law 116-321 added section 13412 to the HITECH Act, codified at 42 U.S.C. 17941. When HHS decides fines, the length and outcome of an audit, or other remedies, the Secretary "shall consider" whether the covered entity or business associate adequately demonstrated that it had recognized security practices in place for not less than the previous 12 months.⁹ Recognized security practices include the standards and methods developed under the NIST Act (in practice, the NIST Cybersecurity Framework and related NIST publications) and the approaches promulgated under section 405(d) of the Cybersecurity Act of 2015, which is the HICP guidance.⁹²⁵³⁸ The organization chooses which practices to follow. The law also says it does not authorize HHS to increase fines or lengthen audits because an organization did not adopt such practices, and that it does not limit HHS's authority to enforce the Security Rule.⁹

The connection to the risk analysis is direct. The law rewards practices that were actually in place and can be shown. A dated risk analysis that maps findings to NIST CSF outcomes or HICP practices, a risk management plan showing those practices were implemented, and evidence of operation over 12 months are the kind of record that can make the difference. In April 2022, OCR asked the public how organizations implement recognized security practices and how they would show it, in a request for information published at 87 FR 19833; comments closed June 6, 2022.³⁹ OCR has not issued a rule defining what "adequately demonstrated" means, so organizations should keep their own evidence: policies with dates, configuration screenshots, training records, scan reports, and minutes of meetings where risks were reviewed. The HHS 405(d) program's free HICP volumes include a practice on cybersecurity risk assessment and management for small organizations (sub-practice 10.S.B), and the voluntary HPH Cybersecurity Performance Goals released in January 2024 give a short list of essential and enhanced goals that make convenient targets for a risk management plan.⁴⁰⁴¹

Who should do the analysis

Doing it in house

Nothing in the rule requires an outside assessor. Many small practices do their own analysis with the SRA Tool, the security official leading and the IT provider supplying technical facts. That works when the people involved understand the systems, answer honestly, and have time. The risks are blind spots (no one questions how things have always been done), conflicts (the IT provider grading its own work), and thin technical evidence.

Using an outside assessor

Larger organizations, those with complex networks, and those that have had an incident often bring in an outside firm. A good assessor brings a tested method, technical testing, and independence. A poor one sells a generic report with the client's name pasted in, which is the kind of work OCR's audit report criticized: its second-worst rating, 4, described negligible efforts such as generic or template-copied documentation.¹²⁴² When hiring, ask to see a redacted sample report, ask how they will build the asset inventory, whether they will interview staff and inspect systems on site or remotely, whether they will include vulnerability scanning, how they rate likelihood and impact, and whether they will help build the risk management plan. Be wary of anyone promising "HIPAA certification": HHS does not certify organizations or products as HIPAA compliant.

Mixing the two

A common middle path: the organization does its own inventory, data flow map and SRA Tool questionnaire each year, and brings in an outside firm every two or three years, or after a major change, for technical testing and an independent check. Whatever the approach, the organization owns the result. As OCR's audit report put it, "The responsibility to maintain an appropriate risk analysis rests with the entity."¹²

What a good final report contains

NIST SP 800-30's Appendix K offers a report outline, and SP 800-66 Rev. 2 recommends a risk register.³⁴ Putting those together with OCR's nine elements, a report that will hold up typically has:

1. Cover page: organization, date, version, who performed it, who approved it.
2. Purpose and scope: what was covered (all locations, systems, vendors and ePHI) and anything deliberately excluded, with the reason.
3. Method: the steps followed, the likelihood and impact scales, the scoring method and the risk tolerance.
4. Participants and sources: who was interviewed, what was inspected, which scans and documents were reviewed.
5. Asset inventory and data flow map, dated.
6. Threats and vulnerabilities considered, including those judged not applicable and why.
7. Current controls and whether each was verified.
8. Risk register: each threat and vulnerability pair with likelihood, impact, risk level and reasoning.
9. Prioritized recommendations that lead straight into the risk management plan.
10. Leadership sign-off showing the owner, board or executive accepted the results and any residual risks.
11. Next review date and triggers.
12. Appendices: scan reports, evidence, the prior analysis and what changed since.

Common mistakes OCR keeps finding

These failures come from OCR's resolution agreements, settlement announcements and audit report. Most organizations that end up in a CAP made more than one.

• No risk analysis at all. Still common in small practices and business associates, often discovered only after a breach report.
• Not organization-wide. Anthem's finding was the lack of an "enterprise-wide" analysis.³⁵ Smaller versions: the analysis covered the EHR but not email, file shares or the billing system.
• Missing ePHI. The audit report found entities "generally failed to" identify and assess the risks to all of the ePHI in their possession.¹² Bryan County's CAP required a complete asset inventory.²⁴
• Treating a product or checklist as the analysis. Buying a security tool or filling out a compliance checklist does not identify and rate risks.¹²
• Outdated analysis. One analysis done years ago, never revisited after a new EHR, a move or a merger.
• Analysis without management. Risks identified but no plan, no owners, no dates, no evidence of follow-through. Ambry, OSF and others were required to create risk management plans as part of their CAPs.²³²²
• Ignoring the obvious attack paths. Phishing and ransomware are the leading causes of large breaches, yet analyses often rate them low or leave out email, remote access and backups.²⁶¹⁷
• Business associates skipping their own analysis. Business associates have been directly required to do a risk analysis since 2013. MMG Fusion and Consociate Health, both business associates, were cited for not doing an accurate and thorough one.²¹¹⁷
• Weaknesses the analysis should have found. No unique user IDs, no procedure for ending access, no audit log review. These turn up as separate findings alongside risk analysis failures.²³³⁵

Questions people ask

How often do we have to do a risk analysis?

The current rule does not set a number. It requires an accurate and thorough analysis kept current through periodic review and updates after changes.¹¹⁹ OCR's guidance mentions annual reviews or reviews every two or three years as practices some organizations follow.² Annual is the safest choice, and it is what the proposed rule would require if finalized.⁷ A full redo is not needed every year if the prior analysis is reviewed, verified and updated with documented changes.

Is the HHS SRA Tool enough by itself?

For a small practice it can be the backbone, but on its own it has gaps. It cannot detect technical vulnerabilities, and its output depends on honest, verified answers. Pair it with an asset inventory, a data flow map, vulnerability scanning and a written risk management plan.⁵⁴

We are a business associate. Do we need our own analysis?

Yes. Since the 2013 Omnibus Rule, business associates must comply with the Security Rule directly, including the risk analysis requirement.¹⁶¹ A covered entity's analysis does not cover the vendor's own systems, and several initiative actions involved business associates.²¹¹⁷

Does the risk analysis have to cover paper records?

The Security Rule's risk analysis covers ePHI. Paper records are protected by the Privacy Rule's requirement for appropriate administrative, technical and physical safeguards. Many organizations assess both in one exercise, which is sensible because the same office, staff and vendors handle both.

What will OCR ask for after a breach?

Typically: the current risk analysis and prior ones, the risk management plan and evidence of progress, policies and procedures, training records, BAAs for vendors involved, audit log review records, and the incident and breach notification records. Lessons 5 on breach notification and 8 on enforcement cover the rest of the process.

How much does a risk analysis cost?

The HHS SRA Tool, NIST guidance, HICP and CISA's external scanning are free.⁵⁴⁴⁰³² The real cost of an in-house analysis is staff time. Outside assessments vary widely with size and scope; get several written quotes describing exactly what is included. The cost of not doing one shows up in OCR payments of $10,000 to $700,000 in recent cases, multi-year CAPs, and the far larger cost of a breach.²¹²³

We added an AI scribe. Does that change the analysis?

Yes. Any new tool that receives patient conversations or records is new ePHI flowing to a new vendor. Add it to the inventory and data flow map, assess its risks, and make sure there is a BAA. Lesson 6 covers AI vendors in detail.

Hard questions

Should HHS prescribe exactly what a risk analysis must contain?

For: After two decades of flexible text, the same failure keeps appearing in enforcement, and the 2016 to 2017 audits found most entities rated 3 or worse.¹² Supporters of the 2025 proposal argue that a list of minimum contents, a required inventory and network map, and a 12-month cycle would tell organizations exactly what OCR expects and make the requirement easier to meet and to check.⁷ Against: In February 2025, a group of hospital and health system organizations including the Association of American Medical Colleges asked the administration to rescind the proposal, citing "the staggering costs and regulatory burden" and a timeline they called unreasonable.⁴³ HHS's own estimate in the proposal was large: first-year costs of about $9.3 billion ($9,314,106,174 in the paperwork burden estimate) and about $6 billion a year in years two through five.⁷ What the evidence shows: The current gap is less about not knowing what to do than about not doing it; OCR's 2010 guidance and NIST already describe the contents in detail.²⁴ Clearer text would remove excuses, but whether more paperwork reduces breaches has not been tested. HHS has moved the final rule to a long-term action, projected for July 2027.⁸

Is it fair to hold a three-person practice to the same requirement as a health system?

For equal treatment: Patients' data is just as sensitive in a small office, and attackers target small practices because they are easier. Several OCR cases involve small entities and business associates.²⁰²¹ For a lighter touch: Small practices lack staff and money, and a requirement written for hospitals can turn into a paper exercise. What the evidence shows: The current rule already scales: the analysis must be accurate and thorough, but its size can match the organization.¹⁰² Free federal tools exist specifically for small providers (the SRA Tool, HICP Technical Volume 1, CISA scanning), and OCR's settlements with small entities have been as low as $10,000, sometimes after considering the entity's finances.^5403221 The harder question is whether those tools reach the practices that need them; no public data measures their use.

Do penalties for missing risk analyses improve security, or would technical help do more?

Penalties work: Public enforcement gets attention from boards and owners, and CAPs force organizations to fix the problem under supervision.⁶ Help works better: Most initiative cases resolve incidents from 2020 and 2021, years after the fact, and payments in the tens of thousands of dollars are small next to breach costs. What the evidence shows: OCR resolved 22 cases with payments in all of 2024, totaling $9,944,612, while it received 30,256 new complaints and 663 large breach reports that year.¹³²⁶ Enforcement on that scale cannot touch most organizations; it works as a signal. The Recognized Security Practices law takes the other approach, rewarding organizations that can show good practices after an incident.⁹ Neither approach has been formally evaluated for its effect on breach rates.

Should passing an outside certification count as a risk analysis?

For: Certifications such as HITRUST or SOC 2 involve independent testing that is often more rigorous than a self-assessment, and they map to HIPAA. Recognizing them would reduce duplicate work. Against: A certification measures controls against a framework, which is closer to a gap assessment; it may not cover every system or vendor that holds the organization's ePHI. What the evidence shows: HIPAA does not recognize any private certification as proof of compliance, and NIST notes that tools and frameworks do not "necessarily equate to compliance."⁴ An organization can use certification work as strong input to its risk analysis and as evidence of recognized security practices, but should still be able to produce a HIPAA risk analysis that covers all ePHI.⁹

Where to go next

• HHS Security Risk Assessment Tool: Free Windows app or Excel workbook from HHS for small and medium providers; data stays on your computer. Build your inventory first, answer from evidence, and pair it with vulnerability scanning.
• OCR Guidance on Risk Analysis (2010): Free, short, official. The nine elements OCR expects; read it before starting and keep it beside your report.
• NIST SP 800-66 Rev. 2: Free NIST guide written for HIPAA entities. Use Section 3 for the seven-step assessment, Section 4 for risk management and Table 8 as a work plan.
• NIST SP 800-30 Rev. 1: Free. The underlying risk assessment method; Appendices D to I give sample threats, vulnerabilities and scales, and Appendix K a report outline.
• HICP Technical Volume 1 for small health care organizations: Free HHS 405(d) guide. Practical controls for small practices that make good treatments in a risk management plan, and recognized security practices under 42 U.S.C. 17941.
• CISA Cyber Hygiene Services: Free weekly external vulnerability scanning for health care and other critical infrastructure organizations; enroll by email. Fills the technical gap a questionnaire leaves.
• OCR Resolution Agreements and CAPs: Free. Read the corrective action plans to see exactly what OCR requires after a risk analysis failure.

Still being checked (5 items)

These points could not be fully confirmed against a primary source when this lesson was written and fact checked in October 2026. The text above states each one as uncertain.

• The exact release date of SRA Tool version 3.7; the HHS page shows only "Last Updated: September 18, 2026."
• The formal launch date of OCR's Risk Analysis Initiative; the first announced action was October 31, 2024. OCR's own wording describing the initiative's purpose was not found on a primary HHS page during fact checking, so the lesson paraphrases it.
• The total number of Risk Analysis Initiative actions after June 18, 2026; later OCR releases (OSF HealthCare, Ambry Genetics) cite risk analysis failures without an initiative number.
• Whether Northeast Surgical Group and Guam Memorial Hospital Authority are formally numbered initiative actions (4th and 7th in secondary-source lists); HHS's own release numbers the neurology practice settlement (note 20) as the 8th, and OCR's list confirms the amounts and dates.
• The status and results of the audit round of 50 regulated entities that OCR reportedly planned to start in late 2024 or early 2025; no published results were found.

Last verified October 28, 2026. General education, not legal, compliance or medical advice; rule versions and dates are stated in the text, and the sources used are listed in the Notes and Sources below. Check the regulator's current text before relying on any point.

Notes

1. 45 CFR 164.308, Administrative safeguards, including 164.308(a)(1)(ii)(A) risk analysis and (B) risk management, as amended by the Omnibus Rule (78 FR 5566, Jan. 25, 2013); current eCFR text, Title 45 (read Oct. 28, 2026). Read it online. ↩
2. HHS Office for Civil Rights, Guidance on Risk Analysis Requirements under the HIPAA Security Rule, July 14, 2010; page content last reviewed Aug. 12, 2026. PDF version: https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/administrative/securityrule/rafinalguidancepdf.pdf (read Oct. 28, 2026). Read it online. ↩
3. NIST Joint Task Force Transformation Initiative, Guide for Conducting Risk Assessments, NIST Special Publication 800-30 Revision 1, September 2012; Chapter 3 (process) and Appendices D to K (read Oct. 28, 2026). Read it online. ↩
4. Jeffrey Marron, Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource Guide, NIST Special Publication 800-66 Revision 2, Feb. 14, 2024; Sections 3.1 to 3.4, Section 4, Table 8 and Appendices C, D and F (read Oct. 28, 2026). Read it online. ↩
5. HealthIT.gov (HHS ASTP, formerly ONC, with OCR), Security Risk Assessment Tool, version 3.7, page "Last Updated: September 18, 2026" (read Oct. 28, 2026). Read it online. ↩
6. HHS press release announcing OCR's settlement with Spencer Gifts LLC Flexible Benefits and Welfare Benefit Plans ($450,000; OCR's 20th ransomware action and 14th Risk Analysis Initiative action), June 18, 2026 (read Oct. 28, 2026). Read it online. ↩
7. HHS Office for Civil Rights, "HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information," notice of proposed rulemaking, 90 FR 898 (Jan. 6, 2025), RIN 0945-AA22, docket HHS-OCR-2024-0020; proposed 164.308(a)(1), (a)(2) and (a)(5) at 90 FR 1012 to 1013; cost estimates in the regulatory impact analysis and Paperwork Reduction Act sections. Not a final rule (read Oct. 28, 2026). Read it online. ↩
8. Office of Information and Regulatory Affairs, Unified Agenda entry for RIN 0945-AA22 (2026 agenda, publication ID 202510): stage "Long-Term Actions," final action projected 07/00/2027 (read Oct. 28, 2026). Read it online. ↩
9. 42 U.S.C. 17941 (HITECH Act section 13412, added by Pub. L. 116-321, Jan. 5, 2021), Recognized security practices; text at Cornell Legal Information Institute (read Oct. 28, 2026). Read it online. ↩
10. 45 CFR 164.306, Security standards: General rules, including (b) flexibility of approach, (d) addressable implementation specifications and (e) maintenance; text at Cornell Legal Information Institute (read Oct. 28, 2026). Read it online. ↩
11. HHS, "Summary of the HIPAA Security Rule" (required and addressable implementation specifications) (read Oct. 28, 2026). Read it online. ↩
12. HHS Office for Civil Rights, 2016-2017 HIPAA Audits Industry Report, December 2020; ratings for Security Rule audit items S2 (risk analysis) and S3 (risk management) (read Oct. 28, 2026). Read it online. ↩
13. HHS Office for Civil Rights, Annual Report to Congress on HIPAA Privacy, Security, and Breach Notification Rule Compliance, calendar year 2024 (read Oct. 28, 2026). Read it online. ↩
14. American Med Spa Association, "HHS Announces HIPAA Audit Program Will Resume," Jan. 24, 2025 (secondary source reporting OCR's plan to audit 50 regulated entities) (read Oct. 28, 2026). Read it online. ↩
15. HHS, "Health Insurance Reform: Security Standards," final rule, 68 FR 8334 (Feb. 20, 2003); compliance dates at 45 CFR 164.318 (read Oct. 28, 2026). Read it online. ↩
16. HHS, "Modifications to the HIPAA Privacy, Security, Enforcement, and Breach Notification Rules Under the HITECH Act and GINA; Other Modifications to the HIPAA Rules," final rule, 78 FR 5566 (Jan. 25, 2013) (read Oct. 28, 2026). Read it online. ↩
17. HHS press release announcing four OCR ransomware settlements (Regional Women's Health Group, Assured Imaging, Consociate Health, Star Group L.P. Health Benefits Plan; 19 ransomware and 13 Risk Analysis Initiative investigations completed), Apr. 23, 2026 (read Oct. 28, 2026). Read it online. ↩
18. 45 CFR 160.103, Definitions ("electronic protected health information," "business associate"); text at Cornell Legal Information Institute (read Oct. 28, 2026). Read it online. ↩
19. 45 CFR 164.316, Policies and procedures and documentation requirements, including (b)(2) time limit (6 years), availability and updates; text at Cornell Legal Information Institute (read Oct. 28, 2026). Read it online. ↩
20. HHS Office for Civil Rights, "Resolution Agreements and Civil Money Penalties" list (Northeast Surgical Group, Jan. 15, 2025; Guam Memorial Hospital Authority, Apr. 17, 2025; Comprehensive Neurology, Apr. 25, 2025; and others); and HHS press release, "HHS Office for Civil Rights Settles HIPAA Ransomware Cybersecurity Investigation with Neurology Practice," Apr. 25, 2025 (Comprehensive Neurology, PC, $25,000; 8th Risk Analysis Initiative action), https://www.hhs.gov/press-room/ocr-hipaa-racap-np.html (read Oct. 28, 2026). Read it online. ↩
21. HHS press release announcing OCR's settlement with MMG Fusion, LLC (12th Risk Analysis Initiative action, $10,000), Mar. 5, 2026 (read Oct. 28, 2026). Read it online. ↩
22. HHS press release announcing OCR's ransomware settlement with OSF HealthCare System ($552,250), July 29, 2026 (read Oct. 28, 2026). Read it online. ↩
23. HHS press release announcing OCR's settlement with Ambry Genetics Corporation over a phishing attack affecting about 225,000 individuals ($700,000), Sept. 17, 2026 (read Oct. 28, 2026). Read it online. ↩
24. HHS Office for Civil Rights, Resolution Agreement and Corrective Action Plan, Bryan County Ambulance Authority (ransomware began encrypting files Nov. 24, 2021; about 14,273 patients; three-year CAP that requires a risk analysis including a complete inventory of equipment, data systems, off-site storage and applications holding ePHI), announced Oct. 31, 2024. Summary also in Hunton Andrews Kurth, Privacy and Information Security Law Blog (read Oct. 28, 2026). Read it online. ↩
25. HHS 405(d) Program and Health Sector Coordinating Council, Health Industry Cybersecurity Practices: Managing Threats and Protecting Patients (HICP), 2023 edition (read Oct. 28, 2026). Read it online. ↩
26. HHS Office for Civil Rights, Annual Report to Congress on Breaches of Unsecured Protected Health Information, calendar year 2024 (663 reports of 500 or more; hacking or IT incidents 534 reports, 81%; business associates 106 reports, 16%, about 206.9 million people, 85%) (read Oct. 28, 2026). Read it online. ↩
27. HHS Office for Civil Rights, "Use of Online Tracking Technologies by HIPAA Covered Entities and Business Associates," bulletin first issued December 2022, revised March 2024, partly vacated in American Hospital Association v. Becerra (N.D. Tex. June 20, 2024) as noted on the page (read Oct. 28, 2026). Read it online. ↩
28. HHS Office for Civil Rights, "Guidance on HIPAA and Cloud Computing," Oct. 6, 2016, last reviewed Dec. 23, 2022 (read Oct. 28, 2026). Read it online. ↩
29. HHS Office for Civil Rights, "Change Healthcare Cybersecurity Incident Frequently Asked Questions" (about 192.7 million individuals as of July 31, 2025), last reviewed Aug. 13, 2025 (read Oct. 28, 2026). Read it online. ↩
30. 45 CFR 164.310(d), Device and media controls (disposal and media re-use); text at Cornell Legal Information Institute (read Oct. 28, 2026). Read it online. ↩
31. HealthIT.gov, SRA Tool User Guide, version 3.7, linked from the SRA Tool download page (read Oct. 28, 2026). Read it online. ↩
32. Cybersecurity and Infrastructure Security Agency, "Cyber Hygiene Services" (free vulnerability scanning of internet-facing systems for critical infrastructure organizations, including health care) (read Oct. 28, 2026). Read it online. ↩
33. HHS Office for Civil Rights, fact sheet on the HIPAA Security Rule notice of proposed rulemaking, Dec. 27, 2024 (read Oct. 28, 2026). Read it online. ↩
34. McDermott Will and Schulte, "Final Action on HIPAA Security Rule Modifications Now Projected for July 2027," July 16, 2026 (secondary source on the earlier May 2026 projection) (read Oct. 28, 2026). Read it online. ↩
35. HHS Office for Civil Rights, Anthem, Inc. resolution agreement page ($16 million, almost 79 million people), Oct. 15, 2018. The findings quoted, including failure to conduct an enterprise-wide risk analysis, are from the HHS press release as reproduced by Burr and Forman LLP: https://www.burr.com/assets/htmldocuments/uploads/2018/10/Anthem-Will-Pay-Record-16-Million-To-Settle-Health-Care-Data-Breach.pdf (read Oct. 28, 2026). Read it online. ↩
36. HHS press release announcing OCR's settlement with Top of the World Ranch Treatment Center ($103,000; 11th Risk Analysis Initiative action), Feb. 19, 2026 (read Oct. 28, 2026). Read it online. ↩
37. EHR Resources, "OCR Risk Analysis Initiative" compiled list of enforcement actions, updated Oct. 18, 2026 (secondary source; not an HHS publication) (read Oct. 28, 2026). Read it online. ↩
38. NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, Feb. 26, 2024 (read Oct. 28, 2026). Read it online. ↩
39. HHS Office for Civil Rights, "Considerations for Implementing the Health Information Technology for Economic and Clinical Health (HITECH) Act, as Amended," request for information, 87 FR 19833 (Apr. 6, 2022); comments due June 6, 2022 (read Oct. 28, 2026). Read it online. ↩
40. HHS 405(d) Program, Technical Volume 1: Cybersecurity Practices for Small Health Care Organizations, 2023 edition (sub-practice 10.S.B, cybersecurity risk assessment and management) (read Oct. 28, 2026). Read it online. ↩
41. HHS, "Healthcare and Public Health Sector Cybersecurity Performance Goals" (10 essential and 10 enhanced voluntary goals, released January 2024) (read Oct. 28, 2026). Read it online. ↩
42. HIPAA Journal, "OCR HIPAA Audits Industry Report" (description of the 1 to 5 rating scale used in OCR's 2016 to 2017 audits), Dec. 18, 2020, secondary source (read Oct. 28, 2026). Read it online. ↩
43. Association of American Medical Colleges, "AAMC Joins Group Letter Requesting Rescission of HIPAA Proposed Security Rule," Feb. 21, 2025 (read Oct. 28, 2026). Read it online. ↩
44. HHS Office for Civil Rights, Breach Portal: Notice to the Secretary of HHS Breach of Unsecured Protected Health Information (breaches affecting 500 or more individuals) (read Oct. 28, 2026). Read it online. ↩
45. Idaho Office of the Attorney General, "Security Breaches" list of notices received (includes Minidoka Memorial Hospital filings dated Aug. 6 and Sept. 28, 2026) (read Oct. 28, 2026). Read it online. ↩
46. SecurityWeek, "460k Impacted by Kootenai Health Ransomware Attack" (464,088 people per filing with the Maine Attorney General), 2024, secondary source (read Oct. 28, 2026). Read it online. ↩
47. HIPAA Journal, "Minidoka Memorial Hospital Cyberattack," Apr. 22, 2026, secondary source (read Oct. 28, 2026). Read it online. ↩
48. Idaho Code 28-51-104, Definitions (personal information for breach notice purposes), Idaho Legislature (read Oct. 28, 2026). Read it online. ↩