In April of 2013 the Office of Civil Rights, the branch of the Department of Health and Human Services that oversees compliance with the HIPAA Security Rule, started releasing analysis from their pilot audit of Security Rule compliance. In 2012, OCR and their audit partner KPMG set out to assess 115 organizations: hospitals, insurance companies, clearinghouses and business associates. Their essential goals were to develop and test a new HIPAA audit program, and to see what the current state of HIPAA compliance was. And what they found was that in terms of HIPAA Security Rule compliance … you’re probably doing it wrong.
Two thirds of the organizations audited in the pilot program were not aware that they were supposed to conduct a risk assessment. This one fact is stunning because when you read the HIPAA Security Rule the first specification is that you must conduct a risk assessment. This is probably evidence of both the fact that people are not reading the regulation and/or the guidance material from OCR, and people do not know what risk assessments are.
On the first point, I’ll remark that I very often encounter people who show me the research they’ve done on HIPAA compliance, and they provide hyperlinks from every known website but for one ending in the domain “hhs.gov” or “.gov” for that matter. For some reason people do not read the source material. They instead look for opinions or guidance from people who are not the authorities on the subject. But the regulation and the guidance from OCR are readable and understandable. You may need someone to help implement the requirements in the regulations and guidance, but the instructions are very clear. To make things worse, many of the websites I am being sent hyperlinks to just do not understand the core of the HIPAA Security Rule, which gets us to our next point.
American managers generally do not know what information risk assessments are. So before we go much farther, let’s be clear about what we mean by an information risk assessment.
- An information risk assessment is the means by which we both identify and justify our information security safeguards. This is true for any U.S. regulation that protects personal information.
- Information risk assessments are management’s analysis of what negative impacts might occur if information is somehow compromised.
What HIPAA is trying to tell us is, “Don’t try to implement all possible safeguards to their fullest extent. Just implement safeguards that reduce your risks to a reasonable and appropriate level.” The way we calculate reasonable and appropriate risk is through a risk assessment.
Further, the OCR is telling us, “Use the freely available standard ‘NIST Special Publication 800-30’ to estimate that risk.” NIST SP 800-30 provides detailed guidance for building a risk register that will help you identify your organization’s “duty of care” for protecting health information, and will help you determine which safeguards would help you meet that requirement.
You may hear criticisms that risk assessments, and particularly NIST SP 800-30, are insufficient for identifying true risks. These criticisms are also in line with complaints that “compliance is not security.” While both of these criticisms are defensible, consider this point; if two-thirds of organizations that must be HIPAA compliant don’t even know they should conduct risk assessments, then starting with a method as simple as NIST SP 800-30 moves them further ahead than where they are today.
So let’s also discuss what you will need in order to conduct a quality information risk assessment.
- Ensure that you are using a simple process, such as NIST SP 800-30 or ISO 27005, especially if you are just starting your risk management processes. These standards will guide you toward making a spreadsheet that helps you systematically identify and score your information risks.
- Define your impact scores using values that matter to your mission. If you use impact scores such as “High,” “Medium,” and “Low” without defining those values, then your risk assessment participants will be using widely varying criteria for determining what those values mean to them. Rather, use guidance language such as “’High’ means more than 500 patients will have their PHI exposed. ‘Medium’ means up to 499 patient records will be exposed, and ‘Low’ means none will be exposed.”
- Ensure that your highest level executives help you define what the impact score values will mean. When you budget and plan your safeguards, you will be comparing the cost of those safeguards to the potential impact that they are reducing. This comparison will be helpful if the people who approve budgets and priorities agree with the impacts, knowing that the impacts are based on the mission of the organization.
- Properly identify your vulnerabilities. Examine each information asset that will have some contact with PHI. Determine what kinds of controls should be applied to that asset using an information controls standard such as NIST SP 800-53 or ISO 27002 [eg. being sure to at least include the Security Rule specifications]. If those controls are not in place or are not effective, then you have found a risk.
- Work with experts to determine what threats could take advantage of those vulnerabilities and compromise your assets. This is critical. If you are estimating your duty of care in a risk assessment, then you should know what threats you could expect to experience. Neglected network services, advanced malware, theft, loss of equipment, hacks, careless or uninformed employees, weak web applications, poorly configured devices and user devices on the network are all threats that ebb and flow in their probability. If you do not have this expertise on hand, then hire it. A risk assessment that does not include currently expected threats will not identify your risks and you will not know your duty of care as a result.
- Use the same risk calculation for the proposed safeguard as you are using to calculate the initial risk. This way, you can justify your safeguard as one that will be reasonable by comparing the cost of the safeguard against the originally assessed impact.
So do what the OCR is asking you to do instead; assess your risks, then apply controls that will reduce your risks to a reasonable and appropriate level.
If these companies didn’t know about the Risk Assessment then they never read the Security Rule. It is the #1 item.
As far as the advice to perform the risk assessment and then mitigate or eliminate those risks is a little off the mark in my opinion. If the Risk Assessment isn’t focused on the flow of (e)PHI information in your organization then it is too broad and you will probably be expending time and effort that you shouldn’t. The steps to complying are:
1. Get a copy of the Security Rule. It is readily available on the HHS website.
2. Identify where (e)PHI is touched or manipulated. This can be accomplished by an easy interview with business owners and documenting the business processes.
3. Identify your control gaps
4. Put a plan together to close those gaps.
It isn’t that complicated.
Also to the comment about performing a Risk Assessment and using that as your guidance you will miss one of the big required items, the Sanction Policy which is a required item.
And don’t forget that HIPAA is focused on both ePHI and PHI. Which means if the PHI information exists in a non electronic format (printed pages for example) you still need to provide proper controls. So don’t forget to check out the HIPAA Privacy Rule as well.
Should the risk assessment include a vulnerability assessment? By VA, I mean the process where a team evaluates the implementation of the security controls to determine if they are working as expected.
The terminology of risk management drives me crazy: risk assessment, risk analysis, risk ratings, etc.
Thanks, this is a helpful article.
Your comment was helpful because I realized that I had missed stating that vulnerabilities should be analyzed against the HIPAA Security Rule itself, not just ISO 27002 and NIST SP 800-53. Of course they should! Thanks for catching that. We added an editorial correction to the original blog posting.
Also worth mentioning is that we recommend using an information security standard in the risk assessment, such as ISO 27002 or NIST SP 800-53 so that when the risk assessment is being conducted we can describe information security controls based on a well-known standard, not on loose interpretations. For instance, if I am addressing access control specifications, I want to look at the access controls in NIST SP 800-53 to see what would be expected of me. I’d rather not rely on someone’s guess as to what “access control” means.
As for the fundamental role that risk assessments play in HIPAA compliance, OCR is pretty clear on what they are expecting. They are pushing us further than just a gap-fix compliance model. They want to be sure that we are cognizant of threats, impacts, likelihoods and they want us to decide on what our safeguards should be based on those factors. This actually gives us reason to not go full-bore on implementing all possible safeguards, but at least to the degree that they make our risks reasonable and appropriate.
Here is a really helpful guide by OCR on how to accomplish an information risk assessment for HIPAA Security Rule compliance. It requires extra work up front, but it saves a lot of organizations a lot of security resources when it is completed.
Some of our clinical clients have been able to justify iPads after analyzing the risks and safeguards in their risk register.
Yes, the risk assessment will require an evaluation of vulnerabilities. I’ll provide a break-down of the exact steps in my next blog post, but in brief, your risks are based on analysis of:
1. Information assets.
2. Existing controls for those assets (controls that you are analyzing should come from the Security Rule itself, and other security standards that are appropriate for your environment).
3. Vulnerabilities, if controls are not strong enough.
4. Threats that can take advantage of vulnerabilities.
5. The likelihood and impact of threats, and a risk score based on the likelihood and impact.
6. And finally proposed safeguards that would bring that risk score down to a reasonable and appropriate level.
And while we often recommend that vulnerability analysis is at least based on table-top analysis by the owners of the information assets, in many circumstances it is also important to review configurations (if available), and to run a vulnerability scan or a penetration test. These options vary based on the maturity of the environment, the maturity of the organization or pre-existing knowledge of the on-the-ground configurations.
If you see the hyperlink in my previous comment, you’ll see the guidance OCR provides on how those risk assessment steps work. It’s a pretty easy read with big pay-off.