Conducting a HIPAA Security Rule security risk analysis (SRA), also called a security risk assessment, involves a series of steps. This article provides an overview of the SRA process, and then describes the SRA steps. These steps are covered below:
Overview
The HIPAA Security Rule requires that covered entities and business associates implement security safeguards to 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. Once you have conducted the risk analysis, you are ready to conduct the process of risk remediation. Risk remediation involves implementing a series of administrative, physical, and technical measures, to correct deficiencies you discovered during the risk analysis.
We will now discuss each of the six steps of the risk analysis, in turn.
Security Risk Analysis Element 1: Collecting Data
This step consists of the gathering of relevant data on and about ePHI. To gather data, an organization should conduct an ePHI inventory. The inventory process involves conducting an ePHI inventory. As part of the inventorying, covered entities and business associates must identify where their ePHI is stored, received, maintained, or transmitted.
ePHI can be stored in a variety of places, received through several kinds of electronic transmission, maintained in several formats, and transmitted through more than one transmission method. To perform a complete inventory, therefore, relevant data should be gathered through a variety of sources and means. These include:
Reviewing past and/or existing projects involving ePHI. Such review allows you to determine where ePHI is stored, how you come into possession of it, and how it is transmitted. Reviewing project notes and project documentation will shed light on how ePHI enters, stays in, is maintained, and is transmitted through your organization.
Performing interviews. Interviewing staff members as to what ePHI they access, receive, maintain, store, or transmit, yields a more thorough inventory than reviewing past or existing projects alone. While the Security Rule does not dictate how interviews are to be conducted, there are several effective known methods.
Sending out information questionnaires to staff. The questionnaires should be written as clearly as possible so employees will know what information is being sought of them. Staff should be given adequate time to respond. Once responses are received and reviewed, follow-up interviews can be conducted in person, to fill in any gaps or incomplete responses.
Contacting your hosting provider. If you are hosting health information at a HIPAA-compliant data center, you will need to contact your hosting provider to document where and how your data is stored. Reminder: If your practice has ePHI, anyone that hosts, stores, or maintains hosts your ePHI, must also be HIPAA compliant.
Step 2 - Identifying and Documenting Potential Threats and Vulnerabilities
Once a covered entity or business associate 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. 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.
Vulnerability. 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 to occur. A good synonym for the word “vulnerability is “weakness.”
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 specific 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 should be those that are reasonably anticipated.
An organization may begin the identifying process by making a list of threats by category. Categories of threats include natural threats, human threats, and environmental threats). Let’s define each of these in turn:
Natural threats may include floods, earthquakes, tornadoes, and landslides.
Human (or manmade) threats are enabled or caused by humans and may include intentional (e.g., network and computer-based attacks, malicious software upload, and unauthorized access to EPHI) or unintentional (e.g., inadvertent data entry or deletion and inaccurate data entry) actions.
Environmental threats may include power failures, pollution, chemicals, and liquid leakage.
Entities should identify natural, human, and environmental threats that are unique to the circumstances of their environment. To do this, an entity should focus on its specific characteristics in relation to each threat category.
Consider natural threats as an example. Hurricanes, in theory, pose a natural threat to any location. An entity, say, Michigan, though, probably would not consider a hurricane to be a reasonably anticipated threat, due to its location. Why? 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 of Kansas’ atmospheric and geographic conditions. These conditions include a combination of warm, moist air, and a long stretch of mountains to the west that extends for thousands of miles; such conditions are ideal for tornado formation.
For most covered entities and business associates, human threats – threats posed by employees, ex-employees, hackers, commercial rivals, terrorists, criminals, the 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.
Of these threat sources, employees in particular target a covered entity or business associate and exploit vulnerabilities. Employees have the access, knowledge, and motivation to take action resulting in an adverse impact. As such, covered entities and business associates, 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
After you identify reasonably anticipated natural, human, and environmental threats, be sure to document these threats.
How Do I Identify Vulnerabilities?
While identifying potential threats, covered entities must also identify and document vulnerabilities that, 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. Covered entities and business associates 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 the 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 information systems 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.
Step 3 - Assessing Current Security Measures
Step 3 consists of the assessment of a covered entity’s current security measures. Assessing current security measures – is to determine whether the assessed security measures are actually effective.
How Do I Assess Current Security Measures?
If existing measures to minimize or eliminate risks to ePHI are effective, vulnerabilities are not likely to be triggered or exploited by a threat.
If, however, those measures are ineffective in one or more ways, vulnerabilities are more likely to be triggered by a threat - the confidentiality, availability, and integrity of ePHI is at risk of being compromised. Effective security measures are required.
Effective security measures can be both technical and non-technical.
Technical measures are part of information systems hardware and software. Examples of technical measures include:
Access controls
Identification and authentication measures
Encryption methods
Automatic logoff
Audit controls
Indeed, these measures are critical components of the Security Rule’s technical safeguards.
Non-technical measures include management and operational controls, such as:
Policies
Procedures
Standards
Guidelines
Accountability and responsibility
Physical and environmental security measures
The output of step 3 should be thorough documentation of the security measures an organization uses to safeguard ePHI. The output should identify:
Whether security measures required by the Security Rule are already in place
Whether those security measures are configured and used properly
Step 4 - Determining the Likelihood of Threat Occurrence
The next step in the security risk analysis is to determine the likelihood of threat occurrence.
What Does “The Likelihood of Threat Occurrence” Mean?
“The likelihood of threat occurrence,” as that term relates to the HIPAA Security Rule, is the probability that a threat will trigger or exploit a specific vulnerability.
To determine the likelihood of threat occurrence, covered entities and business associates should consider each potential threat and vulnerability combination (as a reminder, Identification and Documentation of Potential Threats and Vulnerabilities is step 2 of the security risk analysis) and rate them by likelihood (or probability) that the combination would occur.
How Do I Classify the Likelihood of Occurrence?
Ratings such as high, medium, and low, or numeric representations of probability (i.e., a scale of 1 to 10, with one being “very unlikely” and 10 being “extremely likely”) may be used to express the likelihood of threat occurrence. The ratings used will depend on the covered entity’s or business associate’s approach.
If a covered entity uses the “high, medium, and low” rating system, it could define each category as follows:
High likelihood or probability: Here, a high probability exists that a threat will trigger or exploit one or more vulnerabilities. This might be due to the existence of multiple organizational deficiencies, such as the absence, inadequacy, or improper configuration of security controls, or due to geographic location (such as, within a flood zone, or in a region where atmospheric conditions encourage hurricane formation).
Medium likelihood: Here, a moderate probability exists that a threat will trigger or exploit one or more vulnerabilities. The probability exists due to, for example, the existence of a single organizational deficiency, such as the lack of security measures, or to the fact that a few (as opposed to numerous) organizational deficiencies exist, but have yet to be remedied.
Low likelihood: Here, a low probability exists that a threat will trigger or exploit a single vulnerability. The low probability can be attributed to, for example, the existence of one, single organizational deficiency or inadequate security measure, such as improper configuration of security controls.
The output of this step number 4 should be documentation of all threat and vulnerability combinations with associated likelihood ratings that may impact the confidentiality, availability, and integrity of ePHI of a covered entity or business associate. The documentation should be included as part of the finished security risk analysis product.
Step 5 - Determining the Potential Impact of Threat Occurrence
Step 5 requires a combination of data produced in step 2, along with data produced in step 4.
What Does “The Potential Impact of Threat Occurrence” Mean?
Step 2 of the security risk analysis consists of the identification and documentation of potential threats and vulnerabilities. Step 4 of the security risk analysis consists of determining the likelihood of threat occurrence. The output of Step 4 of the security risk analysis is documentation of all threat and vulnerability combinations, with associated likelihood (i.e., possibility that the threat may occur) ratings that may impact the confidentiality, availability, and integrity of ePHI.
Step 5 of the security risk analysis requires that an entity address the potential impact of the threat to the entity’s operation. A threat, if realized, can result in a variety of negative impacts. Threat impacts include (among other items):
Unauthorized access to or disclosure of ePHI
Permanent loss or corruption of ePHI
Temporary loss or unavailability of ePHI
Loss of financial cash flow
Loss of physical assets
Loss of public confidence in an organization
Loss of an organization’s credibility
All of these adverse outcomes have the ability, or potential, to affect the confidentiality, availability, and integrity of ePHI that is created, received, maintained, or transmitted by covered entities and business associates.
Some adverse outcomes may have a greater impact on the organization than others. Factors to consider in determining the magnitude of an impact may include:
How many people could be affected by the threat occurrence?
What extent of private data could be potentially exposed – just health information, or both health information and billing information?
The impact of potential outcomes should be measured to assist the covered entity or business associate in prioritizing risk mitigation activities. Broadly speaking, risk mitigation is a strategy an entity may use to prepare for and lessen (or mitigate) the effects of threats faced by an entity.
How Are the Impacts of Potential Threats Measured?
A covered entity or business associate may measure the impact of potential threats (threat occurrence impact) using a variety of methods.
The two most common methods are qualitative and quantitative. Both of these methods allow covered entities and business associates to measure risk.
Under the qualitative method, the magnitude of the potential impact resulting from a threat is rated on a scale using descriptive terms such as “high,” “medium,” and “low.” Potential impacts can be grouped into these three categories.
The qualitative method is the most common measure used to measure the impact of a threat. This method allows the covered entity or business associate to measure all potential impacts, whether tangible or intangible. The method is particularly well-suited, though, for measuring intangible impacts.
An intangible loss is more “concept-based” than something that can be measured by a specific dollar amount. As such, measuring an impact that is intangible or abstract, such as a loss of public confidence or loss of credibility, may more effectively be made using “high,” “medium,” and “low” labels, than by using a dollar amount. This is particularly so because in the case of concept-based, intangible impacts, specific dollar amounts are either impossible to ascertain, or can only be ascertained by effectively using a “best guess.”
In contrast, the quantitative method measures the tangible potential impact of a threat triggering or exploiting a specific vulnerability, by using a numeric value associated with resource cost.
A numeric value might include, for example, a number associated with a resource cost – such as the specific amount it costs to make repairs to information systems, or the specific amount it costs to replace an asset that has been lost or stolen. The quantitative method provides valuable information to later be used in risk management efforts.
A covered entity or business associate may use either method or a combination of the two methods to measure impact on the organization. Since there is no single correct method for measuring the impact during the risk analysis, a covered entity or business associate should consider the advantages and disadvantages of the two approaches, qualitative and quantitative.
The final output of this step should be documentation of all potential impacts, and ratings associated with the occurrence of threats triggering or exploiting vulnerabilities that affect the confidentiality, availability, and integrity of ePHI.
Step 6 - Determining the Level of Risk to ePHI
The final step in the security risk analysis is to determine the level of risk to ePHI.
What Does “The Level of Risk” Mean?
The term “risk,” as used in the phrase “security risk analysis,” can be defined as a function of two things:
The likelihood of a given threat triggering or exploiting a specific vulnerability (this value is determined in Step 4 of the security risk analysis); and
The resulting impact (this value is determined in step 5 of the security risk analysis).
Generally, the greater the likelihood of a given threat occurring, AND the greater the impact of the threat occurring is, the higher the level of risk to an organization. The higher the degree of a risk is, the more reasonably anticipated that risk can be said to be.
The phrase “reasonably anticipated,” in the context of a security risk analysis, should ring a bell. Recall that the Security Rule requires entities to evaluate risks and vulnerabilities in their environments, and to implement reasonable and appropriate security measures to protect against reasonably anticipated threats to the security or integrity of ePHI. Risk analysis is the first step in that process.
How is the Level of Risk Determined?
The level of risk is determined by analyzing the values assigned to the likelihood of threat occurrence, and the resulting impact of threat occurrence. The level of risk may be determined by assigning a risk level that is based on the average of the assigned likelihood and impact levels.
A risk level matrix can be used to assist in determining and ranking risk levels. The matrix is created using the values for likelihood of threat occurrence and resulting impact of threat occurrence. The matrix may be populated using a “high,” “medium,” and “low” rating system. For example, a threat likelihood value of “high” combined with an impact value of “low” may equal a risk level of “low.” Or a threat likelihood value of “medium” combined with an impact value of “medium” may equal a risk level of “medium.”
Once the risk level is determined, an organization can label each risk level with a general action description, to guide the decision-making of senior management. The action description can identify the general timeline and type of response (e.g., steps to be taken, and what kinds and volume of resources must be used during the process) needed to reasonably and appropriately reduce the risk to acceptable levels.
For example, a risk level of “high” could have an action description requiring immediate implementation of high-resource-consuming corrective measures to reduce the risk to a reasonable and appropriate level. On the other hand, a risk level of “low” could have an action description requiring that implementation be complete within several weeks, with minimal resource expenditure needed for corrective measures.
Assigning action descriptions provides covered entities and business associates with additional information to prioritize risk management efforts. A guiding principle of risk management is that, generally, the highest-level risks should be prioritized first.
Each risk level should contain an associated (and documented) list of mitigating corrective actions to be performed.
Entities should document the output of each step of the risk level determination process.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article