HIPAA Security Risk Assessment: A Consultant’s Guide

In our work with healthcare organizations, we’ve seen how a well-executed HIPAA Security Risk Assessment can prevent costly problems. We don’t just know…

Read More

Jim Hook, MPH

By Jim Hook, MPH | June 10, 2026

HIPAA Compliance Officer in suit seated at a table with wooden blocks falling. He inserts his hand and stops more form falling, simulating how a HIPAA security risk assessment can mitigate the risk.

In our work with healthcare organizations, we’ve seen how a well-executed HIPAA Security Risk Assessment can prevent costly problems. We don’t just know the rule—we’ve applied it in the field, and what follows is what we’ve learned. This post explains what the assessment entails, why it’s required, and when to update it. I’ll even share some of the scary things we’ve encountered in the trenches.

Why You Should Care About Your Security Risk Assessment

Here’s a quick two-question pop quiz:

  • How long have HIPAA Covered Entities (CEs) and Business Associates (BAs) been required to complete a HIPAA security risk assessment?
  • Has your Covered Entity/Business Associate organization recently completed a HIPAA security risk assessment?

You may not know the answer to Question #1. (It’s since 2003 for Covered Entities when the HIPAA Security Rule was first issued. And since 2010 for Business Associates when the HITECH Act was passed by Congress). But you should know the answer to Question #2. And if it’s “Never”, or “I don’t remember,” then this article is for you. 

Even if you do remember when you last went through the security risk assessment process, now there’s a third question:

  • Have there been any material changes to the systems or circumstances where or how you create, maintain or transmit electronic protected health information? if so, you too should pay attention to this post.

Why is a HIPAA Security Risk Assessment Required?

As we noted above, a HIPAA Security Risk Analysis (often called a security risk assessment) has been required since the HIPAA Security Rule was first issued. The requirement for this type of analysis comes from the Administrative Safeguards of the HIPAA Security Rule. One of the required four implementation specifications of the Security Management standard is to complete a security risk assessment. Unfortunately, this required implementation specification was for a long time one of the more frequently ignored provisions of the Security Rule.

A second source of requirements for a security risk assessment is the provisions of the Medicare Program’s Merit-based Incentive Program (MIPS). The 2025 Performance Requirements for Promoting Interoperability require participating Medicare providers to utilize Certified EHR Technology and to attest they are in compliance with the Security Risk Analysis measure of the MIPS performance measures.

Ready to take a closer look at your HIPAA compliance?

What are the elements of a HIPAA Security Risk Assessment?

As the term implies, the purpose of a security risk assessment is to assess the potential risks of loss or unauthorized disclosure of electronic protected health information (eHPI). An accurate and thorough assessment will help your organization identify potential threats to, and vulnerabilities of, health information technology, other information systems and their associated security risks. 

The major elements of a risk analysis include:

  • The scope of the risk analysis: This would include a description of the software applications that contain ePHI. CEs and BAs should keep in mind the myriad of applications and devices and multiple locations, where ePHI may be maintained. We recommend creating a list of software programs used within your organization. For each program, include a short description of the application and its function. Note whether it maintains or transmits ePHI, the devices it runs on, and the operational impact if the program became unavailable or data was lost.
  • Data Collection: In our assessments, we’ve often found that smaller organizations overlook mobile devices and cloud-based storage when listing where ePHI is stored. Your list should include external sources such as data centers or cloud servers where ePHI is stored. In our experience, many breaches involve lost or stolen laptops and other portable devices. These often contain reports with protected health information.
  • Potential Threats, Likelihood and Risk Levels: This element can be displayed in a matrix with threats (natural, environmental threats, intentional human threats, and unintentional human threats) on one axis. On the other, you can capture the likelihood, impact on confidentiality, integrity, or availability of data. This is an excellent way to document vulnerabilities.
  • Current Security Measures: Describe the current security measures in place to minimize the possibility of unauthorized physical or electronic access, damage, loss, or other interference with the organization’s premises or information. In our experience, these controls are often incomplete or outdated—especially when compared to what’s outlined in internal policies or procedures. 
  • Level of Risk: Risks of each threat occurrence can be assigned risk levels as low, medium or high. For instance, many threat elements to ePHI stored at a reputable data center may be assessed as Low. But a server with eHPI situated in an unlocked closet on the premises with the backup tapes stored in the same closet may constitute a medium or even high risk of loss or damage.

How often is a HIPAA Security Risk Assessment Required?

The HIPAA Security Rule doesn’t specify how often a security risk analysis must undergo periodic review. But in our experience, many organizations delay updates for years—even after major system or security changes. That kind of gap can expose them to unnecessary risk.

This risk management activity should be periodically reviewed for all applications containing ePHI. Updates are especially important when new applications are added, security measures are changed, or information technology is updated or replaced. In each case, organizations should also document the changes. Covered Entities and Business Associates must then update their related policies and procedures to reflect any changes required by the HIPAA Security Rule.

HIPAA Security Risk Assessment Lessons Learned

The description above is a bare-bones review of the several elements most CEs or BAs must address to achieve compliance with this requirement of the HIPAA Security Rule. In our work over the years providing many organizations with a HIPAA Gap Analysis, we have seen plenty of risky situations for healthcare providers that must be addressed in a security risk analysis.

A few examples of those risky situations we’ve witnessed include:

  • The server for a multi-state skilled nursing home chain kept in the basement of the founder’s 60- year-old residence;
  • Servers kept in unlocked closets with backup tapes kept on top of the server;
  • Software applications not updated for several security fixes;
  • Reports with ePHI downloaded to laptops with minimal or no security to access the laptop.

And the HIPAA Wall of Shame is replete with examples of lost laptops, failed firewalls and equipment or software applications left out of a HIPAA risk assessment. When the Office for Civil Rights (OCR) of the Health and Human Services Department (HHS) comes to audit your compliance with the Privacy and/or Security Rule, they don’t limit themselves to just the issue that prompted an audit. They look at every aspect of your HIPAA compliance, and then they calculate your fine. 

And don’t forget that attesting to something you haven’t done, e.g., to having performed a Security Risk Assessment as part of your attestations related to MIPS incentive payments, could be considered a false claim by Medicare. That can involve criminal penalties! 

In the long run and the short run, spending money on security measures is cheaper than paying fines!