The HIPAA Security Rule places a great deal of emphasis on the importance of the security risk analysis—so much so that it was positioned front-and-center as an implementation specification under first standard in the first section of HIPAA. The requirement to complete a security risk analysis is under the Security Management Process standard in the Administrative Safeguards.
Yet, as we do HIPAA compliance audits and gap assessments for organizations, it is rare to find that a formal security risk analysis has been completed, and it is rarer still to find that the security risk analysis addresses what the authors of HIPAA intended.
The security risk analysis is critical to safeguarding electronic protected health information or “ePHI.” HIPAA requires both covered entities and their business associates to “Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic PHI held by the covered entity.”
If you provide services to a healthcare provider or payer, and in the process of providing services, you are given access to or may encounter ePHI, you are most likely a “business associate” under HIPAA. The US Department of Health and Human Services (HHS) clarified in publishing the HIPAA Omnibus Rule in September 2013 that business associates included all contractors and subcontractors if they were given access to ePHI similarly to employees.
Not sure a security risk analysis is all that important? If you’re in doubt, do a little research into what the HHS’ Office of Civil Rights or “OCR” has to say on the subject. OCR is the chief enforcer of HIPAA. When investigating a breach, the OCR routinely requests the security risk analysis and is more likely to impose a monetary fine when an organization has failed to inventory their ePHI and conduct a thorough analysis of the risk to the confidentiality of their ePHI. To the OCR, such laxity indicates that the organization has not established a culture of compliance – in essence, asserting that the organization is not showing evidence that they take HIPAA compliance seriously.
If you’ve concluded some attention may be warranted in this area, the first step is to take inventory of your ePHI—Find out where is it created, stored, maintained or transmitted. The “inventory” should consist of formal documentation that identifies the applications, data stores, system components and third party services providers (i.e., downstream business associates) that can access the ePHI.
After you know what ePHI you have, how you get it, where you store it and where it goes, you need to assess the risks that are posed to the ePHI in each of those areas. Most organizations have done this informally, and are managing their risks, but cannot demonstrate documented evidence of the “thorough risk analysis.” The formal security risk analysis should cover the ePHI environment, and each point in the flow of ePHI where vulnerabilities, threats and risks could exist. Where the risks to ePHI are unacceptable, organizations must develop the remediation plan to reduce the risks.
For do-it-yourselfers, see the link below for guidance: http://www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule/rafinalguidance.html
Additionally, the National Institute of Standards and Technology – NIST – has developed Special Publication number 800-30, revision 1, entitled Guide for Conducting Risk Assessments. This guide contains the widely used methodology for performing HIPAA-required security risk analyses. See: http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf.