HIPAA Risk Analysis and Risk Management Program Considerations
Over 90 percent of the Office for Civil Rights (OCR) HIPAA settlement actions regarding ePHI breaches involved findings of an insufficient risk analysis or risk management program. This highlights how important it is for organizations to understand what is required for compliance with these HIPAA requirements. Doing so involves a deeper dive into the requirements and making note of key points that should be considered when doing risk analysis / risk management activities to help ensure compliance. The applicable HIPAA requirements are listed below:
§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.
This is the Risk Analysis requirement and will occur first, followed by the risk management requirement.
§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).
This is the Risk Management requirement, that states organizations should make informed decisions based on results of risk analysis from §164.308(a)(1)(ii)(A) to reduce risk to an appropriate level. Note that this requirement also makes a reference to §164.306(a).
§164.306(a): Covered entities and business associates must do the following:(1) Ensure the confidentiality, integrity, and availability of all electronic protected health information the covered entity or business associate creates, receives, maintains, or transmits. (2) Protect against any reasonably anticipated threats or hazards to the security or integrity of such information. (3) Protect against any reasonably anticipated uses or disclosures of such information that are not permitted or required under subpart E of this part; and (4) Ensure compliance with this subpart by its workforce.
This is a very broad statement, but essentially, it’s saying that risks and vulnerabilities must be reduced to a reasonable and appropriate level for all the requirements in the HIPAA Security Rule.
One of the main things that creates confusion with these requirements is how the language isn’t prescriptive. Some organizations believe that doing a high-level risk assessment as a company meets the requirements, but that is not the case. With the background on the HIPAA requirements now covered, here are some points for organizations to consider in order to develop a HIPAA compliant risk analysis / risk management program.
In many of its breach investigations, the OCR has found that the scope of systems covered in an organization’s risk analysis / risk management program failed to consider all places ePHI could be located in their environment. Knowing where ePHI can be located can be difficult but it is a very important part of compliance, and it is surprising how often companies aren’t exactly sure where ePHI resides within their systems. In any case, it’s better to be safe than sorry—if an organization is handling ePHI as part of the services provided, and it is unknown which systems ePHI is restricted to, an organization should assume that all systems in the environment are in scope for HIPAA. For efficiency purposes, a good approach, when possible, is to segment out systems that could receive, transmit, or store ePHI—that can help limit the scope. But at the end of the day, it’s very difficult to implement an effective risk analysis / risk management program without knowing how ePHI flows through the environment or what systems are in scope for HIPAA. As such, identifying ePHI and the various environments that it touches within an organization is the necessary first step in developing a HIPAA compliant risk analysis / risk management program.
Once the in-scope systems and locations where ePHI is stored or could be stored are identified, it’s time to determine how that organization will carry out their risk analysis. Already, there are some great resources for this that seem to fly under the radar, including the OCR Guidance on the Risk Analysis Requirement. The OCR guidance is not an exact template for performing a risk analysis, but what it does do is clarify the expectations of the OCR in terms of high level steps that should at least be part of the process, including 9 essential elements to a quality risk analysis. Given that the OCR is the organization that investigates breaches, incorporating their guidelines is definitely something to consider.
Additionally, within this risk analysis guidance by the OCR, there are multiple references to NIST SP 800-30—the Guide for Conducting Risk Assessments. By no means does it say that this is the risk assessment methodology that needs to be followed, but it is a well-known and established methodology, and clearly the OCR values it as a guide. As such, it should also be considered as another option while developing a risk analysis program.
Another option for organizations is the Security Risk Assessment Tool, which was developed, in collaboration with the OCR, by the Office of the National Coordinator for Health Information Technology (ONC). The nice thing about this tool is that it not only guides the risk analysis process, but it also pulls in the actual requirements in the HIPAA Security Rule and thereby forces consideration of compliance with those requirements. The ONC’s tool allows organizations to identify where they might not be meeting HIPAA Security Rule requirements, but also considers the relevant risk analysis items related to the given requirement. It compels an organization look at what controls they do have in place to meet the specific HIPAA requirements, and provides some items for compliance consideration. Example threats, vulnerabilities, and potential safeguards for each requirement are included. Organizations also have a place to identify if a risk to the organization for each specific requirement is high/medium/low for likelihood, impact, and overall risk.
Having already discussed a few potential options to help guide organizations in their risk analysis processes for compliance with §164.308(a)(1)(ii)(A), being in compliance with §164.308(a)(1)(ii)(B) is the next phase. Once the risks have been analyzed and prioritized, controls should be put in place to reduce the risks to a level that is “reasonable and appropriate” to comply with the HIPAA Security Rule requirements.
Again, the OCR’s guidance document comes into play—one key requirement referenced within it is §164.316(b)(2)(iii) Review documentation periodically, and update as needed, in response to environmental or operational changes affecting the security of the electronic protected health information, which is an area that a lot of organizations end up overlooking. Some complete a great risk analysis, implement controls that address the identified risks to a “reasonable and appropriate” level, and then forget about it. They do not have a formal process to reassess risk on a specified basis, and don’t have a process to perform an updated analysis when new substantial risks are identified due to a major change in their environment—some examples of such new areas of risk include new technologies introduced, or new business operations that are implemented. As a result of such oversights, the OCR has issued multiple fines to organizations that failed to incorporate new risks into their risk program. This has made it clear that this step is expected and necessary in order to be in compliance with these HIPAA requirements.
So how frequently do companies need to do revisit their risk analysis / risk management process? HIPAA doesn’t actually specify how frequently, but if an organization decides to only perform this review, say every 3 years, it’s important that they make sure they can make a good case supporting why time frame that is appropriate. Ideally, an annual reassessment, or a reassessment after a major change that introduces new risks for consideration should be the practice in place. The best case scenario would be an integrated risk analysis and management process that is part of new technology or business operations planning—if an organization is looking to add a new technology, make major infrastructure changes, or get into a new line of business that impacts the HIPAA environment, this would trigger the risk analysis and management process, and those risks would be considered on the front end of the planning, not after everything has been implemented.
The importance of these HIPAA risk analysis / risk management requirements cannot be understated, and it’s clearly easy to fall into common shortcomings when establishing compliance. This area should be at the top of any organization’s list of priorities that is required to comply with HIPAA, as overlooking these risk requirements increases the possibility of a breach for failing to consider relevant risks. Nobody really wants a large fine from the OCR, or a spot on the OCR Wall of Shame website, so make sure to reference the guidance tools that are already out there and routinely reassess all environments in order to ensure continual, organizational compliance with the HIPAA risk analysis / risk management requirements.
About DOUG KANNEY
Doug Kanney is a Principal at Schellman & Company, Inc. Doug leads the HITRUST and HIPAA service lines and assists with methodology and service delivery across for the SOC, PCI-DSS, and ISO service lines. Doug has more than 10 years of combined audit experience in both public accounting and private industry. Doug has provided professional services for multiple Global 1000, Fortune 500, and regional companies during the course of his career.