Risk analysis made simple

Risk analysis is a process, and the more disciplined, complete and thorough the process, the better your result will be. The Office for Civil Rights (OCR) has expressed this in its incident investigation and audit findings over and over again.

It has also provided guidance on risk analysis, which can be found on OCR’s Web site. That guidance is based on the NIST Special Publication 800-30, but like so many other things described by engineers, it often seems more complicated than it really is, and therefore many won’t wade into those waters. So let’s take that guidance and boil it down to an easy-to-follow process with only a few steps.

Step 1: Define the scope and purpose of your risk analysis
Because it is a process, you can use it over and over again to assess risks against many different situations. Such as for compliance purposes (which we’ll map here), to assess a new program, and new technology (think meaningful use and your EHR), a new facility or a change to an existing one, or an incident (think Breach Notification Rule).  The point is if you adopt a standard way of conducting risk analysis, then no matter when you need it you know what to do, the results are consistent, and the approach fits your overall risk management framework. So the first step is to decide the purpose (why) of your assessment and the scope (what is in bounds) of coverage of your analysis. If the purpose is compliance, then you must also choose the regulatory standard you will measure risks against, such as the HIPAA Security Rule.

Step 2: Analyze the system environment
Identify which systems apply and collect basic information about them, such as who owns/maintains, what is their purpose, what requirements apply to them (i.e., are they your EHR or part of your Designated Record Set (DRS). Identify all threats that could reasonably be expected to apply (external and internal). Identify all vulnerabilities that apply (administrative, physical and technical). And enumerate all security controls you currently have in place that protect systems/data and mitigate risk. Then, taking your systems into consideration, combine threats, vulnerabilities and information about existing controls to identify where gaps might exist that represent risk.

Step 3: Quantify/qualify your risk
The scenarios identified in Step 2 that could present some level of risk require analysis. First off, consider each scenario from a likelihood-of-occurrence perspective, meaning if the set of conditions you identified existed, how likely is it that something bad could happen? To make it simple, you can express this as a high, medium or low probability of happening. Then take a look at each scenario and ask the question if this were to occur how damaging would it be and to what? This, too, can be expressed in a high, medium, low manner. High being a very negative impact, and low being negligible or minor impact. The final phase of your analysis is to put it all together and determine the level of risk each scenario represents to the business or compliance based on the factors identified.

Step 4: Remediate risks
In this step you decide how best to deal with the risks that you have identified. The first step is to prioritize them by criticality and then begin to list the various options for mitigating each. You’ll not want to limit your opportunities as sometimes a single remediation action can address multiple issues. Not all approaches will yield the same result as well, so you will want to calculate the extent of the mitigation per option and determine what is enough. You’ll also want to address the level of investment required for each option and perform a cost/benefit analysis taking into consideration the cost of a breach. This is particularly true for addressable requirements. The fewest number of mitigating controls, with the greatest return, for the least amount of investment should be part of your goal.

Step 5: You are not done till the paperwork is done 
Especially if the risk analysis was conducted as an assessment to meet HIPAA or HITECH compliance. You need to document the results of your analysis and plans for remediation. For the record, you need to describe the current situation and the risks identified. Moving forward, you need to document your approach to mitigation and remediate gaps identified. The risk assessment report, along with supporting documentation, should be retained for at least six years to support continuity and compliance. This report should also be circulated to the leadership of the organization to ensure visibility and gain support for remediation efforts.

Remember: Risk assessment is a required specification under HIPAA, is reinforced in meaningful use and Breach Notification, and is one of the first things the OCR asks for when reviewing a complaint, investigating a breach or conducting a compliance audit.

Add new comment