This blog is based on part three of our 5-part webinar series, “HIPAA Audits Are On The Way—Are You Ready?” Access the replay and presentation materials here.
Although the HIPAA Security Rule has existed for nearly two decades, most healthcare-covered entities and business associates still struggle with conducting Office for Civil Rights (OCR) compliant risk analysis.
In fact, 90% of OCR enforcement actions regarding electronic personal health information (ePHI) were related to improper risk analysis, which included lacking required details, not being comprehensive enough, not following OCR guidance, and not providing adequate documentation or evidence.
According to the 2016-2017 HIPAA Audits Industry Report, only 14% of covered entities and only 17% of business associates in the OCR audit could substantially fulfill their regulatory responsibilities to conduct a proper risk analysis.
These findings highlight that even after all this time, most organizations still can’t correctly ascertain which safeguards are “reasonable and appropriate” for their operations.
The Safeguard Requirement
Under the Security Rule, OCR requires healthcare organizations and business associates to implement reasonable and appropriate administrative, technical, and physical safeguards—known as controls—to protect the confidentiality, integrity, and availability of all electronic protected health information (ePHI).
And, while much of the risk analysis requirement is centered around OCR requirements, it’s not the only place where healthcare organizations are expected to complete risk analysis. For example, cybersecurity practices under the Department of Health and Human Services (HHS) 405(d) Program also include risk analysis as a recommended practice.
Unlike HIPAA, which is less prescriptive about what is “reasonable and appropriate” for each organization, 405(d) includes guidance based on organization type and size.
Yet, the Security Rule’s standards set a foundation for each healthcare entity and business associate to follow.
45 C.F.R. 164.306(a), for example, details that organizations must:
- Ensure the confidentiality, integrity, and availability of all e-PHI they create, receive, maintain, or transmit
- Identify and protect against reasonably anticipated threats to the security or integrity of the information
- Protect against reasonably anticipated, impermissible uses or disclosures
- Ensure compliance by their workforce
To meet these requirements, 45 C.F.R. 164.306(b)(2) outlines considerations for organizations such as:
- Size, complexity, and capabilities
- Technical, hardware, and software infrastructure
- Security measures cost
- Likelihood and possible impact of potential ePHI risks
OCR’s Guidance on Risk Analysis
On July 14, 2010, OCR issued Guidance on Risk Analysis Requirements under the HIPAA Security Rule. This guidance details that every risk analysis must incorporate the following elements:
- Analysis scope
- Data collection
- Identify and document potential threats and vulnerabilities
- Assess current security measures
- Determine the likelihood of a threat occurrence
- Determine the potential impact of a threat occurrence
- Determine risk level
- Finalized documentation
- Periodic risk analysis reviews and updates
In this context, OCR considers a vulnerability to be any flaw or weakness in a system’s security procedures, design, implementation, or internal controls that an attacker could intentionally exploit, resulting in a security breach or violating a system’s security policy. This also includes the chance that internal personnel or associates could accidentally or intentionally exploit these issues.
A threat is considered the potential for a person or thing to accidentally trigger or intentionally exploit a vulnerability. This includes natural disasters such as weather incidents, earthquakes, etc., and intentional and unintentional human and environmental threats.
Risk is defined as the threat’s impact, considering the probability a threat actor will accidentally trigger or intentionally exploit a vulnerability or security weakness and its resulting impact.
Yet, even in this context, many organizations think other types of assessments, like a security controls gap assessment or a compliance gap analysis, can meet OCR risk analysis requirements; however, they cannot.
For clarity, a security controls gap analysis is a process that evaluates the effectiveness of an organization’s existing security controls compared to a set of industry standards, best practices, or regulatory requirements, such as the NIST Cybersecurity Framework or ISO 27001.
A compliance gap analysis determines how much an organization’s practices, procedures, and controls align with specific regulatory requirements or industry standards such as the HIPAA Security Rule, GDPR, PCI, or HITRUST.
Part of the confusion is anchored in the interchangeability, particularly for cybersecurity and other consultants, with the terms risk analysis and risk assessment; however, OCR is explicit in its expectations about risk analysis requirements. Your processes may include pieces of both a security controls gap analysis and a compliance gap analysis. Still, if your risk assessment doesn’t include all of the aforementioned OCR requirements, it’s not considered a compliant risk analysis.
A Closer Look at OCR Risk Analysis Guidance
Before taking a closer look at OCR’s risk analysis guidance, it’s essential to understand how OCR defines risk. Specifically, for HIPAA purposes, risks arise from legal liability or mission loss as a result of:
- Unauthorized (malicious or accidental) disclosure, modification, or destruction of information
- Unintentional errors and omissions
- IT disruptions due to natural or artificial disasters
- Failure to exercise due care and diligence in the implementation and operation of an IT system
And, while there is no single, specific risk analysis process that is reasonable and appropriate for every organization, there are some best practices all organizations can follow to ensure compliance.
1. Risk analysis scope
The scope of your risk analysis should include all of your ePHI, regardless of how or where it is created, received, maintained, or transmitted. That’s internally and across all third-party vendors you exchange protected information with.
Unfortunately, many organizations don’t have a good handle on this. Few know every system with ePHI or all the equipment or infrastructure that handles protected health data. Organizations rarely accurately document all of these details, which OCR mandates. That creates often overlooked increased risk.
Here are some of the key elements to consider as part of your risk assessment scope:
- Clinical systems and software
- Automated medication or medical supply cabinets
- Billing information system
- Claims payment system
- Clinical workstations (e.g., thin or zero-client computers, portable laptop carts, etc.)
- Core health information system
- Diagnostic equipment (e.g., EKG, EEG, pulmonary function testing, etc.)
- Dictation devices
- Electronic health record system
- Emergency department system
- Lab information system
- ICU/NICU telemetry system
- Oncology system
- Operating room software
- Picture Archiving and Communication System (PACS)
- Patient portal
- Radiology information system
- Incident management system
- Telehealth software
- Mobile patient apps
- Equipment and infrastructure
- Administrative workstations (e.g., desktop and laptop computers)
- Closed-circuit television (CCTV) system
- Document management system
- Microsoft SharePoint
- Email system
- Fax system
- Network file shares
- Document/records storage and management vendor
- Medical equipment maintenance supplier
- Cloud environment
- Medical devices
- Diagnostic equipment (e.g., EKG, EEG, pulmonary function testing)
- Laboratory equipment (e.g., hematology analyzer, TEG devices)
- Radiological equipment (e.g., CT, MRI, PET scanners, mammography, ultrasound, X-ray machines, gamma knife)
- Remote monitoring devices
- Business systems
- Financial system
- Human resources systems
2. Data collection
As part of OCR requirements, your organization must identify and document where all ePHI is created, received, maintained, or transmitted.
Recommended data collection methods:
- Review past and existing projects
- Perform interviews
- Review documentation
- Conduct CMDB system and software inventories
- Use other data-gathering techniques
3. Identify and document potential threats and vulnerabilities
To conduct a compliant risk analysis, you must also identify all reasonably anticipated threats and vulnerabilities.
Threat examples:
- Burglary
- Theft
- Electrical issue
- Fire
- Flood
- Inclement weather
- Malware
- Ransomware
- Network connectivity outage
- Power outage/interruption
Vulnerability examples:
- Anti-malware vulnerabilities
- Destruction/disposal vulnerabilities
- Dormant accounts
- Endpoint Leakage vulnerabilities
- Excessive user permissions
- Insecure network configuration
- Insecure software development processes
- Insufficient application capacity
- Insufficient data backup
4. Assess current security measures
OCR requires assessment and documentation of all security measures your organization uses to safeguard ePHI, including whether you’ve put required Security Rule measures in place and properly configured and used security measures.
NIST SP 800-53A Rev 5 is a good resource to help with this process. It identifies three control assessment methods:
- Examine method: Review, inspect, observe, study, or analyze one or more assessment objects (i.e., specifications, mechanisms, or activities) to facilitate understanding, achieve clarification, or obtain evidence.
- Interview method: Discuss with individuals or groups within your organization to facilitate understanding, clarify, or obtain evidence.
- Test method: Use one or more assessment objects (i.e., activities or mechanisms) under specified conditions to compare the actual object state to the desired state or expected behavior.
5. Determine threat occurrence likelihood
In this step, you should document all threat and vulnerability combinations (with associated likelihood estimates) that may impact the confidentiality, availability, and integrity of your ePHI.
Examples to consider:
- Based on your physical controls—or lack thereof—how likely is it that an unauthorized individual can procure an asset such as an administrative desktop?
- If a system is in a flood plain, how likely is it that your organization will lose access to that system if there is a flood?
- If you don’t have a vulnerability management program to patch security issues regularly, how likely is it that your organization will get malware on a clinical desktop?
6. Determine the potential impact of threat occurrence
Here, you should consider the criticality or impact of potential threats to the confidentiality, integrity, and availability of ePHI.
Based on the previous threat occurrence likelihood examples, consider:
- Looking at your physical controls — or lack thereof — what is the potential impact if an unauthorized individual procures an asset such as an administrative desktop?
- What is the potential impact if you lose access to an essential system due to a flood?
- If you don’t have a vulnerability management program to patch security issues regularly, what is the potential for a clinical desktop to get malware?
7. Determine risk level
For compliance, you should assign risk levels to all threat and vulnerability combinations you identify during your risk analysis. For example, you can determine the risk level by analyzing values assigned to the likelihood of a threat occurrence and the resulting impact of threat occurrence. You may also determine a risk level based on the average of the assigned likelihood and impact levels. Be sure to document each risk level and all corrective action tasks to mitigate each risk level.
8. Finalize documentation
Even if you do everything correctly, if you don’t document everything OCR requires, it won’t be considered a compliant risk analysis. While the guidance does not outline a specific format for documentation, your risk analysis documents should include:
- Where ePHI resides
- Threats
- Vulnerabilities
- Safeguards
- Likelihood of threat vulnerability combinations
- Impact of threat triggering vulnerability
- Risk levels and corrective actions
9. Periodic review and updates
OCR requires you to update and document security measures annually or as needed (e.g., bi-annual or every three years), depending on the circumstances of your environment. So, that means you should conduct continuous risk analysis to identify when you need these updates. Here are a few examples of when you may need to do an update:
- You’ve experienced a security incident
- There’s been a change in ownership
- There’s turnover in key staff or management
- You have plans to incorporate new technology
- You have new or different facilities
- You’ve identified new threats or vulnerabilities
Risk Framing Strategy
OCR recognizes that the Security Rule does not prescribe a specific risk analysis methodology and understands that organizations will take various approaches based on organization size, complexity, and capabilities. However, the Rule identifies risk analysis as the foundational element to achieve compliance and outlines objectives you must achieve; therefore, it’s a good idea to adopt a risk framing strategy, for example, NIST SP 800-39. This publication breaks down the risk analysis process with a broad look at risk management.
To achieve compliance, here’s an overview of the key elements your risk analysis should include:
- Risk assumptions and constraints: Assumptions that affect how your organization conceptualizes risk and constraints that limit choices regarding risk responses.
- Risk tolerance: Defines the risk level your organization will accept. This guideline informs decision-making when evaluating whether to mitigate, transfer, accept, or avoid specific risks.
- Priorities and tradeoffs: Identifies priorities that influence risk decisions and acknowledges you may need trade-offs to manage risk effectively (within the constraints of operational efficiency, cost, and mission objectives).
- Roles and responsibilities: Clearly delineate roles and responsibilities within your organization to manage risk. This ensures accountability and establishes who has the authority to make risk-based decisions.
- Risk management strategy: Outlines plans to address risk, including methods for risk assessment, risk response strategies, and how you will integrate risk activities into your broader organizational processes.
- Stakeholder engagement and communication: A growing number of compliance and cybersecurity regulations are shifting ownership and responsibility to the executive or board level. For OCR-compliant risk analysis, you must detail how stakeholders will be involved in the risk management process and how you will communicate information about risks and risk management activities across your organization and to external stakeholders.
Risk Analysis Audit Criteria
OCR’s risk analysis audit criteria evaluate policies and procedures and the risk analysis itself. The key areas reviewed during a risk analysis audit may include:
Policies and procedures
- Obtain and review risk analysis policies and procedures.
- Evaluate and determine if written policies and procedures address the purpose and scope of the risk analysis, workforce member roles and responsibilities, management involvement in risk analysis, and how frequently you will review and update the risk analysis.
Risk analysis
- Obtain and review a written risk analysis or other record(s) documenting your accurate and thorough risk and vulnerability assessment related to ePHI confidentiality, integrity, and availability.
- Evaluate and determine if the risk analysis documentation contains:
- A defined scope that identifies all systems that create, receive, maintain, or transmit ePHI
- Details of identified threats and vulnerabilities
- Assessment of current security measures
- Impact and likelihood analysis
- Risk rating
While risk analysis is required for HIPAA and other security and compliance regulations, it’s also best practice for organizations of all sizes. However, to ensure compliance with OCR, remember your analysis should:
- Be comprehensive in scope and cover all systems and associated components used to create, receive, maintain or transmit ePHI.
- Align with OCR Guidance Risk Analysis Requirements Under the HIPAA Security Rule.
- Be ongoing or continuous. Organizational and other changes like personnel, technology, facility, threats, and a recent breach are all reasons to conduct and document your risk analysis.
Need help with an OCR-quality risk analysis? We can help; learn more.
