Risk Analysis: Fundamental to HIPAA security compliance

This article is reprinted with premission from Compliance Today: September 2013

• The Omnibus Final Rule does not change the HIPAA Security Rule's requirements for risk analysis and risk management.
• The requirement for risk analysis is explicitly stated in the Security Rule.
• Risk analysis provides the foundation upon which a risk management program is built.
• Although there is no "template" for risk analysis, resources such as NIST publications present industry standards for best practices.
• Risk analysis by independent experts can help an organization quickly analyze and benchmark security programs against peer organizations and industry best practices.

With the publication of the HIPAA Final Omnibus Rule, healthcare providers and other covered entities are once again reassessing their privacy and security programs with an eye toward compliance. In light of new questions and requirements, we talked to Terrill Clements, Senior Equal Opportunity Specialist at the Department of Health and Human Services (HHS) Office for Civil Rights (OCR), to find out about new developments. His answer was reassuring—the key to compliance still lies in the fundamentals of good privacy practices: ongoing risk analysis, risk management, and monitoring.

DP: Let's start with the question on everyone's mind: Does the Omnibus Rule change any of the requirements of the Security Rule?

TC: The Omnibus Rule doesn't do away with any of the requirements of the Security Rule. In fact, it reiterates the importance ofpatient privacy and data security, and it officially modifies the HIPAA Privacy, Security, and Enforcement rules to include requirements specified by the HITECH Act. It extends these rules to include business associates, and it provides for a tiered increase in penalties for compliance violations and specifies mandatory audits by HHS. Leon Rodriguez, the Director of OCR has said that it strengthens the ability of OCR "to vigorously enforce the HIPAA privacy and security protections." However, the HIPAA/HITECH Omnibus Final Rule contains no changes to the Security Rule's standards and specifications for risk analysis and risk management. The fundamentals are the same, and a compliance program still begins with and rests on thorough and ongoing risk analysis. (The Omnibus Final Rule became effective on March 26, 2013, and the compliance enforcement date is September 23, 2013.)

DP: Where in the Security Rule does it specifically require that covered entities complete a risk analysis?

TC: In section 45 C.F.R. § 164.308(a)(1)(ii)(A), the Rule states that as the first step of its security management process, a covered entity must "conduct 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].¹

DP: What is the difference between risk analysis and risk management in the Security Rule?

TC: Risk analysis is the evaluation of the risks and vulnerabilities that could negatively impact the confidentiality, integrity, and availability of the electronic protected health information (e-PHI) held by a covered entity, and the likelihood of occurrence.² Risk management is the actual implementation of security measures sufficient to reduce the risks and vulnerabilities to a reasonable and appropriate level.³ These are obviously closely related concepts, and both are required by the Security Rule. You might say that risk analysis is the process of identifying and prioritizing potential problems, and risk management is the process of planning and taking systematic steps to reduce their likelihood of occurrence and severity.

DP: Is there a risk analysis template, or a resource that provides a good example of what should be included in a risk analysis document?

TC: Because the Security Rule is meant to be scalable according to the size of an entity, it does not specify an actual "template" for risk analysis. There are numerous methods of performing a risk analysis and there is no single method or best practice that guarantees compliance with the Security Rule.

NIST is a federal agency that sets computer security standards for the federal government and publishes reports on topics related to IT security. Note that these reports are informational resources, not guidance that sets a standard upon which compliance is measured. Some examples of steps that might be applied in a risk analysis process are outlined in NIST Special Publication 800-30: Risk Management Guide for Information Technology Systems.⁴ However, there are several elements a risk analysis must include, regardless of the method or format employed:

• Scope of the analysis— A covered entity's risk analysis must take into account all of its e-PHI, regardless of the particular electronic medium in which it is created, received, maintained, or transmitted, or its source or location.
• Data collection— Covered entities must identify where the e-PHI is stored, received, maintained, or transmitted. An organization could gather relevant data by reviewing past and/or existing projects, performing interviews, reviewing documentation, or using other data gathering techniques. The e-PHI data gathered using these methods must be documented.
• Identification and documentation of potential threats and vulnerabilities — Covered entities must identify and document reasonably anticipated threats to e-PHI, including different threats that are unique to the circumstances of their environment. Covered entities must also identify and document vulnerabilities that, if triggered or exploited by a threat, would create a risk of inappropriate access to or disclosure of e-PHI.
• Assessment of current security measures — Covered entities should assess and document the security measures currently being used to safeguard e-PHI, whether security measures required by the Security Rule are already in place, and if current security measures are configured and used properly.
• Threat probability assessment — The Security Rule requires covered entities to take into account the probability of potential risks to e-PHI. The results of this assessment will determine which threats may be "reasonably anticipated"—the threats that the Security Rule requires covered entities to protect against. The output of this step will be documentation of all threat and vulnerability combinations with associated likelihood estimates that may impact the confidentiality, availability, and integrity of the organization's e-PHI.
• Threat impact assessment— The Security Rule also requires consideration of the "criticality," or impact, of potential risks to confidentiality, integrity, and availability of e-PHI. Covered entities must assess the magnitude of the potential impact resulting from a threat triggering or exploiting each specific vulnerability. A covered entity may use either a qualitative or quantitative method, or a combination of the two methods, to measure the potential impact, and the output of this process should be documented.
• Risk impact assessment — Covered entities should assign risk levels for all threat and vulnerability combinations identified during the risk analysis. The level of risk could be determined, for example, by analyzing the values assigned to the likelihood and resulting impact of threat occurrence, or by assigning a risk level based on the average of the assigned likelihood and impact levels. The resulting levels should be documented and correlated with a list of corrective actions to mitigate each risk level.
• Documentation — The Security Rule requires the risk analysis to be documented but does not require a specific format.⁵ The risk analysis documentation is a direct input to the risk management process.

OCR's Guidance on Risk Analysis Requirements Under the HIPAA Security Rule and the other materials available on OCR's web pages, provide much more detail on the steps in the risk analysis process.⁶

DP: How often does a covered entity haveto review and update its risk analysis?

TC: The risk analysis process should be ongoing. In order for an entity to update and document its security measures "as needed," which the rule requires, it should conduct continuous risk analysis to identify when updates are needed.⁷ However, the Security Rule does not mandate a specific interval for updates. This process will vary from one covered entity to another, depending on individual circumstances. (Again, the time period is determined by what is "reasonable and appropriate" for that organization.) For example, many entities have formal policy review cycles that include periodic risk analysis updates. Annual or biennial reassessments appear to be a common general practice for such routine reassessments. But where there are significant changes in electronic record systems and processes, significant security incidents, or significant unforeseen security issues identified through system access tracking, it would be prudent for a covered entity to update its risk analysis and risk management programs promptly, rather than wait for a scheduled periodic reassessment that may be many months away.

DP: What are some examples of threats that covered entities should address when conducting their risk analysis?

TC: Several types of threats may occur within an information system or operating environment. Threats are typically grouped into general categories such as natural, human, and environmental. According to NIST Special Publication 800-30, Risk Management Guide for Information Technology Systems, some examples of common threats in each of these categories include:

• Natural threats such as 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 e-PHI) or unintentional (e.g., inadvertent data entry or deletion and inaccurate data entry) actions.
• Environmental threats such as power failures, pollution, chemicals, and liquid leakage.

DP: Does OCR use NIST risk-analysis standards as a best practices baseline for an assessment of whether a covered entity has met Security Rule requirements for risk analysis?

TC: The NIST papers are important informational resources for OCR as well as covered entities, but they are not legally binding guidance for covered entities. Because the requirements of the Security Rule are flexible and scalable, no guidance material or other such resources can provide rigid prescriptions for compliance in every situation. NIST guidelines represent the industry standard for good business practices with respect to standards for securing e-PHI, however, so covered entities will often find their content valuable when developing and performing compliance activities.

DP: Where can I find the OCR, CMS, and NIST guidance materials for risk analysis online?

TC: You can find them at www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule/securityruleguidance.html. You'll find these important resources (among others) there:

• OCR's Guidance on Risk Analysis Requirements Under the HIPAA Security Rule.
• CMS HIPAA Security Series 1: Security 101 for Covered Entities
• CMS HIPAA Security Series 6: Basics of Risk Analysis and Risk Management
• CMS HIPAA Security Series 7: Security Standards: Implementation for the Small Provider

The HIPAA Security Information Series consists of educational papers produced by the HHS

Centers for Medicare and Medicaid Services (CMS) to give covered entities insight into the Security Rule and assistance with implementation of the security standards. These are the most pertinent ones for risk analysis.

NIST special publications are provided by OCR as an informational resource but are not legally binding guidance for covered entities. NIST publications can be found at: http://1.usa.gov/1cVMuFC. These three are a great place to start:

• NIST Special Publication 800-30: Risk Management Guide for Information Technology Systems
• NIST Special Publication 800-66: An Introductory Resource Guide for Implementing the HIPAA Security Rule
• NIST Special Publication 800-115: Guide to Technical Aspects of Performing Information Security Assessments

Risk analysis and customized compliance: With flexibility comes responsibility

Information security is never "one size fits all," and PHI security is no exception. In recognition of varying needs, HIPAA and HITECH regulations don't prescribe the details of PHI privacy programs, giving organizations the freedom to create security programs that meet their needs. But with the flexibility to define your own security program, comes the responsibility to ensure and be able to demonstrate and document that risks to the exposure of your PHI are discovered and adequately addressed.

Terrill Clements emphasizes that a security risk analysis is not optional: it is required in order to achieve compliance. These eight questions and answers highlight the importance of ongoing risk analysis, risk management, and monitoring. With the enforcement date for the Omnibus Final Rule fast approaching, organizations that have not yet done a formal HIPAA security risk analysis need to move quickly to do so, also implementing risk management programs based on their findings. The risk analysis provides you with a blueprint for focusing your risk management program.

^1. The full text of the Security Rule can be found on OCR's website at: http://1.usa.gov/13u8Bjg

^2. See 45 C.F.R. § 164.308(a)(1)(ii)(A).

^3. See 45 C.F.R. § 164.308(a)(1)(ii)(B)

^4. NIST Special Publication 800-30: Risk Management Guide for Information Technology Systems and NIST Special Publication 800-66: An Introductory Resource Guide for Implementing the HIPAA Security Rule are available at http://1.usa.gov/1cVMuFC

^5. See 45 C.F.R. § 164.316(b)(1)

^6. http://www.hhs.gov/ocr/office/index.html

^7. See 45 C.F.R. §§ 164.306(e) and 164.316(b)(2)(iii).