Download Understanding HIPAA Security Rule: Risk Analysis and Risk Management and more Exercises Risk Analysis in PDF only on Docsity!
HIPAA
Security
S E R I E S
Compliance Deadlines No later than April 20, 2005 for all covered entities except small health plans, which have until no later than April 20, 2006.
NOTE: To download the first paper in this series, “Security 101 for Covered Entities,” visit the CMS website at: www.cms.hhs.gov/SecurityStan dard/ under the “Regulation” page.
What is the Security Series? The security series of papers will provide guidance from the Centers for Medicare & Medicaid Services (CMS) on the rule titled “Security Standards for the Protection of Electronic Protected Health Information,” found at 45 CFR Part 160 and Part 164, Subparts A and C, commonly known as the Security Rule. The Security Rule was adopted to implement provisions of the Health Insurance Portability and Accountability Act of 1996 (HIPAA). The series will contain seven papers, each focused on a specific topic related to the Security Rule. The papers, which cover the topics listed to the left, are designed to give HIPAA covered entities insight into the Security Rule and assistance with implementation of the security standards. This series explains specific requirements, the thought process behind those requirements, and possible ways to address the provisions.
CMS recommends that covered entities read the first paper in this series, “Security 101 for Covered Entities” before reading the other papers. The first paper clarifies important Security Rule concepts that will help covered entities as they plan for implementation. This sixth paper in the series is devoted to the required risk analysis and risk management implementation specifications and assumes the reader has a basic understanding of the Security Rule.
Background All electronic protected health information (EPHI) created, received, maintained or transmitted by a covered entity is subject to the Security Rule. Covered entities are required to implement reasonable and appropriate security measures to protect against reasonably anticipated threats or hazards to the security or integrity of EPHI. The Security Rule requires covered entities to evaluate risks and vulnerabilities in their environments and to implement policies and procedures to address those risks and vulnerabilities.
Security^6 Basics of Risk Analysis and Risk Management
Topics
5. Security Standards
- Organizational, Policies and Procedures and Documentation Requirements
4. Security Standards
- Technical Safeguards
2. Security Standards
- Administrative Safeguards
3. Security Standards
- Physical Safeguards
1. Security 101 for Covered Entities
7. Implementation for the Small Provider
6. Basics of Risk Analysis and Risk Management
The objectives of this paper are to:
Review the Security Rule required implementation specifications for Risk Analysis and Risk Management.
Review the basic concepts involved in security risk analysis and risk management.
Discuss the general steps involved in risk analysis and risk management.
Security Rule Requirements for Risk Analysis and Risk Management The Security Management Process standard, at § 164.308(a)(1)(i)) in the Administrative Safeguards section of the Security Rule, requires covered entities to “[i]mplement policies and procedures to prevent, detect, contain, and correct security violations.” The Security Management Process standard has four required implementation specifications. Two of the implementation specifications are Risk Analysis and Risk Management.
The required implementation specification at § 164.308(a)(1)(ii)(A), for Risk Analysis, requires a covered entity to, “[c]onduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity.”
The required implementation specification at § 164.308(a)(1)(ii)(B), for Risk Management, requires a covered entity to “[i]mplement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with § 164.306(a) [(the General Requirements of the Security Rule)].”
Both risk analysis and risk management are standard information security processes and are critical to a covered entity’s Security Rule compliance efforts. As stated in the responses to public comment in the preamble to the Security Rule, risk analysis and risk management are important to covered entities since these processes will “form the foundation upon which an entity’s
NOTE: Risk analysis and risk management serve as tools to develop and maintain a covered entity’s strategy to protect the confidentiality, integrity, and availability of EPHI.
STANDARD
164.310(a)(1)
ADMINISTRATIVE SAFEGUARDS
- Security Management Process
- Assigned Security Responsibility
- Workforce Security
- Information Access Management
- Security Awareness and Training
- Security Incident Procedures
- Contingency Plan
- Evaluation
- Business Associate Contracts and Other Arrangements
HIPAA SECURITY STANDARDS
PHYSICAL SAFEGUARDS
- Facility Access Controls
- Workstation Use
- Workstation Security
- Device and Media Controls TECHNICAL SAFEGUARDS
- Access Control
- Audit Controls
- Integrity
- Person or Entity Authentication
- Transmission Security
ORGANIZATIONAL REQUIREMENTS
- Business Associate Contracts and Other Arrangements
- Requirements for Group Health Plans
Security Standards: General Rules
POLICIES and PROCEDURES and DOCUMENTATION REQUIREMENTS
(accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system’s security policy.”
Vulnerabilities, whether accidentally triggered or intentionally exploited, could potentially result in a security incident, such as an inappropriate use or disclosure of EPHI. Vulnerabilities may be grouped into two general categories, technical and non- technical. Non-technical 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; or incorrectly implemented and/or configured information systems.
THREAT
An adapted definition of threat, from NIST SP 800-30, is “ [t]he potential for a person or thing to exercise (accidentally trigger or intentionally exploit) a specific vulnerability.”
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 common threats in each of these general categories include:
Natural threats may include floods, earthquakes, tornadoes, and landslides.
Human 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.
RISK
The definition of risk is clearer once threat and vulnerability are defined. An adapted definition of risk, from NIST SP 800-30, is:
“The net mission impact considering (1) the probability that a particular [threat] will exercise (accidentally trigger or intentionally exploit) a particular [vulnerability] and (2) the resulting impact if this should occur. …[R]isks arise from legal liability or mission loss due to—
NOTE: A Vulnerability triggered or exploited by a Threat equals a Risk.
_1. Unauthorized (malicious or accidental) disclosure, modification, or destruction of information
- Unintentional errors and omissions
- IT disruptions due to natural or man-made disasters
- Failure to exercise due care and diligence in the implementation and operation of the IT system.”_
Risk is a function of 1) the likelihood of a given threat triggering or exploiting a particular vulnerability, and 2) the resulting impact on the organization. This means that 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.
Example Risk Analysis and Risk Management Steps There are numerous methods of performing risk analysis and risk management. There is no single method or “best practice” that guarantees compliance with the Security Rule. However, most risk analysis and risk management processes have common steps. The following steps are provided as examples of steps covered entities could apply to their environment. The steps are adapted from the approach outlined in NIST SP 800-30.
EXAMPLE RISK ANALYSIS STEPS:
1. Identify the scope of the analysis.
2. Gather data.
3. Identify and document potential threats
and vulnerabilities.
4. Assess current security measures.
5. Determine the likelihood of threat
occurrence.
6. Determine the potential impact of threat occurrence.
7. Determine the level of risk.
8. Identify security measures and finalize documentation.
EXAMPLE RISK MANAGEMENT STEPS:
1. Develop and implement a risk management plan.
2. Implement security measures.
3. Evaluate and maintain security measures.
NOTE: CMS is not recommending that all covered entities follow this approach, but rather is providing it as a frame of reference.
NOTE: A threat must have the capability to trigger or exploit a vulnerability to create risk.
should take into account all of its EPHI, regardless of the particular electronic medium in which it is created, received, maintained or transmitted or the source or location of its EPHI.
2. Gather Data Once the scope of the risk analysis is identified, the covered entity should gather relevant data on EPHI. For example, a covered entity must identify where the EPHI is stored, received, maintained or transmitted. A covered entity could gather relevant data by: reviewing past and/or existing projects; performing interviews; reviewing documentation; or using other data gathering techniques. The data on EPHI gathered using these methods must be documented. (See §§ 164.308(a)(1)(ii)(A) and 164.316(b)(1)(ii).)
Many covered entities inventoried and performed an analysis of the use and disclosure of all protected health information (PHI) (which includes EPHI) as part of HIPAA Privacy Rule compliance, even though it was not a direct requirement. This type of inventory and analysis is a valuable input for the risk analysis.
The level of effort and resource commitment needed to complete the data gathering step depends on the covered entity’s environment and amount of EPHI held. For example, a small provider that keeps its medical records on paper may be able to identify all EPHI within the organization by analyzing a single department which uses an information system to perform billing functions. In another covered entity with large amounts of EPHI, such as a health system, identification of all EPHI may require reviews of multiple physical locations, most (if not all) departments, multiple information systems, portable electronic media, and exchanges between business associates and vendors.
3. Identify and Document Potential Threats and
Vulnerabilities Once the covered entity 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 the EPHI. As discussed earlier, the potential for a threat to trigger or exploit a specific vulnerability creates risk. Therefore, identification of threats and vulnerabilities are central to determining the level of risk.
The identification of threats and vulnerabilities could be separated into two distinct steps but are so closely related in the risk analysis process that they should be identified at the same time. Independent identification may result in large lists of threats and vulnerabilities that, when analyzed (in subsequent steps to identify risk), do not provide valuable information.
NOTE: A covered entity should focus its list of threats to those that are reasonably anticipated.
IDENTIFY AND DOCUMENT THREATS
Covered entities must identify and document reasonably anticipated threats to EPHI. (See §§ 164.306(a)(2) and 164.316(b)(1)(ii).) To start, covered entities may compile a categorized list (such as natural, human, and environmental) of threats. Covered entities may identify different threats unique to the circumstances of their environment.
After the complete list is compiled, the covered entity should reduce the list to only those reasonably anticipated threats. 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 a threat, but a covered entity in Kansas probably would not consider it a reasonably anticipated threat due to its location. However, a covered entity in Kansas should consider the likelihood of a tornado a reasonably anticipated threat.
For most covered entities, human threats will be of greatest concern, because human threats have the potential to be triggered or exploited more frequently than natural or environmental threats. Potential human sources that could target a covered entity and trigger or exploit vulnerabilities are employees (the most common source), ex-employees, hackers, commercial rivals, terrorists, criminals, general public, vendors, customers and visitors. Anyone that has the access, knowledge and/or motivation to cause an adverse impact on the covered entity can act as a threat.
Covered entities should analyze several information sources to help identify potential human threats to their systems. Information sources such as any history of system break-ins, security violation reports, and ongoing input from systems administrators, help desk personnel and the user community should be reviewed.
IDENTIFY AND DOCUMENT 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. (See §§ 164.308(a)(1)(ii)(A) and 164.316(b)(1)(ii).) 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, associated with existing information systems and operations that involve EPHI.
Security measures implemented to reduce risk will vary among covered entities. For example, small covered entities tend to have more control within their environment. Small covered entities tend to have fewer variables (i.e. fewer workforce members and information systems) to consider when making decisions regarding how to safeguard EHPI. As a result, the appropriate security measures that reduce the likelihood of risk to the confidentiality, availability and integrity of EPHI in a small covered entity may differ from those that are appropriate in large covered entities.
The output of this step should be documentation of the security measures a covered entity uses to safeguard EPHI. The output should identify whether security measures required by the Security Rule are already in place. The documentation should also identify if current security measures are configured and used properly. (See §§ 164.306(b)(1), 164.308(a)(1)(ii)(A), and 164.316(b)(1)(ii).)
5. Determine the Likelihood of Threat Occurrence Once the first four steps in the risk analysis process are complete, the covered entity has the information needed to determine 1) the likelihood that a threat will trigger or exploit a specific vulnerability and 2) the resulting impact on the covered entity. The next two steps (steps 5 and 6) use information gathered from the previous steps to help the covered entity make likelihood and impact determinations. The purpose of these steps is to assist the covered entity in determining the level of risk and prioritizing risk mitigation efforts.
“Likelihood of occurrence” is the probability that a threat will trigger or exploit a specific vulnerability. Covered entities should consider each potential threat and vulnerability combination and rate them by likelihood (or probability) that the combination would occur. Ratings such as high, medium and low or numeric representations of probability may be used to express the likelihood of occurrence. The ratings used will depend on the covered entity’s approach. For example, a covered entity may choose to rate risks as high, medium and low, which could be defined as:
High Likelihood – 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).
Medium Likelihood – a moderate probability exists that a threat will trigger or exploit one or more vulnerabilities due to the existence of a single organizational deficiency, such as the lack of security measures.
NOTE: Covered entities should consider the advantages and disadvantages of both qualitative and quantitative methods for determining the potential impact.
Low Likelihood – a low probability exists that a threat will trigger or exploit a single vulnerability due to the existence of a single organizational deficiency, such as improper configuration of security controls.
The output of this step 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. (See §§ 164.306(a)(2), 164.308(a)(1)(ii)(A), and 164.316(b)(1)(ii).)
6. Determine the Potential Impact of Threat Occurrence If a threat triggers or exploits a specific vulnerability, there are many potential outcomes. For covered entities, the most common outcomes include, but are not limited to:
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.
All of these outcomes have the potential to affect the confidentiality, availability and integrity of EPHI created, received, maintained, or transmitted by covered entities. The impact of potential outcomes, such as those listed above, should be measured to assist the covered entity in prioritizing risk mitigation activities.
Measuring the impact of a threat occurring in a covered entity can be performed using different methods. The most common methods are qualitative and quantitative. Both of these methods allow a covered entity to measure risk.
QUALITATIVE METHOD
The qualitative method rates the magnitude of the potential impact resulting from a threat triggering or exploiting a specific vulnerability on a scale such as high, medium and low. The qualitative method is the most common measure used to measure the impact of risk. This method allows the covered entity to measure all potential impacts, whether tangible or intangible. For example, an intangible loss, such as a loss of public confidence or loss of credibility, can be measured using a high, medium or low scale.
NOTE: During the risk management process, recommended security measures will be evaluated, prioritized, modified, and implemented.
Next, each risk level is labeled with a general action description to guide senior management decision making. The action description identifies the general timeline and type of response 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 corrective measures to reduce the risk to a reasonable and appropriate level. Assigning action descriptions provides the covered entity additional information to prioritize risk management efforts.
One output of this step should be documented risk levels for all threat and vulnerability combinations identified during the risk analysis. Another output should be a list of corrective actions to be performed to mitigate each risk level. (See §§ 164.306(a)(2), 164.308(a)(1)(ii)(A), and 164.316(b)(1)(ii).)
8. Identify Security Measures and Finalize
Documentation Once risk is identified and assigned a risk level, the covered entity should begin to identify the actions required to manage the risk. The purpose of this step is to begin identifying security measures that can be used to reduce risk to a reasonable and appropriate level. When identifying security measures that can be used, it is important to consider factors such as: the effectiveness of the security measure; legislative or regulatory requirements that require certain security measures to be implemented; and requirements of the organization’s policies and procedures. Any potential security measures that can be used to reduce risks to EPHI should be included in documentation.
This step only includes identification of security measures. The evaluation, prioritization, modification, and implementation of security measures identified in this step is part of the risk management process, addressed in the next section “Example Risk Management Steps.”
The final step in the risk analysis process is documentation. The Security Rule requires the risk analysis to be documented but does not require a specific format. (See § 164.316(b)(1)(ii).) A risk analysis report could be created to document the risk analysis process, output of each step and initial identification of security measures. The risk analysis documentation is a direct input to the risk management process.
Example Risk Management Steps Once the covered entity has completed the risk analysis process, the next step is risk management. Risk management, required by the Security Rule, includes the implementation of security measures to reduce risk to reasonable and appropriate levels to, among other things, ensure the confidentiality, availability and integrity of EPHI, protect against any reasonably anticipated threats or hazards to the security or integrity of EPHI, and protect against any reasonably anticipated uses or disclosures of EPHI that are not permitted or required under the HIPAA Privacy Rule.
1. Develop and Implement a Risk Management Plan The first step in the risk management process should be to develop and implement a risk management plan. The purpose of a risk management plan is to provide structure for the covered entity’s evaluation, prioritization, and implementation of risk-reducing security measures.
For the risk management plan to be successful, key members of the covered entity’s workforce, including senior management and other key decision makers, must be involved. The outputs of the risk analysis process will provide these key workforce members with the information needed to make risk prioritization and mitigation decisions.
The risk prioritization and mitigation decisions will be determined by answering questions such as:
Should certain risks be addressed immediately or in the future? Which security measures should be implemented?
Many of the answers to these questions will be determined using data gathered during the risk analysis. The entity has already identified, through that process, what vulnerabilities exist, when and how a vulnerability can be exploited by a threat, and what the impact of the risk could be to the organization. This data will allow the covered entity to make informed decisions on how to reduce risks to reasonable and appropriate levels.
An important component of the risk management plan is the plan for implementation of the selected security measures. The implementation component of the plan should address:
Risks (threat and vulnerability combinations) being addressed; Security measures selected to reduce the risks; Implementation project priorities, such as: required resources; assigned responsibilities; start and completion dates; and maintenance requirements.
“Security measures implemented to comply with standards and implementation specifications adopted under § 164.105 [(the Organizational Requirements)] and this subpart [(the Security Rule)] must be reviewed and modified as needed to continue provision of reasonable and appropriate protection of [EPHI] as described at § 164.316.”
The Security Rule does not specify how frequently to perform risk analysis and risk management. The frequency of performance will vary among covered entities. Some covered entities may perform these processes annually or as needed (e.g., bi-annual or every 3 years) depending on circumstances of their environment.
A truly integrated risk analysis and management process is performed as new technologies and business operations are planned, thus reducing the effort required to address risks identified after implementation. The Evaluation standard (§ 164.308(a)(8)) requires covered entities to:
“ Perform a periodic technical and nontechnical evaluation, based initially upon the standards implemented under this rule and subsequently, in response to environmental or operational changes affecting the security of [EPHI], that establishes the extent to which an entity’s security polices and procedures meet the requirements of [the Security Rule].”
For example, if the covered entity is planning to incorporate new technology to make operations more efficient, such as using notebook computers or handheld devices that contain EPHI, the potential risk to these devices must be analyzed to ensure the EPHI is reasonably and appropriately protected. If it is determined that existing security measures are not sufficient to protect against the risks associated with the new technology, then the entity must determine if additional security measures are needed. Performing the risk analysis and risk management processes before implementing the new technology will allow the covered entity to reduce the associated risks to reasonable and appropriate levels.
In Summary Risk analysis and risk management are the foundation of a covered entity’s Security Rule compliance efforts. Risk analysis and risk management are on going processes that will provide the covered entity with a detailed understanding of the risks to EPHI and the security measures needed to effectively manage those risks. Performing these processes appropriately will ensure the confidentiality, availability and integrity of EPHI, protect against any reasonably anticipated threats or hazards to the security or integrity of EPHI, and protect against any reasonably anticipated uses or disclosures of EPHI that are not permitted or required under the HIPAA Privacy Rule.
Resources The previous papers in this series address specific requirements of the Security Rule. The final paper in this series will address implementation of Security Rule standards and implementation specifications in the small provider environment.
Covered entities should periodically check the CMS website at www.cms.hhs.gov under “Regulations and Guidance” for additional information and resources as they work through the security implementation process. There are many other sources of information available on the Internet. While CMS does not endorse guidance provided by other organizations, covered entities may also want to check with other local and national professional health care organizations, such as national provider and health plan associations for additional information.
Need more information?
Visit the CMS website often at www.cms.hhs.gov under “Regulations and Guidance” for the latest security papers, checklists, and announcements of upcoming events.
Visit the Office for Civil Rights website, http://www.hhs.gov/ocr/hipaa, for the latest guidance, FAQs and other information on the Privacy Rule.
PHYSICAL SAFEGUARDS
Standards Sections (^) (R)= Required, (A)=AddressableImplementation Specifications Contingency Operations (A) Facility Security Plan (A) Access Control and Validation Procedures
(A)
Facility Access Controls
§ 164.310(a)(1)
Maintenance Records (^) (A) Workstation Use § 164.310(b)
Workstation Security § 164.310(c)
Disposal (^) (R) Media Re-use (R) Accountability (A)
Device and Media Controls
§ 164.310(d)(1)
Data Backup and Storage (A)
TECHNICAL SAFEGUARDS
Standards Sections Implementation Specifications (R)= Required, (A)=Addressable Unique User Identification (R) Emergency Access Procedure
(R)
Automatic Logoff (A)
Access Control § 164.312(a)(1)
Encryption and Decryption (A) Audit Controls § 164.312(b)
Integrity § 164.312(c)(1) Mechanism to Authenticate Electronic Protected Health Information
(A)
Person or Entity Authentication
§ 164.312(d)
Transmission Integrity Controls (A) Security
§ 164.312(e)(1) Encryption (A) ORGANIZATIONAL REQUIREMENTS Standards Sections (^) (R)= Required, (A)=AddressableImplementation Specifications Business Associate Contracts
Business associate (R) contracts or other arrangements
§ 164.314(a)(1)
Other Arrangements (R) Requirements for Group Health Plans
§ 164.314(b)(1) Implementation Specifications
(R)
POLICIES AND PROCEDURES AND DOCUMENTATION REQUIREMENTS
Standards Sections Implementation Specifications (R)= Required, (A)=Addressable Policies and Procedures
§ 164.316(a)
Time Limit (^) (R) Availability (R)
Documentation § 164.316(b)(1)
Updates (R)
