A risk analysis for the security rule is

One of the first requirements under the Health Insurance Portability and Accountability Act of 1996 (HIPAA) Security Rule is that organizations have a risk analysis conducted. While most covered entities and business associates understand the requirement, there often are questions on how it should be conducted. This article will examine the specification and outline what must be included when conducting the risk assessment.

The Office for Civil Rights (OCR) is responsible for issuing guidance on the provisions in the HIPAA Security Rule (45 Code of Federal Regulations (CFR) Sections 164.302–318). It provides guidance to assist organizations in identifying and implementing the most effective and appropriate administrative, physical and technical safeguards to secure electronic protected health information (ePHI).

The guidance provided according to §164.308(a)(1)(ii)(A) is as follows:

RISK ANALYSIS (Required). 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 or business associate.

The risk analysis is required, as opposed to addressable. An addressable specification must still be in place; however, the organization has the opportunity to determine if it’s reasonable as written. Thus, it can implement an equivalent alternative measure (compensating control) to comply with the standard. Since the risk analysis is required, the organization must implement it as written without having a compensating control or measure in its place.

Organizations often struggle with exactly how they should conduct this risk analysis, asking questions like:

• Is this a review of the HIPAA Security Rules?
• Should this be a National Institute of Standards and Technology (NIST) common security framework assessment?
• Should it include a penetration test?

These are great questions, but the guidance doesn’t answer this specifically. In fact, the guidance was intentionally written in a way to avoid prescribing a specific methodology. As organizations differ in their sizes and complexities, they should consider the following factors, which are identified in §164.306(b)(2):

1. The size, complexity and capabilities of the covered entity
2. The covered entity’s or the business associate’s technical infrastructure, hardware and software security capabilities
3. The costs of security measures
4. The probability and criticality of potential risks to ePHI

While management has the flexibility to select an appropriate methodology, the OCR requires that the risk analysis must contain the following nine items:

1. Scope of the Analysis: The scope must include the risks to the confidentiality, availability and integrity of all ePHI within the organization. To do this, an entity must understand how it receives, creates, stores or transmits ePHI, considering both data in transit as well as data at rest. For example: What applications use ePHI? What systems have access to this data? What locations or areas have access to the ePHI? Is it being stored in portable devices such as USB drives or laptops?
2. Data Collection: Along with scope, an organization must identify where ePHI is received, created, stored and transmitted, including procedures on how ePHI is collected. This must be documented.
3. Identify and Document Potential Threats and Vulnerabilities: The risk analysis must show the organization can identify and document reasonable threats to its ePHI. While some of these are universal, there may be unique threats based on the business environment. What are the potential vulnerabilities that, if triggered, would risk exposure of ePHI to unapproved parties?
4. Assess Current Security Measures: Organizations should document security measures used to safeguard ePHI, i.e., controls, processes and procedures. The risk analysis would consider the existence of these security measures (design and implementation). A more robust approach would assess the effectiveness of these security measures.
5. Determine the Likelihood of Threat Occurrence: The risk analysis would need to address the probability of the risk or threat to ePHI. What are the chances this threat would occur in the course of operations?
6. Determine the Potential Effect of Threat Occurrence: Along with likelihood, the Security Rule also requires the impact or criticality of the potential risk to the ePHI be reviewed. This may be classified as High/Medium/Low, or may use another common scoring system.
7. Determine the Level of Risk: Using the potential likelihood and effect, organizations will need to include the risk level in their risk analysis. This should include the assigned risk levels and list of corrective actions to mitigate each risk.
8. Finalize Documentation: The Security Rule requires the risk analysis be documented, but it doesn’t specify a format. A risk report that addresses the areas above would meet this requirement.
9. Periodic Review and Updates to the Risk Assessment: Finally, the risk analysis should be ongoing. The frequency isn’t specified by the Security Rule. While annually is recommended, there may be business reasons why this may occur less (or more) frequently. For example, a major implementation or change in the infrastructure would trigger a reason for a review.

There are a number of ways to conduct a risk analysis. Some organizations look to conduct the same assessment annually, but they also may consider alternating different methodologies for a broader coverage of risks. For example, an organization may run HIPAA Security Rules, Privacy and Breach Notification for one assessment. It may follow with its next assessment as a review of its operations as compared to the NIST Cybersecurity Framework. It also could consider a network penetration test against the ePHI processing environment or a social engineering assessment to evaluate the effectiveness of the human factor—all part of a cybersecurity program to help provide better protection of ePHI.

Organizations should work with a trusted advisor who can help determine an effective risk analysis and develop a cybersecurity program. This allows for the most direct approach to address the real risks in the organization, rather than just meeting the compliance requirements. Contact Rex or your trusted BKD advisor if you have questions or want to discuss your risk analysis options.