The Complete Guide to HIPAA Risk Assessments

> TL;DR: A HIPAA risk assessment is a documented analysis of threats to electronic protected health information, the likelihood and impact of each threat, and the safeguards in place to address them. It is required under 45 CFR 164.308(a)(1)(ii)(A), and failing to conduct a thorough one is the most-cited deficiency in OCR enforcement actions. This guide walks through the full methodology — scope, threats, vulnerabilities, likelihood, impact, and documentation — plus how modern compliance platforms automate the heavy lifting.

A HIPAA risk assessment is a systematic evaluation required under the HIPAA Security Rule (45 CFR 164.308(a)(1)(ii)(A)) in which covered entities and business associates identify threats and vulnerabilities to electronic protected health information (ePHI), evaluate the likelihood and impact of potential breaches, and document findings to guide their security programs. Failing to conduct and document a thorough risk assessment is the single most-cited deficiency in OCR enforcement actions and has resulted in millions of dollars in penalties.

If you work in healthcare compliance, you have heard the phrase "risk assessment" hundreds of times. You have probably also seen it reduced to a yearly checkbox, a spreadsheet someone fills out in December, or a task that gets passed around until someone with enough patience finally handles it.

That approach is exactly what gets organizations fined.

The HIPAA Security Rule, codified at 45 CFR 164.308(a)(1)(ii)(A), requires covered entities and business associates to "conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate." There is no ambiguity here. This is not optional, and it is not something you can fake your way through.

Between 2016 and 2023, the Office for Civil Rights (OCR) at the U.S. Department of Health and Human Services levied tens of millions of dollars in penalties tied directly to failures in risk analysis (Source: HHS OCR Enforcement Highlights, 2016-2023). Many of those enforcement actions did not involve dramatic data breaches. They involved organizations that simply could not produce evidence of a thorough, documented risk assessment.

This guide walks through what a HIPAA risk assessment actually involves, how to execute one properly, and the mistakes that trip up even well-intentioned compliance teams.

Risk Analysis vs. Risk Management: Two Separate Requirements

Before getting into the step-by-step process, a common source of confusion needs to be addressed. The Security Rule contains two distinct implementation specifications under the Administrative Safeguards:

Risk Analysis (45 CFR 164.308(a)(1)(ii)(A)) is the process of identifying where ePHI lives, what could threaten it, and how likely and damaging those threats are.

Risk Management (45 CFR 164.308(a)(1)(ii)(B)) is the process of implementing security measures that reduce those identified risks to a reasonable and appropriate level.

These are sequential. You cannot manage risk you have not identified. Yet OCR investigations frequently reveal that organizations jumped straight to buying security tools or writing policies without first analyzing what they were actually protecting against. The tools may be excellent. The policies may be well-written. But without a documented risk analysis as the foundation, there is no way to demonstrate that your security program is tailored to your specific risks.

Think of it this way: risk analysis is the diagnosis, and risk management is the treatment plan. No physician prescribes medication before examining the patient.

The Step-by-Step Process

The following framework aligns with guidance published by OCR and the National Institute of Standards and Technology (NIST), specifically NIST SP 800-30, which OCR has repeatedly referenced in its guidance documents.

Step 1: Define the Scope

Your risk assessment must account for all electronic protected health information (ePHI) that your organization creates, receives, maintains, or transmits. All of it. Not just the data in your EHR. Not just the data in your primary data center.

This means identifying ePHI in:

• Electronic health record systems
• Practice management software
• Billing and claims systems
• Email (including archived messages containing patient information)
• Cloud storage services (Google Drive, Dropbox, OneDrive, Box)
• Mobile devices used by staff (phones, tablets, laptops)
• Medical devices that store or transmit patient data
• Paper-to-digital workflows (scanned documents, faxes received electronically)
• Backup systems and disaster recovery environments
• Legacy systems that may still be connected to your network

One of the most common failures OCR identifies is an incomplete scope. If your risk assessment only covers your EHR and ignores the fact that physicians are texting patient information or that your billing vendor has access to ePHI, you have an incomplete assessment. OCR will treat that as a deficiency.

Step 2: Identify Threats

A threat is anything that could exploit a vulnerability and cause harm to ePHI. Threats generally fall into three categories:

Natural threats include floods, earthquakes, tornadoes, hurricanes, and power outages caused by weather events. If your servers sit in a basement in a flood-prone area, that is a threat worth documenting.

Human threats can be intentional or unintentional. Intentional threats include hackers, disgruntled employees, and social engineering attacks. Unintentional threats include an employee accidentally emailing a patient list to the wrong recipient, a staff member losing an unencrypted laptop, or someone falling for a phishing email.

Environmental threats include HVAC failures, power surges, water pipe bursts, and hardware failures.

Do not limit yourself to dramatic scenarios. The breach that triggers an OCR investigation is more likely to be a lost laptop than a sophisticated nation-state attack. According to the HHS Breach Portal, lost or stolen devices and unauthorized access/disclosure remain among the most frequently reported breach categories year after year (Source: HHS Breach Portal, 2025 data).

Step 3: Identify Vulnerabilities

A vulnerability is a weakness that a threat could exploit. For each system or location where ePHI exists, ask: what is weak here?

Examples of vulnerabilities include:

• Lack of encryption on portable devices
• Weak or shared passwords
• Absence of multi-factor authentication
• Unpatched software or operating systems
• Insufficient access controls (staff members with access to ePHI they do not need for their job)
• No audit logging or log review process
• Lack of physical security controls (unlocked server rooms, unattended workstations)
• Missing or outdated data backup procedures
• Inadequate workforce training on security practices
• No formal process for revoking access when employees leave

Vulnerability identification is where technical assessments like penetration testing, vulnerability scanning, and configuration reviews become valuable. These are not required by the Security Rule in those specific terms, but they produce the kind of evidence that demonstrates a thorough analysis.

Step 4: Assess Current Controls

Before determining risk levels, document the security measures you already have in place. This step matters because a vulnerability with strong compensating controls carries less risk than the same vulnerability with no controls.

For each vulnerability, note what safeguards exist. Do you have encryption enabled on laptops? Is there an access control policy? Are audit logs being reviewed? Is workforce training conducted and documented?

Be honest during this step. Listing a control that exists on paper but is not enforced in practice will not help you. If your policy says passwords must be changed every 90 days but your systems do not enforce that requirement, you do not have an effective control.

Step 5: Determine Likelihood

For each threat-vulnerability combination, estimate how likely it is that the threat will actually exploit the vulnerability given your current controls. Most organizations use a three-level or five-level scale:

• High: The threat source is highly motivated and capable, the vulnerability is easy to exploit, and current controls are weak or absent.
• Medium: The threat source exists and the vulnerability could be exploited, but current controls provide some protection.
• Low: The threat source lacks motivation or capability, the vulnerability is difficult to exploit, or current controls are strong.

This does not need to be a precise mathematical calculation. OCR does not expect actuarial-grade probability estimates. It expects a reasoned, documented judgment based on the evidence available to you.

Step 6: Determine Impact

For each threat-vulnerability combination, estimate the impact to the organization if the threat successfully exploited the vulnerability. Consider:

• How many patient records could be affected?
• What types of information could be exposed (demographics, diagnoses, Social Security numbers, financial data)?
• Would the organization lose access to critical systems?
• What would the financial cost be (breach notification, OCR penalties, lawsuits, remediation)?
• Would patient safety be affected?
• What would the reputational damage look like?

Again, use a consistent scale (high, medium, low) and document your reasoning.

Step 7: Assign Risk Levels

Combine your likelihood and impact ratings to produce an overall risk level for each threat-vulnerability pair. A simple risk matrix works:

| | Low Impact | Medium Impact | High Impact | |---|---|---|---| | High Likelihood | Medium Risk | High Risk | Critical Risk | | Medium Likelihood | Low Risk | Medium Risk | High Risk | | Low Likelihood | Low Risk | Low Risk | Medium Risk |

The specific matrix you use matters less than applying it consistently and documenting it clearly.

Step 8: Document Everything

This step is not really a step. It is something that should be happening throughout the entire process. But it gets its own section because documentation failures are the single most common deficiency OCR finds in risk assessments.

Your documentation should include:

• The date the assessment was conducted and who was involved
• The scope of the assessment (all systems and locations where ePHI was identified)
• The methodology used
• Each identified threat and vulnerability
• Current security controls in place
• Likelihood and impact ratings with supporting rationale
• Resulting risk levels
• Recommended actions to address identified risks (this bridges into risk management)

If it is not documented, it did not happen. That statement is not hyperbole. In every enforcement action where OCR has cited risk analysis failures, the core problem was either that no analysis was done or that no documentation existed to prove one was done.

How Often Should You Conduct a Risk Assessment?

The Security Rule does not specify a frequency. It does not say annually, quarterly, or biannually. What it says, and what OCR has reinforced in guidance documents, is that risk analysis should be an "ongoing" process.

In practice, this means you should:

• Conduct a comprehensive, baseline risk assessment if you have never done one (or if your last one was superficial)
• Review and update the assessment whenever significant changes occur in your environment (new systems, new facilities, organizational changes, new business associate relationships)
• Conduct a full reassessment at least annually, even if no major changes have occurred
• Review and update the assessment after any security incident or breach

The "annual" expectation has become standard practice in the industry, and OCR has indicated in settlement agreements and guidance that annual reviews are reasonable. But "annual" does not mean "only annual." If you deploy a new EHR system in June, you should not wait until December to assess the risks associated with that system.

Common Mistakes That Lead to OCR Enforcement Actions

Treating It as a Checkbox

The most damaging mistake is treating the risk assessment as a compliance formality rather than a genuine security exercise. Organizations that approach it this way tend to produce thin, generic documents that list risks like "hacking" without analyzing specific threats to their specific environment. OCR sees through this immediately.

Failing to Include All ePHI Locations

Your assessment must cover every place ePHI lives or moves. If your organization uses a cloud-based EHR, a separate billing platform, email, a patient portal, and staff members carry smartphones with access to patient data, every one of those locations must be in scope. Missing even one can be cited as an incomplete risk analysis.

Not Documenting the Analysis

Some organizations actually do think through their risks carefully. They have conversations, they make decisions, they implement security measures. But they never write any of it down. When OCR asks for documentation, they have nothing to produce. Verbal risk assessments do not satisfy the Security Rule.

Confusing a Security Questionnaire with a Risk Assessment

Filling out a vendor's security questionnaire or completing a checklist is not the same as conducting a risk assessment. Those tools can inform a risk assessment, but they are not substitutes for the threat-vulnerability-likelihood-impact analysis the Security Rule requires.

Ignoring the Risk Management Follow-Through

Identifying risks and then doing nothing about them may actually be worse than not conducting the assessment at all. It demonstrates that you knew about vulnerabilities and chose not to address them. Your risk assessment should directly feed into a risk management plan with assigned owners, timelines, and documented remediation activities.

The HHS Security Risk Assessment Tool

HHS, in collaboration with the Office of the National Coordinator for Health Information Technology (ONC), developed a free Security Risk Assessment (SRA) Tool designed to help small and medium-sized healthcare practices conduct risk assessments. The tool walks users through the process using a question-and-answer format aligned with NIST standards.

The SRA Tool is available for download at healthit.gov. While it was designed with smaller practices in mind, the methodology is sound for organizations of any size. Larger organizations may find that they need more robust tooling to manage the complexity of their environments, but the SRA Tool provides a solid starting point and demonstrates what OCR considers a reasonable approach.

One important caveat: simply downloading and filling out the SRA Tool does not automatically mean your risk assessment is adequate. The quality of the output depends entirely on the accuracy and thoroughness of the information you provide. Garbage in, garbage out.

What Happens When OCR Investigates

When OCR opens an investigation, whether triggered by a breach report, a complaint, or a compliance audit, the risk assessment is almost always one of the first documents they request. They want to see:

1. That you conducted one
2. That it was thorough and covered your full ePHI environment
3. That it was reasonably current
4. That you acted on the findings

The penalties for failure can be severe. Under the HIPAA enforcement framework, civil monetary penalties range from $141 per violation (where the entity did not know and could not reasonably have known) up to $2,134,831 per violation for willful neglect that is not corrected (Source: HHS OCR, 45 CFR 160.404, inflation-adjusted penalty amounts). These figures are adjusted periodically for inflation. In 2023, OCR settled with a health system for $1.3 million in a case where failure to conduct an adequate risk analysis was a central finding (Source: HHS OCR Resolution Agreements, 2023).

Beyond financial penalties, OCR typically imposes corrective action plans that require the organization to conduct a compliant risk assessment under OCR oversight, implement a risk management plan, provide workforce training, and submit to monitoring for one to three years.

Key Takeaways

• A HIPAA risk assessment is a mandatory requirement under 45 CFR 164.308(a)(1)(ii)(A) for all covered entities and business associates, regardless of size.
• Risk analysis (identifying threats) and risk management (mitigating threats) are two separate requirements under the Security Rule and must be addressed sequentially.
• The scope of your risk assessment must include every system, device, and location where ePHI is created, received, maintained, or transmitted, not just your EHR.
• Documentation is critical. If you cannot produce evidence of a thorough, current risk assessment, OCR will treat it as if one was never conducted.
• Risk assessments should be treated as ongoing processes, with a full reassessment at least annually and additional reviews whenever your environment changes.
• HHS offers a free Security Risk Assessment (SRA) Tool at healthit.gov that provides a solid framework aligned with NIST standards.

Frequently Asked Questions

How often do I need to conduct a HIPAA risk assessment?

The HIPAA Security Rule does not specify an exact frequency, but OCR guidance and industry best practice establish that risk assessments should be conducted at least annually. You should also update your assessment whenever significant changes occur, such as deploying new systems, adding business associate relationships, or experiencing a security incident (Source: HHS OCR, 45 CFR 164.308).

Can I conduct a HIPAA risk assessment myself, or do I need to hire a consultant?

You can conduct a risk assessment internally if your team has sufficient knowledge of your systems, security practices, and HIPAA requirements. The Security Rule does not require external consultants. However, external assessors bring objectivity and specialized expertise that can be valuable, especially for first-time assessments or complex environments. The key factor OCR evaluates is competence and thoroughness, not whether the assessor is internal or external.

What tool does HHS recommend for HIPAA risk assessments?

HHS, in collaboration with the Office of the National Coordinator for Health IT (ONC), developed a free Security Risk Assessment (SRA) Tool available for download at healthit.gov. It uses a question-and-answer format aligned with NIST SP 800-30 standards and is designed primarily for small and medium-sized practices, though the methodology applies to organizations of any size.

What happens if I skip the HIPAA risk assessment?

Failing to conduct a risk assessment is the most frequently cited deficiency in OCR enforcement actions. Penalties range from $141 to $2,134,831 per violation depending on the level of negligence (Source: HHS OCR, 45 CFR 160.404). Beyond fines, OCR typically imposes corrective action plans requiring the organization to conduct a compliant assessment under oversight and submit to monitoring for one to three years.

What is the difference between a HIPAA risk assessment and a gap analysis?

A risk assessment evaluates specific threats and vulnerabilities to determine the likelihood and impact of harm to ePHI, producing risk ratings that prioritize remediation. A gap analysis compares your current security practices against a set of requirements and identifies where you fall short. Both are useful, but only the risk assessment is explicitly required by the HIPAA Security Rule.

Take the Guesswork Out of Your Next Risk Assessment

Conducting a thorough, well-documented HIPAA risk assessment does not have to mean weeks of manual work and spreadsheets. Live Compliance provides guided risk assessment tools, automated documentation, and ongoing monitoring that help healthcare organizations build and maintain a defensible compliance program. Whether you are starting from scratch or need to bring an outdated assessment up to current standards, Live Compliance can help you get there efficiently and keep you there year-round.