Information security pros working in the healthcare sector quite often experience a high degree of frustration and anxiety when it comes to the Security Rule‘s “addressable” implementation specifications. As any healthcare provider will tell you, the addressable requirements of the security rule tend to be among the more difficult to meet and more technically focused of the mandates with the Security Rule.
Historically, these addressable requirements have tended to fall by the wayside. This situation is undesirable from a compliance perspective. But there could be some good news on the horizon. Shifts in the way that organizations approach IT (particularly cloud computing) open up opportunities for organizations to revisit (and in many cases, finally meet) these addressable controls.
What Does “Addressable” Mean, Anyway?
HIPAA Security is split into three different sections (administrative, physical and technical), each of which outlines the required standards of that section. Each standard is supported as required by “implementation specifications” that describe how the standards should be carried out.
For example, the “technical safeguards” section (45 CFR 164.312) defines the standard of “transmission security” that says that covered entities must protect transmission of data when in transit on the network; one of the implementation specifications within that section is encryption of the data [164.312(e)(2)(ii)] — because implementing encryption on all network traffic is hard to do, this requirement is addressable.
But “addressable” doesn’t mean “optional.” Even though covered entities are allowed quite a bit of latitude for how they meet individual addressable specifications, they must still put together a documented plan for addressable implementation specifications. HHS (the department of Health and Human Services — the organization ultimately responsible for HIPAA Security and its enforcement) clarifies what addressable means via their frequently asked questions list:
“In meeting standards that contain addressable implementation specifications, a covered entity will do one of the following for each addressable specification: (a) implement the addressable implementation specifications; (b) implement one or more alternative security measures to accomplish the same purpose; (c) not implement either an addressable implementation specification or an alternative. The covered entity’s choice must be documented … The decisions that a covered entity makes regarding addressable specifications must be documented in writing. The written documentation should include the factors considered as well as the results of the risk assessment on which the decision was based.”
Meaning, the covered entity will ideally implement the control required by the implementation specifications. But even if they don’t, they still have work to do. Specifically, they must document what their choice is — and include in that documentation the supporting factors that they considered in making that choice, as well as the supporting risk analysis supporting those considerations (note that this implies that they have a risk analysis in the first place). In practice, many organizations do two things: refrain from implementing the control fully, and refrain from documenting their choice in the manner required. This leaves the institution in the precarious position of not fully complying with the law — at least not in the manner intended by HHS.
Enter the Cloud
But cloud computing changes the dynamics of this a little bit. Why? Because in a cloud computing scenario, most security activities occur in partnership between vendor and client — in other words, while ultimate responsibility for compliance always resides at the covered entity, the actual implementation of certain operational aspects of security occur at the business associate cloud provider. For example, the specifics of human resources controls like employee screening will need to extend to cloud provider personnel, physical access requirements for off-premises data centers need to be implemented at the remote facility, and technical controls like network monitoring may be implemented as part of a package that you’ve purchased.
The point is that some portion of the specific technical responsibilities may need to be shouldered by your vendor(s) in areas where you’ve employed a cloud model in a manner that intersects protected health information. In other words, if you have some portion of your infrastructure that contains PHI — and that area has undergone a full or partial transition to a cloud model, you will need to address all of the standards and supporting implementation specifications (both addressable and otherwise) for HIPAA security as part of the relationship that you have with your cloud provider. This gives you the opportunity to re-raise specific technical controls like encryption, integrity controls, transmission protections, etc., that may have been deferred due to cost or other technical constraints. Budget allocated for cloud transition will generate a lot of activity — by participating in the planning for that activity and looking for targets of opportunity, you may just find areas where you can target requirements that proved problematic during your initial compliance efforts.
Beyond allowing you to just revisit these topics, you can also in some cases draw directly on your cloud vendor to help satisfy some of the challenges in this area as well. First of all, recall that under HITECH, business associates are under the gun to address the specific mandates of HIPAA security in the same way as covered entities. So, as a supporting business associate, your cloud services vendor is on the hook for these controls just as much as you are — so provided you have a BAA with them, you have quite a bit of leverage should they attempt not to support you in implementing these controls.
But aside from just vendor implementations of the specific controls, you can also draw on documentation they may have describing particular security controls. For example, it is well within your rights to ask your cloud providers specifically how they implement the required technical specifications — both the addressable and the required ones. Asking for this in writing gives you an artifact that you (potentially) didn’t have before: a written description of how an addressable control is implemented — just like HHS spells out as a requirement. If you’ve been challenged documenting these controls internally, leveraging vendor documentation in this area can help you get farther than you may have been able to in the past. Granted, this may only apply to the portion of the PHI ecosystem that intersects the vendor’s environment, but some is better than none.
It’s quite natural for security pros to approach a cloud migration with caution, but in many cases a cloud transition can help you accomplish security goals that have otherwise been problematic.
Loading ...
