HIPAA Security Rule: 5 Common Shortcomings (Administrative Safeguards)

Go beyond HIPAA’s language to achieve better security and compliance. Here’s how:

When we help clients with HIPAA assessments—whether it’s a security risk analysis or a gap analysis of security controls—we tend to see many of the same shortcomings again and again. The shortcomings I’m referring to can exist even if you follow all requirements as stated in the HIPAA Security Rule.

In this post, we’ll take a look at some of the Administrative Safeguards found under the HIPAA Security Rule and how merely sticking to the Rule’s language is simply not good enough. In other words, if you simply do what a particular safeguard says you are supposed to do—and nothing more—you’re setting yourself up for failure from both a security and compliance standpoint.

 

1. Not Conducting a Proper Security Risk Analysis

In terms of regulatory risks, not performing a proper risk analysis ranks among the highest risks we see. The risk analysis language in § 164.308(a)(1)(ii)(A) of the HIPAA Security Rule is quite sparse. In reality, you have to review the requirements published by HHS Office for Civil Rights (OCR) in “Guidance on Risk Analysis Requirements under the HIPAA Security Rule.”

Also keep in mind that OCR doesn’t consider a mere gap analysis of security controls to be a risk analysis. Check out this newsletter published by OCR in April 2018 called “Risk Analyses vs. Gap Analyses – What is the difference?” One of the first things OCR will request during a compliance review (in the aftermath of a breach, for example) is a copy of your most recent risk analysis. Not being able to provide one, or providing a deficient one, can get you into additional hot water.

Be sure your most recent risk analysis meets all of these requirements and can be provided to OCR at a moment’s notice.

 

2. No Risk-Based Approach for Managing Security Risks 

The Security Rule’s requirements relating to managing security risks are also light on specifics. The Security Management Process standard itself is vague (“Implement policies and procedures to prevent, detect, contain, and correct security violations.”). So too is the Risk Management requirement found at § 164.308(a)(1)(ii)(B) (“Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with §164.306(a)”).

What the Security Rule leaves out—and what makes the most sense from a security standpoint—is to follow a risk-based approach for managing the risks you have identified.

Even if they have taken the time to identify risks, organizations often lack a clearly defined approach for what to do about them. They don’t prioritize efforts to manage risks based on overall risk ratings. That means a risk rated as “high” might take a backseat to lower-rated risks in terms of remediation efforts. Organizations also fail to track their risks and corresponding risk-management activities over time.

For further information, consult the NIST Cybersecurity Framework. The Framework incorporates risk-management processes to enable organizations to inform and prioritize decisions relating to cybersecurity.

 

3. Lack of a Current and Accurate ePHI Inventory

Although not tied a specific Administrative Safeguard per se, we believe keeping a current and accurate ePHI inventory is critical for several reasons. (As an aside, there is the Accountability requirement at § 164.310(d)(2)(iii) found under the Physical Safeguards, but the kind of inventory discussed here is different).

Organizations often overlook places where ePHI exists. What about your accounting software? Doesn’t that contain ePHI? Or those all-in-one scanner/printer/fax/copy machines over in the corner?

Simply put, ePHI has to be on your radar in order to safeguard it properly. Having an up-to-date and current ePHI inventory gives management and IT staff an important high-level view of all places where ePHI resides so that they can ensure the necessary controls are in place to protect it.

Plus, a fundamental step in performing a security risk analysis according to OCR requirements (see above) is identifying all ePHI assets. Because you have to develop a list of ePHI assets for your risk analysis anyway, you might as well keep it updated.

If you don’t already have an ePHI inventory, work on developing one. The inventory does not have to be extremely detailed, particularly when developing one for the first time. It’s also a good idea to have individuals from across the organization review the inventory to help ensure it is complete and accurate.

 

4. Inadequate Security Incident Response Procedures

Having a general sense of what to do in the event of a security incident is not good enough. It’s also not enough to devote a total of one or two sentences in a policy/procedure saying something like, “Our policy is to investigate and contain security incidents.”

We recommend having specific procedures in writing, communicated to all relevant stakeholders, and tested/practiced under simulated drills such as tabletop exercises.

Knowing the steps to take in response to a security incident—and practicing those steps—can help minimize an incident’s impact.

Go beyond what the Security Rule says by referring to NIST SP 800-61, Revision 2, Computer Security Incident Handling Guide.

 

5. No Business Associate Oversight

A significant amount of ePHI is now accessible by business associates who provide services to covered entities. While many organizations ensure they have a proper business associate agreement in place, they often stop there and do nothing more to oversee their business associates.

While having proper contractual language in vendor agreements is important, it’s only one piece in the much bigger puzzle of managing vendor security risks. Just because vendors contractually agree to have certain security controls in place doesn’t necessarily mean they will. Even if they do have those controls in place, bad things can still happen.

Go beyond what is stated in the Security Rule’s business associate requirements at §§ 164.308(b)(1) and (4). Develop a more in-depth plan and approach for managing security risks presented by your vendor relationships at all stages of the relationship lifecycle.

 

Conclusion

The list above includes common shortcomings we encounter when performing HIPAA assessments for clients. These shortcomings can exist even if the organization is abiding by the language found in the HIPAA Security Rule.

If your organization is subject to HIPAA, be aware of these shortcomings and consider the recommendations included above.

While this post concerns Administrative Safeguards, in future posts we’ll take a look at common shortcomings under the Physical Safeguards and Technical Safeguards of the Security Rule.

Have questions about HIPAA? Get in touch with LMG today.  At LMG Security, We Make Nothing Happen.