Read to learn about risk analysis and risk management strategy basics and how to develop your own risk management strategy.
This post contains the text from the White Paper: Your HIPAA Risk Analysis in Five Steps.
Download the PDF.
HIPAA requires that all entities annually perform a formal risk analysis: "The scope of risk analysis that the Security Rule encompasses includes the potential risks and vulnerabilities to the confidentiality, availability and integrity of all e-PHI that an organization creates, receives, maintains, or transmits." (45 C.F.R. § 164.306(a))
The HHS states, “Conducting a risk analysis is the first step in identifying and implementing safeguards that comply with and carry out the standards and implementation specifications in the Security Rule. Therefore, a risk analysis is foundational.” This requirement helps organizations identify, prioritize, and manage potential security risks to electronic personal health information (ePHI).
Besides helping you know where vulnerabilities, threats, and risks are in your environment, a risk analysis protects you in the event of a data breach or random audit by the HHS. Organizations that have not conducted a thorough and accurate risk analysis can expect to be hit with severe financial penalties.
In this white paper, you will learn risk analysis and risk management plan basics, plus five tips to help you conduct your own risk analysis and develop your own risk management strategy.
The purpose of the risk analysis is to help healthcare organizations document potential security vulnerabilities, threats, and risks.
A vulnerability might be a flaw in system security controls that could lead to ePHI being improperly accessed. For example, let’s say you have a system that requires your employees to log in using a username and password. That would be a system security control. However, let’s imagine that you don’t have a good process in place for removing account access when an employee leaves the company. That lack of process is a vulnerability.
A threat is the person, group, or thing that could take advantage of a vulnerability. For example, what would happen if you have a disgruntled employee who leaves the company? They might want to get back into the system and obtain ePHI after they were terminated. That disgruntled employee is a threat.
Risk is determined by understanding the probability of a threat exploiting a vulnerability and combining this probability with the potential impact to your organization. Thinking again about our disgruntled employee, how likely is it in your organization that someone will leave your organization and then gain improper access to ePHI, and what would be the impact to your organization if it happened? That exploit probability combined with exploit impact is your risk.
Threat + Vulnerability = Exploit
Exploit Probability X Exploit Impact = Risk
HHS recommends that organizations follow NIST SP 800-30 risk analysis standards or another industry-recognized risk analysis methodology. You’ll want to make sure that the following elements are in your risk analysis:
The purpose of the risk analysis is to help healthcare organizations document potential security vulnerabilities, threats, and risks.
To protect PHI, you have to know where it is created, received, transmitted, and maintained in your organization. This is called your scope. To identify your scope, you have to understand how patient data flows within your organization.
Start with the assumption that everything is in scope until you’ve verified otherwise. Verifying that a system is out of scope requires that you confirm proper network segmentation and make sure necessary controls are in place.
There are four main parts to consider when defining your scope:
You need to document where PHI is created, how it enters your environment, what happens once PHI enters, and how PHI exits.
In the PHI lifecycle, it’s important to identify where all PHI enters or is created. By doing this, you know exactly where to start with your security practices.
For PHI entry, think of both new and existing patient records. PHI can begin from patients filling out their own information on physical paper, to the front desk taking messages for their physicians, to business associates faxing you about current or former patient information.
Consider the following sample questions when determining where your electronic PHI is created and enters your environment:
You need to document where PHI is created, how it enters your environment, what happens once PHI enters, and how PHI exits.
You need to know what happens to PHI once it enters your environment. Is it automatically stored in your electronic health record (EHR) or electronic medical record (EMR) system? Is it copied and transferred directly to a specific department (e.g., accounting, marketing)?
Additionally, you must record all hardware, software, devices, systems, and data storage locations that can access PHI.
Here are common places PHI is stored:
When PHI leaves your organization, it is your job to ensure it is transmitted or destroyed in the most secure way possible. You and your business associate are responsible for how the business associate handles your PHI.
Here are some things to consider when PHI leaves your environment:
After knowing these processes, you should find gaps in your security and environment, and then properly secure all PHI.
Now, it’s time to find the gaps. These gaps in security and environment weaknesses are the whole reason we define scope. Weaknesses provide the ability for unsecured PHI to leak in or outside your environment.
The best way to find all possible leaks is by creating a PHI flow diagram. A PHI flow diagram documents all the information you found in your environment, and lays it out in a graphical format.
Detailed PHI flow diagrams are vital for your risk analysis because they show how people, technology, and processes create, receive, transmit, or maintain PHI, revealing where you need to focus security efforts and training.
Create a diagram that shows how PHI enters your network, the systems it touches as it flows through your network, and any point at which it may leave your network.
For example, patients fill out forms at hospitals, which pass patient records to doctors’ offices, which then transfer medical records to pharmacies. Or patients might add sensitive information to third-party patient portals online, which then automatically email a dental receptionist, who then prints and stores it in a giant file cabinet.
One of the first steps in protecting PHI is determining how much of it you have, what types you have, where it can be found in your organization, what systems handle it, and who you disclose it to. You should take time to interview personnel to document those systems and who has access to them.
You probably are not aware of every task and situation that your employees encounter on a daily basis or every aspect of their individual jobs. Interviewing personnel is one of the best ways to get further insight into how you’re interacting with and using PHI on a regular basis. It may help you discover access to systems or certain disclosures that you were not aware of.
For example, we often see large data storage areas where patient data lies around unprotected. Also, staff commonly create copies of patient data and leaves the copies unattended.
Another common scenario is when IT staff don’t fully understand which system components ePHI is being stored on. When this happens, they can’t fully protect the data, which can and does lead to large breaches. Make sure that your IT staff fully understands how you use ePHI and where you are putting it.
SecurityMetrics Security Analyst
Once you understand the scope of your PHI environment, you can start listing the vulnerabilities and threats related to that environment. Consider the following:
Consider these categories in particular as you think about your vulnerabilities, threats, and risks:
The HHS explains, “Vulnerabilities, whether accidentally triggered or intentionally exploited, could potentially result in a security incident, such as inappropriate access to or disclosure of ePHI. Vulnerabilities may be grouped into two general categories: technical and nontechnical. Nontechnical vulnerabilities may include ineffective or non-existent policies, procedures, standards or guidelines. Technical vulnerabilities may include: holes, flaws or weaknesses in the development of information systems.”
Some examples of vulnerabilities are:
A vulnerability is a flaw in components, procedures, design, implementation, or internal controls. Vulnerabilities can be fixed.
A threat is the potential for a person or thing to take advantage of a vulnerability.
According to the HHS, “There are several types of threats that may occur within an information system or operating environment. Threats may be grouped into general categories such as natural, human, and environmental.”
Examples of threats can be:
Risks are the probability that a particular threat will take advantage of a particular vulnerability and the resulting impact on your patients and organization.
For example, a system that allows weak passwords is vulnerable to attack. The threat is that a hacker could crack the password and break into the system. The risk is the damage caused when the hacker accesses unprotected PHI in your system.
According to the HHS, “Risk is not a single factor or event, but rather it is a combination of factors or events (threats and vulnerabilities) that, if they occur, may have an adverse impact on the organization.”
Examples of risks:
The likelihood that a threat can take advantage of a vulnerability, combined with the impact of that exploit, equals your risk.
You need to decide what risks could and/or will impact your organization, your data, and ultimately, your patients. Risk ranking is a crucial part of your risk analysis that will eventually translate to your risk management plan.
To analyze your risk level, consider the following:
Every vulnerability and associated threat should be given a probability level, and the resulting exploit should be given an impact level. Combining probability and impact gives you the risk level. The typical designations are ‘high,’ ‘medium,’ and ‘low.’ Documenting this information results in a prioritized list of security issues.
Examples of risk designations:
As we work with individual entities, we find that because they attempt to perform a risk analysis with only in-house skills, a non-security professional, or an unqualified third party, many vulnerabilities and risks are missed.
In one instance, we were brought in to perform a risk analysis only six months after a different third party had conducted an incomplete risk analysis. Within the first hour of review, we found a number of major problems, including holes in their firewall that were overlooked. A complete and thorough risk analysis is critical to start securing your patient information.
An in-house risk analysis can be a great first step toward HIPAA compliance, but if your staff is stretched too thin (as they almost always are), you probably won’t see accurate and thorough results. Additionally, IT staff is rarely trained to perform formal risk analyses. Risk analysis is a skill set that requires extensive experience in information technology, business process flow analysis, and cybersecurity, so it is unrealistic to expect your staff to be able to accomplish this for you.
A complete and thorough risk analysis is one of the best ways for you and your organization to make intelligent and informed business decisions. Without understanding your risk, how do you best decide where to put your resources?
SecurityMetrics Security Analyst
The risk analysis outcome, with its risk rankings, provides the basis for your risk management plan. The risk management plan is the step that works through issues discovered in the risk analysis and provides a documented instance proving your active acknowledgment (and correction) of PHI risks.
There are many ways to approach the Risk Management Plan, but ultimately the process will consist of three main steps:
The HIPAA Security Rule requires you to complete the risk analysis and risk management plan at least once a year.
After a plan is created to address risk analysis concerns, it’s time to implement it. Starting with the top-ranked risks first, identify the security measure that fixes that problem. For example, if your risk is that you still use Windows XP (an unsupported system with known vulnerabilities that cannot be patched), your security measure would be to update your computer system or work with your vendor to properly mitigate the proposed risk.
Another important part of the risk management plan is documentation. The HHS will want to see your risk management plan, your risk management plan documentation, and regular progress on addressing the items identified in your risk management plan.
As far as the HHS is concerned, if it’s not documented, it never happened.
Although specific items included in a Risk Management Plan vary, the following points are industry best practices:
Updating, implementing, and documenting your risk management plan should be an ongoing process, especially when new systems and processes are added to the PHI environment.
It’s difficult—if not impossible—to find every weakness in your organization on your own. To take your security to the next level and to avoid weaknesses in your system, consider implementing additional security services such as:
A complete and thorough risk analysis is critical as the launching pad for securing your patient information.
A risk analysis should occur at least annually and after significant changes in your network. It should also help provide direction on what vulnerabilities you should address first, based on risk rankings.
Conducting a risk analysis can be a lengthy process, so start by identifying (and resolving) your organization’s top weaknesses and repeat the risk analysis process for medium and low risks. Then, in your risk management plan, determine and document necessary actions to secure your network.
Remember, the HHS has stated on multiple occasions they will make examples of healthcare organizations that put PHI at risk. Given the importance associated with the Risk Analysis and Risk Management Plan, you may want to consider working with a HIPAA security expert to conduct a thorough risk analysis.
We help customers close security and compliance gaps to avoid data breaches. Our forensic, penetration testing, and audit teams identify best security practices and simplify compliance mandates (PCI DSS, HIPAA, HITRUST, GDPR). As an Approved Scanning Vendor, Qualified Security Assessor, Certified Forensic Investigator, we have tested over 1 million systems for security.
.svg)
