To be HIPAA-compliant, an organization must conduct a risk analysis and implement a reasonable and appropriate set of information safeguards—aka information security controls—to provide for the adequate protection of ePHI against all reasonably anticipated threats. In practice, organizations that want to demonstrate HIPAA compliance must generally show that they have addressed each standard and implementation specification in the Security Rule, including risk analysis.
Unfortunately, the HIPAA Security Rule’s numerous standards and implementation specifications for administrative, technical and physical safeguards, despite what the terms imply, lack the prescription necessary for actual implementation by a healthcare organization. However, this approach was necessary as no two healthcare organizations are exactly alike, which means no single set of information protection requirements could possibly apply across the entire industry. In other words, one size truly does not fit all.
Regardless, this lack of prescription, along with a general lack of guidance from HHS on how organizations should interpret “reasonable and appropriate safeguards” and “adequate protection” resulted in wildly varying information protection programs amongst healthcare entities, including those of similar size and scope. Yet all these organizations likely believed they were “HIPAA compliant” because they had done something around each of the HIPAA standards and implementation specifications. By checking the box against the general requirements in the Rule’s implementation specifications, organizations subsequently checked the box—albeit inappropriately—for the risk analysis without actually conducting one.
OCR has publicly stated that it would not accept an assessment based on the original OCR Audit Protocol, which addressed each of the Security Rule’s standards and implementation specifications, as a valid risk assessment as required under the Rule. Further, an analysis of NIST SP 800-66’s mappings to NIST SP 800-53 indicates that the Security Rule’s standards and implementation specifications do not map to many of the controls in the baseline, which indicates that the Rule’s standards and implementation specifications do not address all reasonably anticipated threats as required by the Rule.
The position that simply focusing on the HIPAA standards and implementation specifications will not yield a valid risk analysis also appears to be supported by HHS, which states in their Guidance on Risk Analysis Requirements under the HIPAA Security Rule that “Conducting a risk analysis is the first step in identifying and implementing safeguards that comply with and carry out the standards and implementation specifications in the Security Rule.” Implementing the standards and specifications will not ensure compliance with the risk analysis requirement; but a risk analysis will help ensure compliance with the standards and implementation specifications.
Subsequently, we address the risk analysis requirement in a separate FAQ and compliance with the remaining requirements here.
To fully address the Rule’s standards and specifications, organizations must design or select multiple information security controls to provide the level of prescription necessary for implementation in the system or within the organization. For example, HIPAA § 164.312(a)(2)(iii) states organizations should “implement electronic procedures that terminate an electronic session after a pre-determined time of inactivity.” It’s left to the organization to decide how much time must lapse before terminating the session. But what’s appropriate? Five minutes? Ten? Thirty? Another example is HIPAA § 164.312(b), which requires organizations to “implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.” What types of mechanisms are appropriate? What type of activity should be logged? Who should have access to the logs? How long are the logs retained? An organization must ask and answer these types of questions thoroughly for each standard and implementation specification if they are to adequately address the threats for which these safeguards were designed.
The HITRUST CSF helps healthcare organizations address these questions by providing an extensive mapping of the CSF controls to the HIPAA Security Rule’s standards and implementation specifications, many of which are mapped to multiple controls. And the CSF controls themselves consist of multiple, specific requirements contained in multiple levels. By implementing the HITRUST CSF control requirements that are applicable to an organization based on its specific organizational, system and regulatory risk factors, each and every standard and implementation specification in the Security Rule is addressed in a very complete and robust way.
To provide the most complete assurances that the HIPAA Security Rule’s standards and implementation specifications have been addressed, organizations may conduct a comprehensive assessment of all their applicable CSF requirements in MyCSF, HITRUST’s online, GRC-based assessment tool. However, organizations may also use a baseline assessment used for CSF Certification as part of the HITRUST CSF Assurance Program to provide reasonable assurances the organization has satisfied the Rule’s requirements. This is because the assessment addresses 65 high-risk controls (out of a total of 135 for security) that map to each and every standard and implementation specification in the Rule.
For more information on the use of targeted assessments like the baseline assessment for CSF Certification, refer to the FAQ on risk analysis. For additional information on risk vs. compliance-based assessments, refer to the guide to Understanding HITRUST’s Approach to Risk vs. Compliance-based Information Protection. A complete mapping of the HITRUST CSF to the HIPAA Security, Data Breach and Privacy Rules can be found in a spreadsheet provided in HITRUST’s downloadable CSF package via the License Agreement landing page.