Risk Assessment

HIPAA Part 4: Risky Business

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

(NIST 800-30)

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 an SRA?

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 an SRA

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 an SRA

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.

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.

SKY’s the Limit for Website Development

How Anderson Technologies Helped SKY Investment Group Reach a New Audience

Have you Googled yourself recently? If you own a business or oversee the marketing of one, an internet search is the first step in evaluating your company’s online presence. Social media marketing and web search optimization can be researched and learned. Functionality and ease-of-use must be tested and refined.

First impressions are everything. What does a potential customer or client see when they discover your company? This was the question Carol Bingham, Senior Administrator of SKY Investment Group, asked herself when deciding to give her organization’s online presence a makeover after thirteen years in operation.

Telling the Right Story

Creating an updated site is different than designing a site from scratch. Making sure the new design provides clear navigation and an elevated user experience not just for first-time visitors but also for existing clients is key. Our goal is always to guide users to what they’re looking for quickly and easily.”

The investment management company based in Hartford, Connecticut, hadn’t changed its website in over ten years. The site lacked functionality, making it a challenge to attract new clients. “No mobile capabilities, improperly marketed,” Bingham describes. Beyond that, the information presented on the site was out of date. Incomplete or languishing sites are an unintended sign to search engines and potential clients that a company is stagnant.

“Our business had changed in ten years,” says Bingham. “We became much more aware of who we are.” SKY’s site was created three years into the company’s growth, and the site’s content and organization still reflected its youth. This upgrade served as a rebranding opportunity. “Three years into existence, we tried to be everything to everybody,” Bingham says. The new site not only provides a better user experience for clients but also describes how SKY has changed as a company, allowing potential clients a laser-focused view of their investment options.

When Narrative Meets Creative Vision

Bingham had a personal connection to the Andersons and their established IT company, so naturally SKY reached out to Anderson Technologies when it was time for an overhaul. Director Farica Chang, who has spearheaded many web development projects for Anderson Technologies, took charge of redesigning SKY’s site to better suit its story.

“Creating an updated site is different than designing a site from scratch,” Chang explains. “Making sure the new design provides clear navigation and an elevated user experience not just for first-time visitors but also for existing clients is key. Our goal is always to guide users to what they’re looking for quickly and easily.”

Because SKY is a financial institution, marketing had to be handled delicately. The SEC strictly regulates how investment management companies advertise themselves—namely that they directly oppose the solicitation of clients. SKY’s appeal needed to dwell in conveying services honestly and directly, rather than with flowery filler words. “Carol was instrumental in making sure the presentation did not overstep the bounds of these regulations,” Chang says.

Goals for the new website included simplicity, readability, and neatness. Bingham wanted a crisp interface with “no frills.” SKY’s vision for the site included their contact information, directions to the company’s physical location, clear layout and navigation of available services, and a warm introduction to the team. Users needed to be attracted to SKY’s character and transparency—without a sales pitch.

I wanted to create a site that helped convey this warmth and trust.”

“During the discovery process, what immediately jumped out to me were the personal stories Carol and her husband Bob shared that illustrated how they go above and beyond to serve their clients,” Chang recalls. “I wanted to create a site that helped convey this warmth and trust.” This meant creative elements like colors, structure, and photographs were imperative. They planned a new site design featuring clean, bright layouts with generous white space and gentle curves.

Photos and fonts are important design elements, but communication is the biggest component of a website development project. “Building a website is a collaborative effort between the developer and the client,” Chang says. “We bring technical experience, but no one knows your business better than you.” Strong communication between Chang and Bingham resolved every problem that presented itself, and the Anderson team always took SKY’s needs and concerns seriously. “Member security is super important to us,” Bingham says. “Farica was amazing at finding the right platform.”

The Next Chapter

After SKY’s site face lift, Bingham knew the website could no longer be once-and-done without updates and attention paid to the big changes in the internet landscape. There are still a few markers Bingham would like to reach before the site feels complete.

Building a website is a collaborative effort between the developer and the client. We bring technical experience, but no one knows your business better than you.”

One of the most valuable tools in the internet marketing tool belt is search engine optimization (SEO). The internet and its search components are always changing. Refining the text on SKY’s site—such as updating new contact information and incorporating specific search keywords—and partnering with high-domain sites for backlinks are two methods the company plans to use to rise in the ranks.

In addition to maintaining the strict guidelines for financial institutions, new web policies also warrant changes to SKY’s previous web approach. Because SKY’s clients can potentially access the site from the EU, they need to become compliant with the new GDPR law. That update is something Anderson Technologies’ web development team has implemented on many sites – including our own. Integrating a cookie consent bar and new Google analytics settings not only brings the site up to GDPR compliance but also provides a more accurate record of who accesses the site.

Though SKY Investment Group still has many design ideas to incorporate in the future, their new site tells their company’s story much more successfully. It leaves room to grow, too—and the Anderson Technologies team will be ready to take on the challenge when that time comes.

Does your website need an update? Is your web presence lackluster and preventing customers from learning what you offer? Anderson Technologies can evaluate where your company might benefit from design and marketing help. For a free consultation, call 314.394.3001 or visit our site today!