The ONC/OCR HIPAA Security Risk Assessment Tool: Review of Version 3.0’s New Features

Preliminary results of the Department of Health and Human Services’ Office for Civil Rights’ (OCR) Phase II Desk Audits conducted in 2016 revealed that 83 percent of covered entities reviewed were rated as “making negligible efforts to comply with the audited requirements” or not providing “OCR with evidence of serious attempt to comply with the Rules.” Over 94% of covered entities failed to demonstrate appropriate risk management plans.⁴

In 2014, the Office of the National Coordinator for Health Information Technology (ONC) released a tool to assist providers in performing their SRAs. In October 2018  ONC and OCR published the third release of its tool, version 3.0, continuing to improve upon features based on user feedback. This article reviews the requirement to perform an SRA and evaluates the newest version of the tool compared to prior versions.

Background

HIPAA’s SRA provision requires covered entities and business associates to “conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of [their] electronic protected health information.”⁵ Vulnerabilities are “flaw[s] or weakness[es] in system security procedures, design, implementation, or internal controls that could be exercised…and result in a security breach.”⁶ Weaknesses may be non-technical, such as failing to implement effective policies, or technical, such as insufficient information security configurations. Where there are vulnerabilities to ePHI, there are threats – opportunities to trigger or exploit the flaw or weakness.  Analyzing risks to ePHI involves identifying vulnerabilities, threats, and the likelihood that identified threats may exploit the vulnerabilities.

The scope of this identification and assessment of vulnerabilities and threats extends to ePHI created, received, maintained, or transmitted in any form or medium. ePHI may be located on any hard drive, CD, DVD, laptop, workstation computer, USB drive, floppy disk, memory card, server, or any other electronic media. After identifying locations of ePHI, an organization needs to determine what threats and vulnerabilities exist, the relative likelihood that a security incident will occur, and corresponding criticality of an incident related to the organization’s weaknesses. During this assessment of risks, organizations should inventory and record measures they already have in place to protect against identified threats and vulnerabilities. The output will help the organization identify where the greatest risks to the confidentiality, integrity, and availability of ePHI remain.

Common Misperceptions of the Requirement

The plain text of the SRA requirement within the Security Rule leaves much room for confusion and misperception. Certain myths have circulated throughout the industry, creating risks for covered entities and their business associates’ HIPAA compliance programs and consequently to the protection of ePHI. These myths need to be dispelled.

• Completing an SRA Does Not Necessarily Result in HIPAA Compliance. The SRA is only one security standard under the Security Rule. Other standards include designating a member of the workforce to be responsible for the development and implementation of security policies and procedures, conducting security awareness training, implementing physical safeguards for all workstations that access ePHI, restricting access to authorized users, and implementing technical security measures to guard against unauthorized access to ePHI that is being transmitted over an electronic communications network.⁷ Completing the SRA does not guarantee compliance with the many remaining standards and implementation specifications. An SRA is simply that – an evaluation of whether and how the organization addresses security risks and measures set forth under the Security Rule. In addition, the SRA often does not address the requirements in HIPAA’s Privacy Rule or the Breach Notification Rule, which also need to be followed for full HIPAA compliance.
• SRAs Are Not Optional. Risk analysis is a required implementation specification for the security management standard within the HIPAA Security Rule.  Any implementation specification indicated as “required” must be implemented by covered entities and business associates.⁸ One of OCR’s primary findings from Phase II of its audit program was the failure of audited entities to complete a thorough and accurate SRA, where 83% of entities audited were rated as “inadequate” or worse on their SRA compliance.⁹
• Merely Implementing Security Measures Does Not Satisfy the SRA Requirement. Adopting general, administrative, physical, and technical safeguards is required by HIPAA.¹⁰ Administrative safeguards revolve around appointing responsibility for the security program and developing policies and procedures.¹¹ Physical safeguards address the measures related to buildings and equipment, natural and environment hazards, and unauthorized intrusions that could affect the security of ePHI.¹² Technical safeguards include technological measures for protecting ePHI and control of access of it.¹³ Promulgating safeguards, however, are separate and distinct HIPAA requirements from the SRA. The SRA considers the effectiveness of safeguards a provider has selected, allows the provider to detect gaps between HIPAA requirements and current processes, and aids in the identification of remaining vulnerabilities the covered entity or business associate can continue to improve upon.
• Completing a Checklist Alone is Likely Insufficient. While checklists can help inventory HIPAA’s security requirements and aid in the identification of locations of ePHI or other components of the SRA, checklists alone will most likely fall short of explaining threats and vulnerabilities to ePHI and documenting an organization’s existing security measures.  Checklists frequently fail to meet the SRA requirement because they are too prescriptive, require only yes or no responses, and do not detail with specificity the array of safeguards selected by an entity unique to that organization and evaluate risks specific to its unique security environment.¹⁴
• Even Entities Without Electronic Health Records (EHRs) Must Conduct an SRA. Any individual or organization that is a covered entity or business associate under HIPAA must conduct an SRA. A law firm that occasionally assists healthcare providers in performing healthcare operations through use of ePHI, for example, must conduct an SRA even though the organization does not use an EHR for the ePHI it receives, maintains, or uses.¹⁵
• SRAs Must be Performed Periodically. A common misconception is that once an SRA has been conducted, an organization has satisfied the requirement under HIPAA and need not perform the SRA again. In reality, SRAs should be conducted periodically at a frequency based on factors such as changes in technology being utilized, staff turnover, and change in ownership.¹⁶ ONC implies a risk analysis should be conducted annually or as needed.¹⁷ Covered entities attesting to meaningful use and MIPS measures must be aware that an SRA must be performed for each reporting period they attest under, no later than the last day of the reporting period.¹⁸

OCR and ONC’s Latest SRA Tool

The release of OCR and ONC’s updated SRA tool in October 2018 improves upon previous tools made available by ONC and by the National Institute of Standards and Technology. The downloadable software program is stored locally on the user’s computer, and the information entered is not received by, collected, viewed, stored, or transmitted to OCR or ONC through use of the tool. Its improved features are designed with small to medium providers in mind.¹⁹ As with previous versions, OCR and ONC note that use of the tool is neither required by nor guarantees compliance with federal, state or local laws.²⁰ The tool’s release also follows a string of high profile settlements with and civil monetary penalties against entities for security-related breaches, exceeding more than $20 million in 2018 alone.²¹ The current version includes decision-tree logic based on user input to help guide the user through the assessment process, improved threats and vulnerabilities ratings, improved tracking mechanisms for business associates and assets, and detailed reports with graphical summaries of assessment results.²² Data entry is divided into seven sections: 1) SRA Basics; 2) Security Policies; 3) Security & Workforce; 4) Security & Data; 5) Security and the Practice; 6) Security and Business Associates; and 7) Contingency Planning.

Analyzing the Assessment Tool Information Inventory

After downloading the software program, entities can begin an inventory of their practice locations; assets used to create, maintain, or transmit ePHI; and vendors. User forms allow for adding multiple locations, which helps ensure that the entity considers all  assets and considerations at each of these locations. The program’s first data collection screen provides multiple options for entering assets. Hyperlinks offer additional information to explain what assets should be identified: “laptop and desktop computers, tablets, servers, medical equipment, and other items that might store or transmit ePHI.”²³

Interestingly, the examples provided in this version omit several examples included in the second version of the software. Entities should be mindful that while the assets listed are examples of the most common assets, others are equally important and often forgotten when considering an organization’s security risks. For example, mobile devices, smartphones, USB drives, CDs, and even some printers and copiers are assets that were previously listed in the second release of the software. Additionally, organizations should recognize that all assets which may create, maintain, transmit, or receive ePHI should be considered. In some cases, this may include personal devices not owned by the entity, but which are used by members of the workforce.

There are two methods for entering assets: a user form within the software program itself, or downloading an Excel template for entering assets which can be uploaded into the program once completed. The benefit of the in-tool user form is the inclusion of drop-down lists of options for each field, which can be helpful reminders of the types of assets and attributes for each, such as whether the ePHI on the asset has been encrypted. It also offers the advantage of standardization so that assets can be managed easier through data sorting and filtering. A disadvantage of the drop-down boxes is that they leave no opportunity to enter data that is not listed as a pre-populated option. For example, one can describe an asset’s access to ePHI as “creates,” “receives,” “transmits,” “maintains,” “receives and transmits,” “all of the above,” “none of the above,” or “unknown.” An entity wanting to identify that an asset “creates and maintains” ePHI does not have the option to make this selection through the in-program user form, which may be helpful for some medical devices where ePHI is created and stored on the device but may not be received or transmitted. The program also collects information about the disposal of assets, such as whether the devices was properly disposed and the disposal date. However, there is not a field to identify the method of disposal, a feature that most organizations desire to document, and a consideration  OCR suggests entities address in their policies and procedures for final disposition of hardware and electronic media containing ePHI.²⁴

Vendors and business associates can be entered in much the same manner as assets. Multiple contacts with the vendor/business associate can be entered, and at the time of entering each vendor, the organization can identify if satisfactory assurances have been obtained to secure the ePHI, such as a written business associate agreement that imposes such a requirement, and whether any additional risks have been assessed for this vendor. Neither the software program nor its user manual provides information on what “additional risks” refers to, but users can add free-text notes for each vendor.

For both assets and vendors, users utilizing the Excel template should also be cognizant that additional columns cannot be added to the template and uploaded into the SRA  software program. While this feature would be helpful for entities desiring to document and track additional data elements related to their assets and business associates, doing so causes an error when the file is being re-loaded into the software.

Completing the Assessment

A new feature in the latest release is customized assessment logic, which utilizes a decision-tree type algorithm to determine what questions to ask based on the information being entered. The decision-tree formula can be very helpful for the small and medium sized organizations the program is focused on helping, but also imposes some limitations. For example, when asked what information is included in an organization’s SRA documentation, there are only five options, but no opportunity to enter a description of the information an entity documents as part of its SRA which is not included in the options provided.²⁵

Potential vulnerabilities are provided directly by the program as a series of checkboxes, allowing multiple selections, another advantage for users without extensive security experience. This advantage can also be a drawback, however, if the entity wished to include an additional vulnerability not set forth in the program’s pre-populated list.

At the end of each section, the user is provided highlights on areas of security success and areas where improvement could be made. Here, the user can add information and upload documents.

Upon completion, the program provides an SRA summary, graphically displaying scores in each of the seven sections and identifying areas for review and vulnerabilities. A risk report provides a breakdown of low, medium, high, and critical risk areas, color-coded for easy visual reference.

Benefits and Improvements of the Tool

The SRA Tool 3.0 has operational benefits in addition to providing assistance with performing and documenting an SRA. The application may, for example, serve as a good resource for an inventory of the organization’s business associates and subcontractors and their contact information, as well as the entity’s assets which may create, receive, or maintain ePHI. Finally, the entire analysis can be exported to .pdf in a user-friendly, readable format displaying the date of the report, which may aid in the production of the SRA to  OCR upon an investigation or to the Centers for Medicare & Medicaid Services (CMS) in the event of an audit of a covered entity’s meaningful use or MIPS attestation. Another improvement from the previous tool includes walking users through an analysis of threats and vulnerabilities related to measures where the user identifies potential vulnerabilities.

Limitations of the SRA Tool

An initial limitation as the SRA is initiated is that the user only sees a navigation menu for Sections 1-7, without the Sections’ titles. The SRA forces users to proceed through each question and section in a specific order, but the user does not know in advance the subject of each section that would allow compilation of data before beginning. In addition,  users are unable to flag a question for review and return to it later. Small and medium sized organizations in particular often must investigate their procedures and documentation during the SRA process, and the inability to navigate the tool freely could delay completing items that occur later in the program’s assessment sequence. Users tempted to select “I don’t know” as a placeholder response and return to the question at a later time will find it difficult to do so without redoing the entire SRA.

Both the older and newer versions of the software identify the relevant security regulation for the items being assessed. In the prior tool, the regulatory citation identified the implementation specification as “required” or “addressable.” The newest version does not distinguish between required and addressable implementation specifications. Users unfamiliar with the regulatory framework must find the citation under HIPAA’s regulations to confirm its status as required or addressable. This becomes important in documenting alternative safeguards implemented in lieu of an addressable specification. The Security Rule requires organizations to “document why it would not be reasonable and appropriate to implement the [addressable] implementation specification.”²⁶ If a specification is addressable, the entity should determine if it would be reasonable and appropriate to adopt the specification given the organization’s resources, relative cost of the measure compared to its resulting contribution to the security of ePHI, and other capabilities or limitations of the organization. If the entity determines it cannot reasonably and appropriately implement the addressable specification, it should implement any reasonable alternative and document why it could not comply fully with the specification.

In the previous version of the SRA tool, responding “no” to an implementation specification prompted the user to identify the best reason for choosing not to implement the specification, using language from the regulations.²⁷ This included “cost,” “size,” “complexity,” and “alternate solution.” The previous version only allowed a user to choose one of these options, making it difficult to identify multiple reasons justifying an alternative measure. In the latest tool, however, the user is not prompted at all to enter this documentation. Most small to medium size organizations are unaware of the requirement to document these considerations when choosing an alternative measure, and lack of a prompt to do so may result in deficiencies if their security risk management processes are reviewed.

The Security Rule categorizes safeguards as administrative, physical or technical in nature.²⁸ Administrative safeguards may involve policies and procedures such as designating a security officer; physical safeguards may include managing keys or badges to secure areas; and technical safeguards may include encryption mechanisms or password management.²⁹ In comparison to prior versions, the new tool does not categorize identified risks as administrative, physical, or technical, but instead by the section in which the risk was addressed in the  tool. When categorized by the type of security measure and safeguard in the prior version of the tool, organizations could more easily assign responsibility for addressing identified risks. For example, administrative safeguards may be the responsibility of an office manager, privacy officer, or administrator, while physical safeguards may fall under the purview of facility maintenance, and technical safeguards may be the responsibility of IT.

Finally, organizations should also recognize that the tool does not assess the contents of the entity’s policies and procedures – a process that is addressed in  OCR’s extensive audit protocols most recently updated in July 2018. Instead, the tool merely identifies whether or not various required policies and procedures are in place. Entities interested in delving further into their compliance and preparedness for an audit can access  OCR’s audit protocols online to assess whether specific provisions are addressed in each of those policies.³⁰

Conclusion

OCR and ONC’s updated SRA tool is user-friendly and an excellent resource to ensure that an organization addresses security standards. Conducting an SRA and resolving identified vulnerabilities can greatly reduce the risk of suffering a breach of ePHI and violating HIPAA. However, entities must understand the thorough documentation that must accompany its data selection fields in order to fully and properly comply with HIPAA’s SRA requirement. They also must recognize that the obligations to comply with HIPAA extend beyond addressing security risks. Completing the security risk assessment is important, but  only one of many requirements under HIPAA and part of a comprehensive HIPAA compliance program.

¹ 68 Fed. Reg. 8334.

² See 45 C.F.R. § 164.302 et. seq.

³ 75 Fed. Reg. 44314, 44369 (July 28, 2010) (identifying an SRA according to 45 C.F.R. § 164.308(a)(1) as a Stage 1 meaningful use requirement for both eligible professionals and eligible hospitals); 77 Fed. Reg. 53968, 54003 (September 4, 2012) (requiring an SRA under Stage 2 of meaningful use); 81 Fed. Reg. 77008, 77219 (November 3, 2016) (making an SRA a requirement of the MIPS payment program).

⁴ Update on Audits of Entity Compliance with the HIPAA Rules, Office for Civil Rights (September 2017), available at https://www.nist.gov/sites/default/files/documents/sanches_0.pdf (last accessed October 28, 2018).

⁵ 45 C.F.R. § 164.306(a)(1)(ii)(A).

⁶ Gary Stoneburner et al., Risk Management Guide for Information Technology Systems, Department of Commerce’s National Institute of Standards and Technology Special Publication 800-30 (July 2002).

⁷ 45 C.F.R. §§ 164.308, 310, 312.

⁸ 45 C.F.R. § 164.306(d)(1)-(2).

⁹ Sanches, Linda, Update on Audits of Entity Compliance with the HIPAA Rules, Office for Civil Rights (OCR) U.S. Department of Health and Human Services. (September 2017), available at https://cynergistek.com/wp-content/uploads/2017/09/OCR-CE-Desk-Audit-Results-09_17-.pdf   (last accessed October 31, 2018).

¹⁰ 45 C.F.R. §§ 308, 310, 312.

¹¹ 45 C.F.R. §§ 164.304, 308.

¹² 45 C.F.R. §§ 164.304, 310.

¹³ 45 C.F.R. §§ 164.304, 312.

¹⁴ Top 10 Myths of Security Risk Analysis, Office of the National Coordinator for Health Information Technology (September 20, 2017), available at https://www.healthit.gov/topic/privacy-security/top-10-myths-security-risk-analysis (last accessed October 31, 2018).

¹⁵ 45 C.F.R. § 164.306(c)-(d), 45 C.F.R. § 164.308(a)(1)(ii)(A), See 45 C.F.R. § 160.103 (defining business associate as including persons who perform legal services on behalf of covered entities involving use or disclosure of protected health information).

¹⁶ Office for Civil Rights Security Risk Analysis Guidance (July 14, 2010).

¹⁷ Basics of Risk Analysis and Risk Management, Office for Civil Rights Department of  Health and Human Services (March 20, 2007), available at https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/administrative/securityrule/riskassessment.pdf.

¹⁸ 75 Fed. Reg. 44314, 44369 (July 28, 2010) (explaining “[eligible professionals] and eligible hospitals conduct or review a security risk analysis of certified EHR technology and implement updates as necessary at least once prior to the end of the EHR reporting period. The testing could occur prior to the beginning of the EHR reporting period.”); See generally Top 10 Myths of Security Risk Analysis, Office of the National Coordinator for Health Information Technology, available at http://healthit.gov/providers-professionals/top-10-myths-security-risk-analysis.

¹⁹ Security Risk Assessment Tool User Guide, Office of the National Coordinator for Health Information Technology U.S. Department of Health and Human Services (October 16, 2018), available at https://www.healthit.gov/sites/default/files/page/2018-10/SRA_Tool_User_Guide_101518.pdf (last accessed October 31, 2018); ONC and OCR Bolster the Security Risk Assessment (SRA) Tool with New Features and Improved Functionality (October 16, 2018), available at https://www.hhs.gov/about/news/2018/10/16/onc-and-ocr-bolster-security-risk-assessment-sra-tool-new-features-and-improved-functionality.html (last accessed October 31, 2018).

²⁰ Id.

²¹ Resolution Agreements and Civil Monetary Penalties, Office for Civil Rights Department of Health and Human Services, (October 15, 2018) available at https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/agreements/index.html (last accessed October 31, 2018).

²² ONC and OCR Bolster the Security Risk Assessment (SRA) Tool with New Features and Improved Functionality (October 16, 2018), available at https://www.hhs.gov/about/news/2018/10/16/onc-and-ocr-bolster-security-risk-assessment-sra-tool-new-features-and-improved-functionality.html (last accessed October 31, 2018).

²³ See Security Risk Assessment Tool, Practice Info, Assets Screen.

²⁴ Guidance on Disposing of Electronic Devices and Media, Office for Civil Rights Cybersecurity Newsletter, July 2018.

²⁵ The options provided are “1) Our SRA documentation includes possible threats and vulnerabilities which we assign impact and likelihood ratings to. This allows us to determine severity. We develop corrective action plans as needed to mitigate identified security deficiencies according to which threats and vulnerabilities are most severe. 2) Our SRA documentation includes possible threats and vulnerabilities which we assign impact and likelihood ratings to. This allows us to determine severity. We do not include corrective action plans. 3) Our SRA documentation includes possible threats and vulnerabilities but does not include impact and likelihood ratings, severity ratings, or corrective action plans. 4) I don’t know. 5) Other.

²⁶ 45 C.F.R. § 164.306(d)(3)(ii)((B)(1).

²⁷ See 45 C.F.R. § 164.306(b)(2).

²⁸ See 45 C.F.R. §§ 164.308, 310, 312.

²⁹ Id.

³⁰ Audit Protocol – Updated July 2018, Office for Civil Rights Department of Health and Human Services (July 2018), available at https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/audit/protocol/index.html (last accessed October 31, 2018).