This post contains the text from the White Paper: Your HIPAA Risk Analysis in Five Steps. Download the PDF below.
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.
UNDERSTAND THE BASICS
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:
- Scope analysis
- Data collection
- Vulnerability and threat identification
- Current security measure assessment
- Likelihood of threat exploiting vulnerability
- Potential impact of exploit
- Risk level
- Periodic review and update
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:
- Where PHI is created or enters your organization
- What happens to it in your systems (processing, storage, etc.)
- Where PHI leaves your environment
- Where potential or existing leaks may be
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:
- Email: How many computers do you have, and who can log on to each computer?
- Texts: How many mobile devices do you have, and who owns them?
- EHR entries: How many staff members do you have entering data?
- Faxes: How many fax machines do you have? Do they accept PHI?
- Mail: How is incoming mail handled? Does it contain PHI?
- New patient papers: How many papers are patients required to fill out, and where? Front desk? In the examination room?
- Business associate communications: How do business associates communicate with you? Do they interact with PHI?
- Databases: Do you receive marketing databases of potential patients to reach out to? What records and data do you enter into your database?
- Websites: Do you accept PHI online?
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:
- EHR/EMR systems
- Mobile devices
- Operating systems
- Calendar software
- Encryption software
- Wireless (networked) medical devices
- Shred bin containers
- Physical locations/storage (e.g., filing cabinets)
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:
- Business associates: Are you sending data through encrypted transmission? Are they? Is data sent to them kept at a minimum?
- Email: What procedures are in place for how patients receive data?
- Flash drives: What policies are in place?
- Websites: Are patients able to access PHI online? How are those pages protected?
After knowing these processes, you should find gaps in your security and environment, and then properly secure all PHI.
WHERE DOES PHI LEAK?
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.
STEP 2: IDENTIFY VULNERABILITIES, THREATS, AND RISKS
Once you understand the scope of your PHI environment, you can start listing the vulnerabilities and threats related to that environment. Consider the following:
- What vulnerabilities exist in your systems, applications, processes, or people?
- What threats exist that could exploit each of those vulnerabilities?
- What probability does each potential exploit carry?
Consider these categories in particular as you think about your vulnerabilities, threats, and risks:
- Digital (e.g., weak passwords)
- Physical (e.g., not shredding PHI)
- Internal (e.g., employees)
- External (e.g., hackers)
- Environmental (e.g., fires)
- Negligent (e.g., unknowing employee)
- Willful (e.g., disgruntled former employee)
WHAT ARE YOUR VULNERABILITIES?
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:
- Unpatched operating system software
- Website coded incorrectly
- No office security policies
- Misconfigured or no firewall
- Computer screens in view of public patient waiting areas
A vulnerability is a flaw in components, procedures, design, implementation, or internal controls. Vulnerabilities can be fixed.
WHAT ARE YOUR THREATS?
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:
- Geological threats, such as landslides, earthquakes, and floods
- Malware, such as viruses, worms and ransomware
- Inadvertent data entry or deletion of data
- Power failures
- Chemical leakage
- Social engineering
WHAT ARE YOUR RISKS?
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:
- Remote access to a PHI system with a weak password. If your PHI system permits weak passwords and remote access, that combination results in a system vulnerability. An external hacker interested in gaining remote access to that system is the threat. The risk would be the likelihood that a hacker can brute force the password and gain access to your system, and to the PHI it contains, combined with the impact to your organization this exploit would cause.
- Disgruntled ex-employee with access to PHI. If your organization doesn’t have a process to remove terminated employee access in a timely manner, that’s a vulnerability. A terminated employee trying to access systems is a threat. The risk would be the likelihood that a disgruntled ex-employee would successfully access your systems after termination, combined with the impact this exploit would cause your organization.
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:
- Probability: Just because a threat exists, doesn’t mean it will be able to take advantage of a vulnerability in your organization. For example, organizations in Florida and Maine technically could both be affected by a hurricane. However, Florida-based organizations have a higher hurricane risk level, because the likelihood of hurricane landfall is greater in Florida than in Maine.
- Impact: How would a particular event affect your organization? While you don’t want any PHI to be accessed improperly, the impact to your business for one leaked record will likely be smaller than if hundreds or thousands of records are exposed. For example, while a computer screen might accidentally show PHI to a patient in the waiting room, it can only show one record at a time, while and attacker accessing your unsecured Wi-Fi could gain access to entire databases.
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:
- Remote access to a PHI system with a weak password. Thinking of our earlier example, there is a high probability that an external hacker will brute force the password and gain access to your system, and to the PHI it contains. This would result in a costly impact to your organization. Because the probability of the vulnerable system being compromised by a hacker is high, and because the resulting impact to the organization is also high, you would mark this as a high risk.
- Disgruntled ex-employee with access to PHI. Thinking back to our original scenario when discussing threats, vulnerabilities, and risks, let’s add detail to the story. In your organization’s case, perhaps a process doesn’t exist to remove terminated employee access in a timely manner. Let’s also imagine that you belong to a small practice with few employees and very low turnover. In this case, the vulnerability exists (access after termination) but the probability is low of the threat taking action against it (terminated employee tries to access systems). The impact to your organization, if the threat were to exploit the vulnerability, could still be high, depending on the number of records accessed and how they were used. In this case, with a low probability and a high impact, you might mark this as a medium risk.
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?
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:
- Plan how you will evaluate, prioritize, and implement security controls.
- Implement security measures that address the greatest areas of risk (or your biggest ROI) first (e.g., fix firewall rules).
- Test the security controls you’ve implemented and be sure to keep an eye out for new areas of risk.
The HIPAA Security Rule requires you to complete the risk analysis and risk management plan at least once a year.
IMPLEMENT YOUR RISK MANAGEMENT PLAN
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.
Although specific items included in a Risk Management Plan vary, the following points are industry best practices:
- Security measures: You need to determine appropriate security measures and resolutions to mitigate each line item contained in your risk analysis.
- Risk level: Each vulnerability discovered should be assigned a risk level, based upon benefit, ROI, budget, and internal and external resources.
- Date completed: Including a completion date is great for both HHS documentation and your own records.
- Completed by: This is beneficial for all organizations, especially in instances where two or more people (e.g., doctor and office manager) are completing a risk management plan together.
- Notes section: It’s helpful to include a comments section next to each requirement, especially what policy and procedure the item is associated with and how you’ll implement the task.
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.
The following graphs are an analysis of responses collected from 191 individuals who are responsible for HIPAA compliance (82 professionals in 2018 and 109 in 2017) about their HIPAA risk management plan.
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:
- Internal and external vulnerability scans: Automated testing for weaknesses inside and outside your network
- Penetration tests: Live, hands-on testing of your system’s weaknesses and vulnerabilities
- Nmap: A simple network scan that identifies open ports and services on your network
- Gap analysis: Consultation on where your gaps in security and compliance exist and what steps need to occur next
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.