HIPAA requires covered entities and business associates conduct a Security Risk Analysis (SRA) to ensure compliance with addressable and required elements of the HIPAA Privacy and Security rules. The intent of the SRA process is to identify where protected health information (PHI) lives in both physical and electronic form, to assess risks and vulnerabilities to that PHI, identify current measures through any supporting policies and procedures, and as necessary mitigate and address the identified risks.
As the Office of Civil Rights (OCR) begins to audit Security Risk Analysis documentation and value-based reimbursement programs require a current SRA for participation, completing a comprehensive SRA is more important now than ever. While the components of completing a Security Risk Analysis are not new, it can be difficult to grasp a concise picture of the process. Best practices and considerations for completing a comprehensive SRA are aggregated and outlined below.
Why Analysis instead of Assessment?
While the terms Security Risk Analysis and Security Risk Assessment are often used interchangeably, Security Risk Analysis is the preferred name. The HIPAA Privacy Rule includes the concept of a Risk Assessment, or analyzing a breach of PHI to determine if there is a low probability of compromise to the unauthorized PHI. As utilizing the term Security Risk Assessment could create confusion between it and the breach Risk Assessment, the term Security Risk Analysis should be utilized when discussing the SRA process.
Requirements of a Security Risk Analysis
There is no required format of a Security Risk Analysis, however, there are specific components which should be considered and included while conducting a SRA.
Timeline for Execution
It is strongly recommended (and required by value-based reimbursement) a Security Risk Analysis is conducted or reviewed on an annual basis. Because of calendar year reporting requirements, many organizations conduct one SRA per each calendar year. While not required by HIPAA to be completed on an annual basis, evaluation of the SRA should be done periodically as the organization’s environment or operations may change, and documentation should be updated appropriately to indicate those improvements or changes.
Required versus Addressable
Various elements in HIPAA are labeled as “required” or “addressable”. If an element is labeled as required, it must be implemented. If an element is labeled as addressable, the organization must implement either the measure or an equivalent measure. For instance, encryption is considered an addressable element. If an organization chooses not to implement encryption, they must implement an equivalent standard and explain why the initial element is not reasonable and appropriate in their organization.
Threat Identification
A major component of the Security Risk Analysis process is identifying possible threats to the practice and PHI. Typically, threats can be natural, human or environmentally based. Overall, a threat can take advantage of vulnerabilities in the organization if not properly addressed.
Current Controls
One of the most critical components of a Security Risk Analysis is documenting what the organization is doing to satisfy both the required and addressable components of HIPAA. The organization may identify the current or suggested control as a statement. Additionally, the organization should highlight what policies and procedures are in place to support the control. Finally, the organization should identify if there are any known gaps or vulnerabilities with what the organization currently has in place.
Associated Risk
As the organization assesses the associated risk of the control, they will analyze the likelihood of the threat, the organizational impact if the threat were to occur, and the overall risk determination. Many organizations use a stoplight analogy for assessing risk; low risk is equivalent to green, medium risk is yellow, and high risk is red. The classification of risk by color assists an organization in determining and prioritizing their risks as well as their mitigation plans.
Work Plan
As a result of the Security Risk Analysis process, the organization should produce an action plan document which allows them to work on the risks identified in the time prior to the next SRA, frequently referred to as the Work Plan. This document often lives in a spreadsheet, and allows the organization to assign responsibility for mitigation to the identified risks though the SRA process. Furthermore, this document shows progress on addressing identified risks in the time between Security Risk Analyses, something the Office of Civil Rights is looking for in their recent audits. Most organizational Work Plans include the identified threat, current controls, identified vulnerability, likelihood, impact, risk rating, suggested controls, along with an additional column for progress made in addressing the threat.
Value-Based Reimbursement Programs Requiring a SRA
When the Meaningful Use program deployed in 2011 from the Center for Medicare and Medicaid Services (CMS), providers were met with a requirement to perform a Security Risk Analysis in order to participate in the program. The SRA obligation has continued to be a mainstay in quality reporting programs, as it carried through each version of Meaningful Use and is now found as a requirement in the Merit-Based Incentive Payment Systems (MIPS) Advancing Care Information (ACI) measures. For MIPS, if an organization does not conduct a SRA in the time before or during the reporting period, they receive no ACI category points. The presence of the SRA as a required element in these programs to receive reimbursement illustrates the importance various government agencies like HHS, OCR, and CMS place on the value of the SRA process.
Resources for Completing a Security Risk Analysis
A Security Risk Analysis can be conducted in-house or by an external party. HHS produced a SRA tool and guide to facilitate the process among smaller organizations. However, HHS warns the SRA is only as good as the quality of information inserted into the tool. As the process to produce a SRA can be quite cumbersome and overwhelming, it can be worthwhile to use an external party to assist an organization in producing an SRA. Frequently, healthcare attorneys are capable of working with a healthcare organization to produce a SRA, as well as an information technology managed service provider. In either case, it is critical the external party has experience in conducting a SRA. Other third-parties exist who specialize in HIPAA requirements, like the Security Risk Analysis process. These organizations typically have extensive experience in gathering and assembling documentation to tell the story of an organization through the Security Risk Analysis. Some organizations even use a combination of the above methods, reviewing and updating documentation internally some years, and utilizing external parties for conducting the SRA in the alternating years.
Regardless of what methodology an organization chooses for their Security Risk Analysis, it is critical to have an external party at some point review the documentation to assure it meets the expectations of the Office of Civil Rights. Organizations can often fill in holes in documentation with their own knowledge, but an external party can identify those gaps, allowing the organization to improve their documentation in case of an OCR audit.
Overwhelmed by the prospect of completing a Security Risk Analysis before the end of the calendar year? ScanSTAT Technologies can help! Learn more about our ScanSTAT Security Risk Analysis service.