HIPAA Security Risk Assessment: What It Covers and How Often to Run One

Every healthcare organization that handles electronic protected health information is legally required to conduct a HIPAA security risk assessment. This isn’t a suggestion buried in compliance guidance. It’s a written requirement under 45 CFR 164.308(a)(1)(ii)(A), and the Office for Civil Rights has made enforcing it a stated priority.

The requirement has been on the books since 2003, yet OCR’s enforcement data makes clear that a large share of covered entities and business associates have either never done a proper risk assessment or haven’t kept it current. The settlements from OCR’s Risk Analysis Initiative, fourteen of them through June 2026, most involving ransomware, share a common thread: organizations suffered a breach and then couldn’t demonstrate they had assessed the risk in the first place.

This article explains what a HIPAA security risk assessment actually covers, how HHS defines the required elements, how often you need to run one under current rules and what’s changing, and what organizations most commonly get wrong.

TL;DR

A HIPAA security risk assessment (also called a risk analysis) is a formal, documented process for identifying where electronic protected health information lives across your organization, cataloging the threats and vulnerabilities that could affect it, and assigning risk levels that drive your security program. The requirement sits in the HIPAA Security Rule at 45 CFR 164.308(a)(1)(ii)(A). HHS describes the required elements across 9 areas: scope, data collection, identifying threats and vulnerabilities, assessing current security measures, determining likelihood, determining impact, determining risk level, finalizing documentation, and periodic review. Current rules don’t prescribe a specific interval. They call it an “ongoing” process that triggers on significant operational changes. A proposed update published by HHS on December 27, 2024 would change that by mandating a full review at least every 12 months. Common failure points include incomplete ePHI scoping, generic risk ratings without supporting rationale, and treating a business associate agreement as a substitute for evaluating the vendor’s actual controls.

What the HIPAA security risk assessment actually is

A HIPAA security risk assessment is a structured analysis of every location where your organization creates, receives, maintains, or transmits ePHI, and of every realistic threat that could compromise the confidentiality, integrity, or availability of that data. The term “risk analysis” appears in the regulatory text; “risk assessment” is widely used in practice to mean the same thing.

The legal source is 45 CFR 164.308(a)(1), which is part of the Administrative Safeguards section of the HIPAA Security Rule. The implementation specification at 164.308(a)(1)(ii)(A) requires covered entities 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.”

Three words in that sentence carry most of the weight. “Accurate” means your scope must reflect what’s actually in your environment, not what you think is there or what you wish were there. “Thorough” means every system touching ePHI must be included. “Assessment” means this must be an analytical exercise with documented findings, not a self-attestation or a questionnaire you checked off.

Business associates have the same obligation under the Security Rule. Since the HITECH Act extended Security Rule requirements to business associates directly, any vendor that handles ePHI on behalf of a covered entity must also conduct its own risk assessment. A business associate agreement is a contract. It doesn’t substitute for the vendor actually understanding and managing its own ePHI risks.

The HIPAA Security Rule text at HHS makes clear that the risk analysis is the foundational step for the entire security program. Everything else in the Security Rule is built on knowing what your risks are.

Why this assessment is the foundation of HIPAA compliance

Most of the Security Rule’s required and addressable safeguards reference the risk analysis either directly or implicitly. You can’t make reasonable and appropriate choices about which security measures to implement without first knowing what you’re protecting, where it lives, and what could go wrong.

OCR has described the risk analysis as “the first step in identifying and implementing safeguards that comply with and carry out the standards and implementation specifications in the Security Rule.” That language appears in the official guidance document HHS published to walk organizations through the process.

This matters practically because the Security Rule is built around flexibility. Unlike the Privacy Rule, which specifies many required practices in detail, the Security Rule uses a scalability framework. Organizations choose safeguards based on size, complexity, and the results of their risk analysis. A 3-person medical practice and a regional health system face different risks and have different resources. The Security Rule accommodates that. But it only accommodates it if you’ve actually done the analysis.

Without a current risk analysis, you can’t justify your security decisions. You can’t explain why you chose not to encrypt a particular data store or why you haven’t implemented a specific control. OCR examiners know this, which is why the risk analysis is almost always the first thing they ask about during an investigation.

Core elements HHS expects in a HIPAA risk analysis

HHS published guidance that identifies what an accurate and thorough risk analysis must incorporate. HHS does not prescribe a single required method or number these as official steps. Instead, it describes 9 elements that every risk analysis must address regardless of the approach taken.

Scope of the analysis

The analysis must cover all ePHI your organization creates, receives, maintains, or transmits, regardless of the medium or location. This includes on-premises systems, cloud platforms, portable devices, home offices, acquired practices not yet fully integrated, and any vendor-hosted system through which your ePHI flows. Most organizations discover during this element that their ePHI footprint is larger than their IT department believed.

HHS OCR guidance emphasizes that scope must cover all ePHI regardless of the medium it’s stored on or where it’s physically located. Shadow IT and vendor systems assumed to be someone else’s compliance problem are common sources of undocumented ePHI.

Data collection

Document every system, application, device, and location where ePHI is created, received, maintained, or transmitted. This includes cloud services, portable media, fax machines, legacy applications, and third-party platforms. The data collection phase produces the ePHI inventory that anchors everything else in the analysis.

Identify and document threats and vulnerabilities

A threat is anything that could exploit a vulnerability to harm ePHI. Threats can be environmental (flood, fire, power outage), human (insider error, external attacker, disgruntled employee), or technical (software failure, misconfiguration). Vulnerabilities are weaknesses in your systems or processes that make a threat more likely to succeed.

The regulatory standard is “reasonably anticipated” threats, not every theoretical possibility, but threats that are realistic given your environment, your geography, and the type of data you hold.

Assess current security measures

Catalog what controls you already have in place: firewalls, encryption, MFA, access controls, audit logging, workforce training, backup procedures, and so on. The goal isn’t to list them as a credential. It’s to evaluate whether each control is actually working and whether it’s properly configured.

A firewall that exists on paper but hasn’t been reviewed in 3 years, or MFA that’s deployed only for some users, doesn’t fully offset the vulnerability it was meant to address. This element requires honest evaluation, not box-checking.

Determine the likelihood of threat occurrence

For each identified threat/vulnerability combination, assign a likelihood rating, typically high, medium, or low, based on how probable it is that the threat will exploit the vulnerability given your current controls. This rating must be supported by documented reasoning, not assigned arbitrarily.

Determine the potential impact of threat occurrence

If a threat did successfully exploit a vulnerability, what would happen? Consider the volume of ePHI at risk, whether the affected data could be recovered, the potential for harm to patients, and the operational impact on your organization.

Determine the level of risk

Combine the likelihood and impact assessments into a risk level for each identified risk. The risk level determines how urgently a particular finding needs to be addressed in your risk management plan.

Finalize documentation

No specific format is required. HHS says the documentation must be in writing (which includes electronic format) and must be retained for 6 years. The documentation feeds your risk management plan, the separate required process for implementing safeguards to address identified risks. The HHS Security Risk Assessment guidance covers each element in detail and is the primary reference for understanding what OCR expects to see.

Periodic review and updates

The risk analysis is not a one-time event. HHS explicitly identifies periodic review and updates as a required element. The analysis must be kept current as your environment, operations, and threat landscape change. This element is why the risk analysis is described as an ongoing process rather than a project.

What the assessment must cover: administrative, physical, and technical safeguards

The HIPAA security risk assessment isn’t limited to IT systems. It covers all 3 safeguard categories in the Security Rule: administrative, physical, and technical.

Administrative safeguards include your security policies and procedures, workforce training program, sanction policies for violations, contingency planning, and how you manage business associate relationships. This is the governance layer, the written decisions and processes that shape how your organization handles ePHI day to day.

Physical safeguards cover facility access controls, workstation security policies, device and media controls, and how portable devices are managed. A laptop used by a home health worker, a shared workstation in a nursing station, and a server room with visitor access logs all fall under physical safeguards.

Technical safeguards include access controls (who can access which ePHI), audit controls (logs showing who accessed what and when), integrity controls (preventing improper alteration or destruction), authentication mechanisms, and transmission security. MFA, encryption at rest, encryption in transit, role-based access control, and session timeout policies are all technical safeguard topics.

Every system that touches ePHI must be evaluated across all 3 categories. This includes Active Directory and identity management, email platforms, EHR and practice management systems, telehealth tools, backup and recovery systems, network infrastructure, and any mobile device management configuration. Systems assumed to be someone else’s problem, such as vendor-hosted platforms, cloud services, or clearinghouses, still count if your organization’s ePHI flows through them.

Business associate risk: what your BAA doesn’t cover

A business associate agreement defines the legal obligations of a vendor that handles ePHI on your behalf. It doesn’t tell you whether that vendor has adequate security controls in place.

The distinction matters because covered entities must account for the risks associated with ePHI handled by their business associates and meet their own BAA obligations. Business associates are directly liable for applicable HIPAA Security Rule requirements. HHS clarifies in its business associate guidance that these are separate but parallel obligations.

The proposed HIPAA Security Rule update published by HHS on December 27, 2024 would add an explicit implementation specification requiring covered entities to assess risks from entering into or continuing business associate relationships. Under the proposed requirement, this assessment would need to include written verification from the business associate about the controls it has in place.

Even under current rules, evaluating your business associates is part of a thorough risk analysis. When assessing a business associate, you need to know what type and volume of ePHI they handle, where they store it and whether it’s encrypted, whether they use subcontractors and what those subcontractors’ obligations are, what their breach notification timeline is, and what their own security controls and assessment practices look like.

HHS guidance on business associate contracts provides the contract framework, but your risk analysis needs to go further than the contract itself. Asking a vendor to sign a BAA is not the same as evaluating their security posture.

How often you need to run a HIPAA security risk assessment

The current HIPAA Security Rule doesn’t specify a fixed interval. It calls the risk analysis an “ongoing” process, which means it must be kept current and updated when significant changes occur in your environment.

HHS and OCR have consistently described the triggers that require reassessment:

●  A security incident or breach that reveals a previously unidentified vulnerability

●  Significant changes to your IT environment, including new systems, new platforms, or major upgrades

●  Organizational changes such as mergers, acquisitions, or practice consolidations

●  Changes in key personnel in security or privacy roles

●  New regulatory guidance or significant changes in the threat landscape

Many compliance professionals interpret “ongoing” to mean an annual review at minimum, combined with more immediate updates when triggers occur. This interpretation is reinforced by what OCR looks for during investigations. Organizations that can show a documented annual review with interim updates for significant changes are in a much stronger position than those who treat the assessment as a one-time event.

The practical risk of treating the assessment as a one-time or infrequent exercise is clear in OCR’s enforcement record. Organizations cited in Risk Analysis Initiative settlements frequently couldn’t produce evidence of any recent assessment.

What the proposed rule would change

On December 27, 2024, HHS published a proposed update to the HIPAA Security Rule. The proposed rule, which has not yet been finalized and which the current Security Rule remains in force while under review, would add an explicit frequency requirement: a full risk analysis review at least every 12 months. It would also restructure the current risk analysis standard into 8 specific implementation specifications, turning several currently implied requirements into explicit written obligations.

The HHS Security Rule NPRM fact sheet describes the 8 proposed specifications in detail, including the new business associate verification requirement. Even though the rule hasn’t been finalized, the direction is clear: annual reviews will likely become a hard requirement, and the documentation burden will increase.

The 8 proposed implementation specifications

The proposed rule would replace the current single implementation specification for risk analysis with 8 distinct specifications. Organizations preparing for this change can use these as a planning framework now.

The 8th specification, business associate risk, is the most significant addition to current practice. Under the proposed rule, verbal or informal assurances from vendors won’t satisfy this requirement. Written documentation will be required.

OCR’s Risk Analysis Initiative and what it’s found

In 2023, OCR launched the Risk Analysis Initiative, a targeted enforcement effort focused specifically on organizations that couldn’t demonstrate they had conducted an adequate risk analysis. Through June 2026, the initiative had produced 14 enforcement actions, with penalties ranging from $10,000 to $450,000.

Several patterns appear across these cases. The majority involve ransomware incidents, breaches that encrypted or exposed ePHI. In each case, OCR found that the organization either had no risk analysis or had one that was so outdated or incomplete that it failed to identify the vulnerabilities the attackers exploited.

The $450,000 settlement with Spencer Gifts LLC Flexible Benefits and Welfare Benefit Plans, announced June 18, 2026, became the largest in the initiative. The $350,000 settlement with Northeast Radiology involved unauthorized access to a picture archiving and communication system. The $227,816 settlement with Health Fitness Corporation resulted from a server misconfiguration that left ePHI exposed. A $600,000 settlement with a California health care network, concurrent with the initiative though not formally part of it, involved both a phishing-related breach and a failure to conduct an adequate risk analysis.

The OCR Risk Analysis Initiative page tracks settlements as they’re announced and provides resolution agreement documents that detail what each organization failed to do. Reading these is useful for understanding what ‘adequate’ looks like in OCR’s enforcement view.

The cases make clear that OCR isn’t waiting for large-scale breaches to investigate risk analysis failures. Settlements as small as $10,000 (Northeast Surgical Group) and $25,000 (Comprehensive Neurology, Guam Memorial Hospital Authority) show the agency is willing to pursue smaller covered entities.

Common gaps OCR investigators find

Based on enforcement cases and compliance guidance, several failure patterns recur across organizations of all sizes.

Incomplete scope. The most common issue is a risk analysis that doesn’t account for all ePHI locations. Legacy systems, recently acquired practices, vendor platforms, and devices used by remote workers are regularly missing. If your ePHI inventory doesn’t reflect your actual environment, everything downstream is built on a false foundation.

Generic risk ratings. Assigning “medium” to a risk without explaining why it’s medium, what specific threat, what vulnerability, what current control offsets it partially, doesn’t satisfy the “accurate and thorough” standard. OCR wants to see documented reasoning, not a rating label.

Documenting risks without acting on them. A risk analysis that identifies 40 findings but shows no evidence those findings were addressed in a risk management plan signals that the analysis was a compliance exercise rather than a security exercise.

Treating controls as fully implemented when they’re partial. MFA deployed for 60% of users, encryption applied to some file shares but not others, and access controls configured correctly in the EHR but not in the data warehouse are common examples. Partial controls should be documented as partial, with the residual risk clearly noted.

Using the SRA Tool as the complete answer. HHS and ONC jointly offer the Security Risk Assessment Tool, a free resource that helps organizations structure their analysis. The tool is useful for small practices, but its own documentation notes that the survey alone may not identify all risks in an organization, and HHS has stated that using the tool does not guarantee HIPAA compliance.

Treating the BAA as the vendor evaluation. Covered entities regularly assume that a signed BAA means a vendor has adequate security. It doesn’t. The BAA creates obligations. It doesn’t verify that the vendor has fulfilled them.

Never testing backups or incident response procedures. The risk analysis should assess whether your contingency controls would actually work. An untested backup is a backup you don’t know works.

The HHS SRA Tool: what it does and where it falls short

The Security Risk Assessment Tool, developed jointly by ONC and HHS OCR, is the most widely used free resource for conducting a HIPAA security risk assessment. Version 3.7, the current release as of September 2026, is available as a Windows desktop application for 64-bit Windows 7 through 11, and as an Excel workbook usable on any system with Excel or compatible software. The iPad version is no longer listed on HealthIT.gov. The tool covers the requirements under 45 CFR 164.308, 164.310, and 164.312.

The v3.7 update added an assessment-scope question, a remote access and telework question, and explicit review triggers for updating assessments. The Windows application includes asset and vendor management capabilities, which means the tool now provides more structure for tracking technology assets and vendor relationships than earlier versions.

For small and medium practices doing a risk analysis for the first time, it provides useful structure. Its limitations are real, though. HHS acknowledges that the survey alone may not identify all risks in an organization, and the tool is informational only. It doesn’t produce a risk register with assigned owners and due dates, doesn’t generate policy documents, doesn’t compare results year over year, and may not suit larger or more complex organizations.

Paid risk assessment platforms address these gaps by adding risk registers with remediation tracking, vendor and BAA tracking integrated with the analysis, policy libraries, multi-site support, and prior-year comparison reporting. For organizations that need to demonstrate ongoing risk management rather than a one-time analysis, these capabilities matter.

The choice between the free tool and a paid platform should be driven by your organization’s complexity, the number of systems and vendors involved, and how you need to document and track remediation over time.

What a HIPAA security risk assessment is not

Part of what makes compliance difficult is that organizations often substitute something adjacent for the actual risk analysis. Understanding what doesn’t count helps clarify what does.

A vulnerability scan tests your network and systems for known security weaknesses. It’s a useful technical tool, but it covers only the technical attack surface. It doesn’t address administrative or physical safeguards, and it doesn’t produce the likelihood and impact analysis the risk analysis requires.

A penetration test attempts to exploit vulnerabilities to demonstrate what an attacker could do. It’s even more narrowly technical. Pen test findings feed into a risk analysis, but the pen test itself isn’t the analysis.

A SOC 2 report from a cloud vendor or SaaS provider describes that vendor’s controls as of a specific audit date. It’s useful evidence in your vendor evaluation, but it’s their assessment, not yours. It doesn’t address your broader ePHI environment and it doesn’t replace your obligation to conduct your own analysis.

A HIPAA gap assessment identifies where your current policies and practices fall short of specific regulatory requirements. It’s a compliance tool, not a security risk tool, and it typically doesn’t produce the threat/vulnerability/likelihood/impact documentation the risk analysis requires.

Security awareness training addresses human behavior and helps reduce risk. It’s a required administrative safeguard. It’s not a substitute for the analysis itself.

Each of these tools and assessments has a role in your security program. None of them satisfy the risk analysis requirement on its own.

How to maintain your risk analysis between full assessments

A completed risk analysis isn’t a static document. Even without the proposed annual requirement in place, organizations need processes to keep the analysis current between full reviews.

Track your ePHI environment continuously. When new systems are added, new vendors are onboarded, or staff begin using a new platform or device, those changes should trigger an update to your ePHI inventory. Many organizations connect this to their change management process. Any change that could affect ePHI flows gets flagged for risk review.

Connect your risk register to your remediation tracking. Each identified risk should have a documented status: open, in remediation, mitigated, or accepted (with documented approval for acceptance). Reviewing this register quarterly lets you confirm that identified risks are being addressed and that new risks from operational changes are being captured.

Document trigger events and your response to them. When an incident occurs, when a key system changes, or when a vendor relationship changes, document what the trigger was and what review you conducted. This creates the audit trail that shows your risk analysis is ongoing rather than point-in-time.

Plan for the proposed annual requirement now. Even though the proposed rule hasn’t been finalized, moving toward an annual full review is a reasonable and defensible compliance posture. Organizations that already conduct annual reviews are in a better position regardless of when or whether the proposed rule takes effect.

The National Institute of Standards and Technology guidance on healthcare cybersecurity provides frameworks that many organizations use alongside HIPAA requirements to structure both their risk assessments and their ongoing risk management programs.

Documentation requirements and retention

The HIPAA Security Rule requires that the risk analysis be in writing and that documentation be retained for 6 years from the date of creation or the date it was last in effect, whichever is later. This retention requirement applies to all Security Rule documentation, not just the risk analysis itself.

No specific format is required. HHS has explicitly stated that format flexibility is intentional. Organizations vary too much in size and complexity for a single prescribed format to make sense. What matters is that the documentation is accurate, thorough, and reviewable.

In practice, risk analysis documentation typically includes an ePHI inventory or data flow diagram, a list of identified threats and vulnerabilities with their sources, documentation of current controls and their effectiveness, the likelihood and impact ratings with supporting rationale, the resulting risk level assignments, and an indication of what actions are planned in response to each identified risk.

OCR doesn’t prescribe what this looks like in a file or application, but investigators will look for evidence of a genuine analytical process. A document that lists risks without any supporting reasoning, or that identifies no findings in a complex environment, is unlikely to satisfy the ‘accurate and thorough’ standard.

Putting it together: building a risk assessment that holds up

The organizations that do this well share a few common practices. They treat the risk analysis as a living program rather than a project. They connect their risk findings to actual security investments and remediation timelines. They document not just what risks they found but what they decided to do about each one and why. And they reassess when their environment changes, not only when they’re preparing for an audit.

The difference between a risk analysis that satisfies OCR and one that creates liability isn’t primarily about format or tooling. It’s about whether the analysis reflects the reality of your environment, whether the findings are documented with enough specificity to be actionable, and whether those findings actually drive your security program.

A breach often brings risk-analysis weaknesses to OCR’s attention. An inadequate risk analysis can then become a separate compliance finding alongside other violations identified during the investigation.

Covered entities and business associates that approach the risk analysis as a foundational program, one that informs every security decision, are both better protected and better positioned if OCR ever comes asking.

Frequently asked questions

What is a HIPAA security risk assessment?

A HIPAA security risk assessment is a formal, documented analysis that identifies where ePHI exists across your organization, catalogs the threats and vulnerabilities that could affect it, and assigns risk levels to guide your security program. It’s required under 45 CFR 164.308(a)(1)(ii)(A) of the HIPAA Security Rule.

Who is required to conduct a HIPAA security risk assessment?

All HIPAA covered entities, including health care providers, health plans, and health care clearinghouses, must conduct a risk analysis. Business associates that handle ePHI on behalf of covered entities have the same obligation under the HITECH Act’s extension of the Security Rule to business associates.

How often do you need to conduct a HIPAA security risk assessment?

Under current rules, HHS requires the risk analysis to be an ongoing process without a fixed interval. In practice, most compliance professionals recommend a full review at least annually, with interim updates triggered by significant changes. A proposed HHS rule published December 27, 2024 would make the annual requirement explicit.

What does a HIPAA security risk assessment cover?

It covers all ePHI across all 3 safeguard categories in the Security Rule: administrative safeguards (policies, training, vendor management), physical safeguards (facility access, device controls), and technical safeguards (access controls, audit logs, encryption, authentication). Every system and location where ePHI is created, received, maintained, or transmitted must be included.

Is a business associate required to conduct its own risk assessment?

Yes. The HITECH Act extended HIPAA Security Rule obligations to business associates directly. Each business associate must conduct its own risk analysis covering the ePHI it handles. Business associates are directly liable for applicable Security Rule requirements, separate from a covered entity’s own BAA and risk management obligations.

Does signing a business associate agreement satisfy the risk assessment requirement?

No. A BAA is a contract that defines legal obligations. It doesn’t evaluate whether a vendor has adequate security controls in place. Your risk analysis must assess the actual security posture of your business associates, not just confirm that a contract exists.

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

HHS uses ‘risk analysis’ in the regulatory text. ‘Risk assessment’ is commonly used in practice to refer to the same process. The terms are interchangeable in the context of HIPAA Security Rule compliance.

Can I use the HHS Security Risk Assessment Tool to satisfy the requirement?

The SRA Tool version 3.7, available from HealthIT.gov for Windows and as an Excel workbook, helps structure the analysis and is useful for small and medium practices. HHS has stated that using the tool does not guarantee HIPAA compliance. The tool’s own documentation notes that the survey alone may not identify all risks in an organization.

What happens if you don’t conduct a HIPAA security risk assessment?

Failure to conduct an adequate risk analysis is an independent HIPAA violation, separate from any breach. OCR’s Risk Analysis Initiative has produced 14 enforcement actions through June 2026, with penalties ranging from $10,000 to $450,000, most tied to ransomware incidents or other breaches.

What triggers a new HIPAA security risk assessment?

Any significant change to your environment can trigger a reassessment: new systems or platforms, organizational changes like mergers or acquisitions, a security incident or breach, changes in key personnel, or meaningful changes in the threat landscape. The risk analysis should reflect your current environment, not the environment as it existed when the analysis was last completed.

How long do you need to keep HIPAA risk assessment documentation?

HIPAA Security Rule documentation must be retained for 6 years from the date of creation or from the date it was last in effect, whichever is later. This applies to your risk analysis documentation and all related security program records.

What is the proposed change to how often a HIPAA risk analysis must be conducted?

HHS published a proposed update to the HIPAA Security Rule on December 27, 2024. If finalized, it would require covered entities to conduct a full risk analysis review at least every 12 months. It would also restructure the current risk analysis requirements into 8 specific implementation specifications. The current rule remains in force while the proposal is under review.

What are the most common findings in a HIPAA security risk assessment?

Common findings include incomplete ePHI inventories that miss remote workers, legacy systems, or vendor platforms; access controls that are misconfigured or only partially deployed; missing or untested backup and recovery procedures; insufficient audit logging; and business associates whose controls have never been formally evaluated.

Is a vulnerability scan or penetration test the same as a risk assessment?

No. A vulnerability scan identifies known technical weaknesses in your systems. A penetration test attempts to exploit them. Both are useful tools that feed into a risk analysis, but neither covers administrative or physical safeguards and neither produces the likelihood and impact documentation the risk analysis requires. They don’t satisfy the Security Rule requirement on their own.

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

A gap assessment compares your current policies and practices against specific regulatory requirements to identify where you fall short. A risk analysis is a threat-based security analysis that identifies what could harm your ePHI and how likely and severe that harm would be. Both are useful but they serve different purposes, and a gap assessment doesn’t satisfy the risk analysis requirement.