By Matt Fisher, Healthcare Attorney
LinkedIn: Matthew Fisher
X: @matt_r_fisher
Host of Healthcare de Jure – #HCdeJure
On January 6, 2025, the Department of Health and Human Services officially published a notice of proposed rulemaking to modify and update the HIPAA Security Rule. The timing of the proposed rule leaves any sort of immediate action with a lot of uncertainty (changing administrations bring changing priorities and delays). Leaving aside the political issues, there is broad recognition that the current form of the Security Rule does not sufficiently address the current state of technology, which cuts across a whole host of viewpoints. Optimistically, that will translate to this proposed rule not disappearing into a black hole, but actually resulting in a new rule that helps advance security in healthcare.
Big Tickets from the Proposal
The Security Rule has largely been the same since it was originally introduced in 2003, albeit with some tinkering over the years. The biggest “tinkering” was with the 2013 Omnibus Rule which made business associates directly responsible for complying with the Security Rule. However, those additions did not get into the fundamental requirements of the Security Rule. Those basic building blocks are the ones that have been relatively static. It is important to state that being static in terms of base requirements is not in isolation a bad thing because the Security Rule has always been flexible in its application. It was written to be scalable across organizations of different sizes and arguably did a good job of allowing for the evolution of technology. The shortfall in this day and age though is that it does not necessarily require utilization of a broad enough array of available tools to enhance security. That in turn results in a race to the minimum as an outgrowth of the misperception that HIPAA sets security standards by itself.
Everything is Required and in Writing
Getting into the actual proposed rule, the first important change would be to remove the distinction between required and addressable elements. Instead, all requirements would become required with exceptions being kept few and very specifically spelled out. Under the existing Security Rule, addressable elements can be skipped if a justification for doing so is provided and the distinction is applied to elements that in the current world really should be in place (encryption is the posterchild in this regard).
Putting all elements of the Security Rule on the same footing could remove questions as to what an entity needs to do on the compliance front. The answer becomes everything absent meeting one of the few and limited exceptions acknowledged in the proposed rule.
Along with making all of the elements required, the proposed rule also wants to be clear that all policies, procedures, plans, and analyses must be in writing. Arguably, putting all of those activities and requirement sin writing is not a new requirement since a writing is likely one of the best ways to demonstrate compliance. If it isn’t in writing, it didn’t happen.
The key with an explicitly stated written documentation requirement will be actually following through on that component. An outcry should be expected that it will increase administrative burdens, but again a lot of the writing should already be created and generated on an ongoing basis. The clear statement that everything must be in writing should drive attention to documenting what is done. On the pessimistic side, handwringing can be expected and some bumps along the road, but hopefully those issues can be addressed relatively quickly.
Enhancing the Risk Analysis
The most common fault cited in HIPAA settlements announced by the HHS Office for Civil Rights is failure to conduct a risk analysis. Given the widespread issues around risk analyses, it should come as no surprise that the proposed rule expands upon the requirements of the risk analysis.
Clearer guidance and requirements for the risk analysis should be helpful. The current rule just says to conduct an accurate and thorough analysis without more explanation. The proposed rule seeks to insert additional requirements including (i) producing a written assessment, (ii) reviewing the technology asset inventory and network map, (iii) identifying all reasonably anticipated threats, (iv) identifying potential vulnerability, and (v) assessment the risk level of each threat and vulnerability. From one perspective, those statements just reinforce what should currently go into a valid and reasonable risk analysis. However, more specifically calling out the requirements may offer a bit clearer of a roadmap for organizations to follow when going through the risk analysis exercise.
The proposed rule clearly wants to encourage and require organizations to pay attention to security upfront and mitigate against preventable issues by planning ahead more. If an honest analysis occurs that really considers threats and vulnerabilities, then more accurate policies and procedures can be developed that will be forward looking. The rub will still be getting organizations to actually do the risk analysis and take it seriously.
Enhanced Contingency Planning
After a security incident or other issues occurs, it is too late to figure out how to respond and get operations back up. From that perspective, the proposed rule seeks to beef up requirements around contingency planning. Not only would written plans for data backups, disaster recovery, and emergency mode operations be needed, but reviewing, revising and testing all of the plans at least every 12 months would be required.
A plan on paper is essentially worthless if no one knows how to follow it or work with it on the fly. Improving understanding the contingency plans and really operationalizing will result in time and attention being diverted to these activities, but arguably that will take less time and be less costly than having to learn how to work through the plans in the middle of an actual crisis.
Business Associate Certifications
With business associates being at the root of so many recent data breaches, the proposed rule calls out certain actions for business associates to better acknowledge obligations under the Security Rule.
First, business associates would need to annually provided written verification to each covered entity that it deployed the technical safeguards required by the Security Rule. The written verification would also need to include a written analysis of the business associate’s relevant electronic information systems. The verification being somewhat technical in nature would need to be prepared by an individual at the business associate with appropriate knowledge of how the systems work and the associated cybersecurity controls.
The written certification is a significant new requirement and one that should be expected to carry potential liability issues with it. It should be relatively clear that the written verification will be held against the business associate in the event an incident occurs.
Business associates will also need to notify a covered entity within 24 hours of activating a contingency plan. This notification is in addition to the breach notification related obligations. The proposed rule tries to make clear that the notification is not intended to divert attention away from actually responding to an incident, but just to put the covered entity on notice.
All of these new requirements will need to be built into Business Associate Agreements, which would mean revising and/or amending a lot of existing agreements. It also adds to a checklist of actions that will need to occur on a recurring basis and cannot be overlooked. If the actions are skipped, then both organizations could expect to face consequences.
Miscellaneous Other Requirements
The proposed rule adds in a number of other requirements that reflect what could be considered industry standard security measures. For example, the proposed rule wants a vulnerability scan to occur at least very 6 months and penetration testing to occur at least every 12 months. Further, the proposed rule calls for network segmentation, which can control against the impact of a intrusion if everything is not contained altogether.
Multi-factor authentication would also become required under the proposed rule. Many organizations can face internal pushback when trying to implement MFA. Optimistically, a regulatory mandate will remove those barriers and make it table stakes for setting up security operations.
What Now?
With the clock ticking on submitting comments, now is the time to really dive into the proposed rule and consider the impact it could have. The comprehensive update to the Security Rule offers a very unique opportunity to help shape and influence a rule that will impact pretty much every corner of the healthcare industry. Be an active part of the government process and share your voice.
This article was originally published on The Pulse blog and is republished here with permission.