Developing a Proper Security Risk Analysis (HIPAA)

Several years ago, the HIPAA Security Rule brought about a wave of new regulations intended to strengthen the security of electronic protected health information (e-PHI). A number of these regulations refer to performing a “risk analysis.” But, what does that mean?

The regulations specify that a covered entity that creates, receives, maintains, or transmits e-PHI must perform a periodic and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the organization.

Perhaps it’s important to understand what a RA is NOT…

A Risk Analysis is NOT

  • A paperwork-drill where everything gets resolved in a policy
  • A checklist from HHS/OCR with all the “implemented” boxes checked
  • A simple vulnerability scan of the computing environment
  • An annual or one-time event to prove compliance

All too often we see organizations with mountains of policies and procedures with the mistaken belief that they’ve done their job in compliance. Unfortunately, that’s not the case. As any traditional risk management professional would tell you, evaluating risk is much more involved.

A Risk Analysis IS

  • A quantitative measurement of the risk to your e-PHI
  • Identification of all areas of where e-PHI is stored (including your partners)
  • A technical analysis of the potential threats to your e-PHI
  • The use of checklists, vulnerability scans, and other assessments to validate the risk findings
  • A living and documented process that continues to evolve as the organization does

If you do a google search for a HIPAA Risk Analysis, you’ll find lots of spreadsheets with the required Administrative, Technical, and Physical safeguards along with boxes to check. What you won’t find is a spreadsheet that attempts to actually understand the risk associated with these safeguards and your environment. That’s unfortunate; and something that we constantly have to address with our clients. If a risk analysis doesn’t actually define or quantify your risk, what exactly are you assessing?

Another area of concern is the use of policies that don’t reflect the actual environment. As an example: if you have a policy that states all passwords expire after 90 days, that mean’s all passwords – including the owners. While policy exceptions can sometimes be justified, they must always be documented and consistent with actual practice. Furthermore, thought needs to be given towards how you plan to assess all these safeguards, policies, AND exceptions in the future. Are you defining a policy that you can actually implement and test?

At GoldSky, we work to define your organization’s e-PHI scope, understand your business processes, quantify your areas of risk, and define a roadmap for improving your overall security posture. This is vastly different than checking boxes or just running a scan. Our services provide holistic insight into the security of your e-PHI as well as actionable remediation steps to help you improve your security program without hindering your business.