The HIPAA Security Rule requires covered entities (health plans, healthcare clearinghouses, and healthcare providers who electronically transmit any health information in connection with a HIPAA related transaction) and business associates to implement security safeguards. These security safeguards must protect the confidentiality, integrity, and availability of electronic protected health information (ePHI). ePHI is any protected health information that is created, stored, transmitted, or received in any electronic format. Performing a security risk analysis is the first step in identifying and implementing these safeguards. A security risk analysis consists of conducting an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI. The first step of the analysis consists of collecting data. This article focuses on the second step of the security risk analysis, which consists of identifying and documenting potential threats and vulnerabilities.
What are Potential Threats and Vulnerabilities?
Once a covered entity has completed Step 1 of the security risk analysis (once it has gathered and documented relevant data on ePHI), the next step is to identify potential threats and vulnerabilities to the confidentiality, availability and integrity of ePHI.
It is useful to have an understanding of the following terms before undertaking Step 2 of the security risk analysis:
- Threat
- Vulnerability
A threat is a circumstance or event that has or indicates the potential to exploit vulnerabilities and to adversely impact (create adverse consequences for) organizational operations, organizational assets (including information and information systems), individuals, other organizations, or society.
A vulnerability is a characteristic of a location, security design, security procedure, or internal controls, or the implementation of any of these, that permit a threat or hazard to occur.
A good synonym for the word “vulnerability is “weakness.”
What is the Relationship Between Threats, Vulnerabilities, and Risk?
The potential for a threat to trigger or exploit a specific vulnerability creates risk. Risk is defined as:
- The potential,
- For an unwanted or adverse outcome,
- Resulting from an incident, event, or occurrence.
The potential for an unwanted or adverse outcome is determined by:
- The likelihood
- That a particular threat will exploit a particular vulnerability
- With the associated consequences.
How Do I Identify Threats?
The Security Rule defines the scope of what threats must be identified. Under the Security Rule, threats must be those that are reasonably anticipated.
The identification process can be completed by making a list of threats by category (i.e., natural threats, human threats, environmental threats).
As part of the security risk analysis, covered entities should identify threats that are unique to the circumstances of their environment.
This can be done by focusing on specific characteristics of the entity in relation to each of the threat categories.
For example, the geographic location of the entity will determine the natural threats that may create a risk.
A hurricane is theoretically a natural threat to any location. A covered entity in, say, Michigan, though, probably would not consider it a reasonably anticipated threat due to that CE’s location. Michigan borders the Great Lakes; the Great Lakes do not provide the appropriate conditions – notably, warmth – needed for hurricane formation. In contrast, a covered entity in Kansas should consider the likelihood of a tornado as a reasonably anticipated threat; tornadoes occur in Kansas rather frequently, because Kansas’ atmospheric and geographic conditions – a combination of a warm, moist air, and a wide, high range, and long stretch of mountains to the west that extends for thousands of kilometers – are ideal for tornado formation.
After the complete list is compiled, the covered entity, as part of Step 2 of the security risk analysis, should reduce the list to only those reasonably anticipated threats; i.e., Michigan should strike the hurricane off its list, while Kansas should keep tornadoes on the list.
For most covered entities, human threats – threats posed by ex-employees, hackers, commercial rivals, terrorists, criminals, general public, vendors, customers and visitors – will be of greatest concern. This is because human threats have the potential to be triggered or exploited more frequently than natural or environmental (e.g., power failures, pollution, chemicals, and liquid leakage) threats.
Potential human sources that could target a covered entity and trigger or exploit vulnerabilities are employees (the most common source). Anyone that has the access, knowledge and/or motivation to cause an adverse impact on the covered entity can act as a threat. Therefore, covered entities, as part of step 2 of the security risk analysis, should analyze several information sources to help identify potential human threats to their systems. Information sources to be analyzed under step 2 of the security risk analysis should include:
- Any history of system break-ins
- Security violation reports
- Ongoing input from systems administrators, help desk personnel, and the user community.
Once reasonably anticipated threats have been identified, they should be documented.
How Do I Identify Vulnerabilities?
While identifying potential threats, covered entities must also identify and document vulnerabilities which, if triggered or exploited by a threat, would create a risk to ePHI.
The process of identifying vulnerabilities is similar to the process used for identifying threats. The entity should create a list of vulnerabilities, both technical and non-technical, that are associated with existing information systems and operations that involve ePHI.
There are many sources of information to review when identifying and documenting both technical and non-technical vulnerabilities.
Sources of information to identify non-technical vulnerabilities may include:
- Previous risk analysis documentation
- Audit reports
- Security review reports.
Sources of information to identify technical vulnerabilities may include:
- Internet sites that provide information on technical vulnerabilities
- Business associates. Small covered entities are likely to rely on their business associates for identification of system vulnerabilities, especially if their applications and information systems are maintained by outside vendors or contractors.
Another way to identify technical vulnerabilities is through information systems security testing. The purpose of security testing is to assess the effectiveness of the security safeguards implemented to protect data, such as ePHI.
There are many approaches to security testing. One common approach consists of developing a security testing and evaluation plan, and using security testing tools to scan workstations or the entire network (workstations and servers) for known technical vulnerabilities. The output of the security testing can be a report that identifies your technical vulnerabilities.
Once any vulnerabilities – technical or non-technical – have been identified, they should then be documented as part of the security risk analysis.
Compliancy Group Simplifies HIPAA Compliance
Covered entities and business associates can address their security risk analysis by working with Compliancy Group to address federal HIPAA security standards. Completing a security risk analysis is required to become HIPAA compliant.
Our ongoing support and web-based compliance app, The Guard™, gives healthcare organizations the tools to address HIPAA Security Rule standards so they can get back to confidently running their business.
Find out how Compliancy Group has helped thousands of organizations like yours Achieve, Illustrate, and Maintain™ their HIPAA compliance!
