What a Healthcare Compliance Attorney Heard at the OCR’s HIPAA Security Conference
I spent two days at the beginning of September at the National Institute of Standards and Technology campus in Gaithersburg, Maryland, at the conference NIST co-hosts with the Office for Civil Rights on HIPAA security. It is a government event held on a federal campus, which keeps it small, and the attendance tends to attract those closest to the work: the people in the room are the ones writing the guidance, enforcing the rules, or responsible for following them. Over two days I heard presentations from and spoke with OCR leadership, with security practitioners, and with the people who carry compliance responsibility inside healthcare organizations.
I went expecting to spend most of my attention on the proposed Security Rule overhaul, which has drawn heavier objection from the healthcare industry than any HIPAA rulemaking in years. OCR Deputy Director Timothy Noonan has previously said the agency received roughly 4,745 comments on it. A great many raised the same point: the proposed requirements would cost too much, and the organizations least able to absorb that cost would be hit hardest.
The agenda over two days covered a lot of ground, and most of it was technical. But OCR’s own sessions kept coming back to a requirement that is not part of the proposal at all. The risk analysis has been mandatory since 2005, and turns up missing or deficient in nearly every enforcement action the agency brings. That is not news to anyone who has worked through an OCR investigation, but conversations I had between sessions only reinforced it.
So the objection to the proposed rule deserves to be taken seriously, and in part it is correct. But a significant share of it is aimed at obligations that already exist, and the debate over what compliance will cost in 2027 skips past a more immediate problem: many organizations are not meeting the requirements already in place.
Where the rulemaking stands
The proposed rule was published in the Federal Register on January 6, 2025, at 90 FR 898. The comment period closed on March 7, 2025. The rulemaking remains on the Unified Agenda as a long-term action. OCR Director Paula Stannard clarified the expected timing in her keynote: final action anticipated in July of 2027. That date is worth understanding correctly. It is the point by which OCR currently projects taking its next formal action, not necessarily a publication date for a final rule. What form the rule takes when it arrives is not yet knowable, but the direction is.
A proposed rule is the agency telling the industry where it believes the standard needs to be. The changes are not arbitrary additions and are a reflection of what OCR keeps finding when it investigates. Whatever the final text says, that is where this is heading, and an organization waiting for the date before it begins risks starting from further behind.
OCR did not back away from the reasoning behind the changes. Director Stannard tied them to the increase in large breaches and cyberattacks and to the deficiencies the agency keeps finding in security investigations. She also provided context as to where things stand on the proposed rule changes as comment review is still underway, adding the administration “may have a different view on some of the burdens and benefits of the proposed changes.” Director Stannard also noted she was limited in what she could say mid-rulemaking, but pointed to the cyber strategy the President released in March. One pillar of that strategy is common-sense regulation: streamlining cyber rules and keeping them agile enough for the private sector to match evolving threats, while recognizing Americans’ right to privacy in their own data. Another pillar is securing critical infrastructure, which includes healthcare. So, how far the requirements go may still change. That they are coming is not really in question..
What “addressable” was always supposed to mean
Under the current Security Rule, each implementation specification is labeled either required or addressable. That distinction has been widely misunderstood, and the misunderstanding is the source of a good deal of the present objection. An addressable specification has never been optional. 45 CFR 164.306(d) sets out what a covered entity must actually do with one. First, assess whether the specification is a reasonable and appropriate safeguard in your environment. If it is, implement it. If it is not, you must document why it is not reasonable and appropriate, and then implement an equivalent alternative measure if an equivalent alternative measure is reasonable and appropriate.
Translation: addressable means you have to achieve the protection. It gives you room to achieve it a different way if your circumstances call for that, provided you write down your reasoning and what you did instead. It does not give you room to skip it. An organization that read “addressable” and concluded “optional” was simply not complying.
OCR has said so directly. In the preamble to the proposed rule, at 90 FR 917, the Department states that it is concerned some regulated entities proceed as if compliance with an addressable implementation specification is optional, describes that interpretation as incorrect, and concludes that compliance with the specifications currently designated as addressable is not and should not be optional. This was a throughline across the OCR sessions in Gaithersburg, and the agency’s frustration with the misreading was evident. That is the context for the proposal to eliminate the required and addressable distinction and make implementation specifications required, with limited specified exceptions. For an organization that has been applying 164.306(d) as written, the change alters the label rather than the obligation.
What is genuinely new, and who it falls on
It would be inaccurate to suggest the proposed rule is only a relabeling exercise. The proposal would add a technology asset inventory and network map, a compliance audit at least every twelve months, vulnerability scanning at least every six months, penetration testing at least every twelve months, multifactor authentication, network segmentation, written procedures to restore certain systems within 72 hours, and annual written verification from business associates. The Department’s own regulatory impact analysis projects roughly $9 billion in first-year costs across the industry.
Several of these are controls the information security field settled on years ago. Multifactor authentication, asset inventories, and routine vulnerability scanning are treated as baseline practice in mature security programs; OCR did not invent them. Multifactor authentication in particular is less a compliance item than a basic security control. An environment protected by a password alone is reachable by an attacker with ordinary tools and a little patience. Adding it where it does not exist costs something, but that cost is small compared to what it prevents.
Others represent real new expenses. Annual penetration testing and network segmentation are meaningful investments for a practice with a handful of providers and an outsourced IT vendor. Obtaining written verification from every business associate each year is a genuine administrative burden for an organization with dozens of vendors and nobody assigned to compliance full time.
The burden would not fall evenly. Larger organizations are more likely to have the baseline controls in place already and to absorb what they do not. The weight lands on the organizations with the least capacity to carry it, which is why the cost objection is not frivolous even where the underlying controls are sound.
Stannard offered the counterweight from the same keynote: the cost of doing nothing. A successful cyberattack, she noted, can cost far more in reputation, ransom, remediation, protections for those whose information was taken, and civil lawsuits from the individuals harmed. A compliance program exists to reduce the odds of an attack succeeding, limit how much is exposed if one does, and change the nature of what follows. OCR is going to ask for documents either way. The difference is whether the investigation is focused on understanding how your safeguards failed or about why you never put any in place..
One requirement nobody is objecting to
45 CFR 164.308(a)(1)(ii)(A) requires a covered entity to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of the electronic protected health information it holds. The parenthetical beside it in the regulation reads “Required” and it has read that way since April 2005.
OCR has been unambiguous about its role. The agency requests a risk analysis in every Security Rule investigation it conducts, and it remains among the most commonly deficient documents organizations produce. OCR has also drawn a distinction that catches many programs off guard: a gap analysis, which compares current practice against a checklist, does not satisfy this requirement. Tim Noonan made the point from the podium by comparing a screwdriver to a hammer: both are useful, and neither substitutes for the other.
Nick Heesters, OCR’s Senior Advisor for Cybersecurity, restated the standard in three parts. A sufficient risk analysis addresses risk to electronic protected health information as it is created or enters the organization, as it moves within the organization, and as it leaves. The session made concrete what failure at each stage looks like. In one investigation OCR described, an organization certified that a system held no ePHI, so its web server logs went unprotected by design. A patient-facing form on that system crashed under certain inputs and dumped everything it was processing into those logs, where an attacker eventually found it. Nobody had asked where the data actually went. That is the question the risk analysis exists to answer.
The enforcement record reflects this as well. OCR’s settlements with OSF HealthCare for $552,250, with the Spencer Gifts group health plan for $450,000, and with the Star Group health benefits plan for $245,000 each followed a ransomware incident, and each cited a failure to conduct an accurate and thorough risk analysis. In the investigations I have supported, the risk analysis is among the first documents requested, and what it reveals about the rest of the program is usually apparent before anything else is reviewed.
On the second day, NIST reviewed its work on post-quantum cryptography, a federal effort to protect data against a decryption capability that does not exist yet, on a timeline running to 2035. That is the horizon they are planning against. The concern is that an industry that has not met a twenty-year-old requirement asking it to document where its data lives has no realistic path to what comes after.
What to do today
If you take one action after reading this, make it the risk analysis.
If your organization has completed a risk analysis, consider whether it meets the standard: accurate, thorough, current, and covering ePHI at every stage and not just related to the electronic health record.
If your organization has not completed a risk analysis, or has not completed one within the past year, that is where to start. Not because a new rule is coming, but because the requirement is in force today and has been for twenty years.
The exercise costs less than avoiding it. You may find your controls are sound, in which case you now hold documentation that demonstrates your protection was deliberate. You may find gaps, in which case you know what they are and can work through them in order of severity. Either outcome leaves you in a materially better position.
I spent two days listening to people’s plans for the next decade, and my key takeaway is this: to be prepared to defend against future challenges assumes the ability to defend against current ones. The distance between where most organizations are and where they will need to be is widening. There is room to argue about what the final rule should require, and some of those arguments have merit. What there is no argument about is what the rule requires today. Now is the time to get caught up.
