No matter the size of your practice, compliance with the HIPAA Security Rule is a serious undertaking. In order to fix a problem, you must first know it exists. That’s why the Risk Analysis and Risk Management implementation specifications are the foundation of your security compliance efforts. We touched on risk management in Part 2 of our HIPAA series, but in the next two articles we’ll be digging into the Risk Analysis and Risk Management implementation specifications more thoroughly with tips and tools to help you through the process.
The importance of performing a thorough risk analysis and coming up with a risk management strategy cannot be overstated. Throughout this article there will be links to resources to help you decide how best to perform your risk analysis. If you’ve never performed a risk analysis, we strongly suggest going over those resources first.
What is a Security Risk Analysis?
While much of this article presents an outline of how to conduct a Security Risk Analysis (SRA), it first helps to understand what an SRA is. Identifying that a problem exists—or could exist—is crucial to fixing it, preventing it, or making it as safe as possible. That is the purpose of the SRA.
An SRA is ultimately a process that allows you to analyze the way your company approaches risk and see how all areas of your business or organization—from policies and procedures to technical implementation—influence each other. It creates lists of threats, vulnerabilities, and threat events which could impact not only your organization, but your patients, customers, or vendors as well. Once you understand the risk in your daily business functions, finding a solution to keep them secure and operational is much easier.
Threat: the potential for a person or thing to trigger or exploit a vulnerability.
Vulnerability: a flaw or weakness in the system security procedures, design, implementation, or internal controls that could be accidentally triggered or intentionally exploited and result in a security breach or a violation of the system’s security policy
Threat Event: how a particular threat could trigger or exploit a specific vulnerability
The SRA process is complicated and can require a substantial investment of time and effort to complete, depending on the size and scope of your business. But when it’s finished, the SRA will provide you with a blueprint for the future. It identifies areas that are protected, areas that could use some fixing, and areas that are desperately unprotected. This allows you to prioritize your needs and create a risk management strategy specific to your environment. And when going through your HIPAA Security Rule compliance, there’s no better tool than an SRA.
Why Do You Need a Security Risk Analysis?
For HIPAA, you must conduct a targeted SRA. §164.308(a)(1)(ii)(A) requires an “accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information. . . .” The key to this is the specification of electronic protected health information (ePHI).
Since the Security Rule only deals with ePHI (where the Privacy Rule handles all PHI), the SRA only needs to focus on the ways in which ePHI is created, received, maintained, or transmitted. Including or performing a second SRA to include all PHI and the ways it could be improperly handled or disclosed would be best practice to assess your policies and procedures regarding non-electronic PHI, but it’s not required under HIPAA.
It’s important to remember that ePHI involves far more than an electronic health or medical record system. It includes all types of electronic media hardware that can create, receive, maintain, or transfer ePHI, as well as software such as appointment calendars or billing databases.
While it can only help your organization to conduct a business-wide risk analysis, the targeted scope of ePHI under HIPAA narrows what you need to assess. Don’t narrow your field too much, though. The cost of insufficient or non-existent SRAs and risk management plans can lead to data breaches and serious fines.
According to the Office of the National Coordinator (ONC) for Health Information Technology, simply filling out a checklist is not enough to complete an SRA or count as proper documentation of one under HIPAA. You can learn more about common misconceptions about the SRA at the ONC’s website.
Guides and Tools to Help You Conduct a Security Risk Analysis
While no tool can replace a thorough and accurate SRA, there are plenty to assist you during the process. The ONC recently released an updated version of its SRA Tool that you can download to help identify areas that may need improvement. They also have video tutorials like the one below and interactive games to test your knowledge of both privacy and security requirements.
ONC’s overview of the Security Risk Analysis
There are also numerous guides to help you better understand the process of risk analysis and management. Besides what we’ve mentioned in previous articles (the Department of Health and Human Services’ (HHS) HIPAA Security Series, and NIST’s Introductory Resource Guide—Appendix E), both the ONC and the HHS have overviews of the process.
For detailed explanations of the risk analysis and management process, NIST published two separate guides: SP 800-39 Managing Information Security Risk and SP 800-30 Guide for Conducting Risk Assessments. These are not specifically geared to HIPAA’s SRA, but the level of information provided is far more complete than many of the HIPAA-specific guides. We recommend that you read SP 800-39 before SP 800-30. While SP 800-30 offers greater detail about specific parts of the risk analysis process (especially in the appendices), SP 800-39 is more reader friendly and a good foundation for SP 800-30.
How to Conduct a Security Risk Analysis
Like all parts of HIPAA, scalability and flexibility are at the core of the SRA. A two-dentist practice isn’t going to need the same kind of SRA as a large nursing facility, so HIPAA doesn’t dictate the exact steps to conducting an SRA. However, all thorough and accurate SRAs will go through similar steps and feature key information, no matter the format you choose. As always for HIPAA, document each step for the final SRA report.
Note: While going through the steps, it’s important to remember to look at risk from an organizational perspective (business-wide policies and procedures or budgets), a business function perspective (billing or patient care), and an informational systems perspective (settings on specific technology or hardware purchases). Another way to look at this would be administrative, physical, and technical lenses to match up with the HIPAA safeguards (though, if you prefer HIPAA terminology, keep in mind that physical isn’t perfectly analogous to business function.)
Step 1: Gather a Team
An SRA shouldn’t be performed by one person. Business owners or senior leadership should work together with management and IT experts during the SRA process. Not everyone sees risk the same way, and having a knowledgeable team ensures that your SRA will identify risk from all necessary perspectives.
Step 2: Determine the Scope
In this case, HIPAA has defined the scope for you in §164.308(a)(1)(ii)(A): “the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information” wherever it is created, received, maintained, or transmitted.
If it holds, accesses, or transmits ePHI, it is part of the SRA. For some businesses this will be a lot to cover, while others may only reference a few systems. And while the scope could be increased to include all PHI, it shouldn’t be reduced.
Step 3: Create a Risk Analysis Framework
A risk analysis framework isn’t required for an SRA, but it’s a useful tool to maintain consistency and avoid ambiguity between those preparing the SRA, those implementing it, and those conducting future SRAs. Since few people see risk the same way, the framework creates a clear set of assumptions, constraints, risk tolerances, and priorities/tradeoffs that will determine how your business manages risk.
Many of these terms appear in later steps, but they’re not used in the same way. In the framework you explain how to identify and respond to the risk factors, while later you use the framework to actually identify and respond to the risk. The framework puts everyone on the same page so that each person knows what to look for, how to judge the risk, and how to manage that risk appropriately.
The framework should also dictate the methodology you use to conduct this and future SRAs. This can be qualitative (high, medium, low), quantitative (numerical quantities), or a mix of both. Not all risk can be numerically quantified (# of individuals affected vs lost reputation—the first can be counted, the second cannot), so a qualitative or mixed approach can be more useful.
If you choose to skip the framework step, much of this information will still need to be explained in later steps to satisfy documentation requirements, and you won’t have it readily available for subsequent SRAs.
Step 4: Gather Data
In order to determine the risk to ePHI, you must first determine where it is stored, received, maintained, and transmitted. And while this encompasses a great deal more than physical hardware, having a record of the physical hardware and its movements is a part of the Physical Safeguards (§164.310(d)(2)(iii)—Accountability). This is especially important as more and more healthcare settings utilize portable electronic media, such as tablets or laptops.
Think of the flow of ePHI. Where does it begin in your business? Do you create it or receive it? Follow it from its starting point to endpoint and document what systems each piece of ePHI interacts with. Depending on your business, this could be only a few pieces of software and hardware or it could be most systems in the office. Either way, you need a complete list in order to conduct a HIPAA-compliant SRA.
Step 5: Identify and Document Potential Threats and Vulnerabilities.
This could be considered one step or two, depending on how you decide to conduct your SRA. It may be simpler to identify potential threats and vulnerabilities separately, but you may find that as you identify a threat, you also identify the vulnerability it could exploit and vice versa. It is up to your team to decide the best method.
If you’ve already created a framework, you’re ready to identify threats and vulnerabilities. If not, take some time to decide what you’re going to consider a threat or vulnerability, how you’ll identify them, and what sources are valuable to work from during the process.
Sources of information could include past SRAs, business security reports or testing, known breaches of similar institutions (Breach Level Index, OCR Breach Report), the security community’s public lists and advisories (National Vulnerability Database, National Checklist Repository), information from vendors, and your managed services provider or IT staff.
As always, remember to document everything.
Threats: One important thing to note when starting your list of potential threats is that you are not required to list all potential threats. You must list all reasonably anticipated threats to ePHI. Having valuable sources of threat information is important, because you don’t want to waste time or resources on a threat that will never affect you, such as a hurricane if you’re nowhere near the ocean.
At this point you’re not looking at whether or not you’ve already mitigated the risk of such threats affecting ePHI. You’re only considering if it is a reasonably anticipated threat. And threats aren’t just about whether someone steals your data for misuse, but whether you can verify the integrity of your ePHI and have it available when you need it.
Vulnerabilities: When dealing with ePHI, it’s easy to think of vulnerabilities as technical problems. Non-technical vulnerabilities cannot be overlooked, and could even be the root problem to other perceived vulnerabilities. A lack of policies and procedures on how to securely set up new hardware or a budget that doesn’t meet the demand of current threats could lead to a number of technical vulnerabilities through misconfiguration of security settings or poor hardware purchasing. This is why a team is important for looking at both the big picture and the small details.
Step 6: Assessing Security Measures
Now that you have a complete list of threats and vulnerabilities, it’s time to see what security measures you already have in place to protect ePHI. Small- to medium-sized business have a greater degree of control over their environment, which is an advantage in mitigating risk. Like vulnerabilities, security measures can be both technical and non-technical, and should be looked at from all perspectives. When documenting, also identify that all technical security measures are not only there but also configured and utilized correctly.
Step 7: Determining Risk
In order to determine risk, it’s time to put the threats and vulnerabilities together to create a list of possible threat events. This is not a strictly one-to-one pairing. A single threat might affect multiple vulnerabilities, and a single vulnerability might be affected by multiple threats. (For more guidance on threat events, see Appendix E of SP 800-30.)
For each threat event, you must determine the likelihood of it occurring and the impact it would have on ePHI and your business if it did. Likelihood is the probability that a threat event will occur.
Below are examples (both qualitative and quantitative) of how you could determine likelihood and impact. Depending on your business’s risk tolerance, you might add more levels beyond high, medium, and low.
The impact of a threat event can be felt across different levels. The most obvious is the direct breach to ePHI’s confidentiality, integrity, and availability, but impact can also be felt in the loss of revenue from a damaged reputation, the cost of fixing the effects of the threat event, time and effort spent dealing with regulatory audits, and other intangible results. Below is an example of how you might measure impact.
Assessing Your Level of Risk
Accurate assessments of the above are vital to determining the overall level of risk posed by a threat event because risk is a combination of likelihood and impact. For example, if the impact is high but the likelihood is low, then the overall risk would be low. The clearer the definitions in the framework of what constitutes the levels of likelihood and impact, the more accurate and consistent your evaluations of threat will be. Threat matrices (such as those in Appendix I of SP 800-30) can be used for both qualitative and quantitative methodologies.
Step 8: Document and Manage Risk
If you’ve kept up with your documentation, the final SRA report should be simple to put together. Appendix K of SP 800-30 offers a base template for writing an SRA report, but you should tailor it to your business’ needs. In general, it should include all the lists you’ve made, as well as the reasons for your determinations and how you plan to use this information.
The final task of an SRA is to develop a risk management plan. HIPAA understands that risk cannot be wholly eliminated, but it should be reduced to reasonable and acceptable levels. Conducting an SRA and implementing a risk management plan become the foundation for implementing the rest of the Security Rule’s safeguards. In the next installment of our HIPAA series, we’ll look at how to use your SRA to create a risk management plan.
If you’d like the IT experts at Anderson Technologies to be a part of your risk analysis team, contact us today at 314.394.3001 or by email at info@andersontech.com.
