A risk analysis is required by the HIPAA Security Rule; a gap assessment is not. A gap assessment compares your current controls against a list of the Security Rule's standards and implementation specifications and tells you which boxes are unchecked. A risk analysis is an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of all electronic protected health information (ePHI) your organization creates, receives, maintains, or transmits — threats, likelihood, impact, and risk levels included. A gap assessment is a useful project management tool. It is not a substitute for the required risk analysis, and OCR has repeatedly found organizations noncompliant for treating it as one.
The difference in one paragraph
Think of it this way. A gap assessment asks: what does the regulation say we should have, and what do we not have? A risk analysis asks: where is our ePHI, what could go wrong, how likely is it, how bad would it be, and how much risk are we carrying? The first is measured against a checklist. The second is measured against reality.
What the Security Rule actually requires
Risk analysis is a required implementation specification under the Security Management Process standard. The regulatory text at 45 CFR 164.308(a)(1)(ii)(A) directs organizations 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 organization.
Three consequences follow from the way that requirement is written, and OCR's Guidance on Risk Analysis makes each explicit:
- Scope is everything. The analysis must cover all ePHI the organization creates, receives, maintains, or transmits, in every electronic medium — servers, workstations, laptops, mobile devices, portable media, and systems held by vendors on your behalf. An analysis that covers only the EHR is not thorough.
- No prescribed methodology. The Security Rule does not mandate a particular method, recognizing that approaches vary with the size, complexity, and capabilities of the organization. NIST publications, notably SP 800-30 and SP 800-66, are widely used as frameworks and are cited by OCR as helpful, though only federal agencies are required to follow them.
- It feeds everything else. OCR describes risk analysis as foundational. Addressable implementation specifications are not optional; whether an addressable specification is reasonable and appropriate for you is a determination that flows out of the risk analysis, and the reasoning must be documented.
Side by side
| Risk analysis | Gap assessment | |
|---|---|---|
| Required by the Security Rule? | Yes — 45 CFR 164.308(a)(1)(ii)(A) | No |
| Core question | What are the risks to our ePHI, and how severe? | Which Security Rule requirements do we not yet meet? |
| Starting point | A complete inventory of where ePHI lives and moves | The list of standards and implementation specifications |
| Considers threats and vulnerabilities? | Yes — identified and documented | Usually not, or only incidentally |
| Considers likelihood and impact? | Yes — both, producing risk levels | No |
| Typical output | Documented risks with assigned risk levels, feeding a risk management plan | A checklist of unmet requirements |
| Frequency | Ongoing; reviewed and updated as the environment changes | Point in time, often before a project |
| Satisfies the requirement on its own? | Yes, if accurate and thorough | No |
What a gap assessment is good for
None of this makes gap assessments worthless. They are fast, cheap, and legible to leadership. A gap assessment is a reasonable tool when you want to scope a compliance program before committing budget, brief a new compliance officer on where the obvious holes are, prepare for a vendor security questionnaire, or track remediation of previously identified deficiencies. The failure mode is not doing one — it is doing one instead of a risk analysis and filing it as though the requirement were satisfied.
Why substituting one for the other fails
A gap assessment cannot tell you the things the rule requires you to know. It will not surface the ePHI sitting in an unmanaged shared drive, because that system is not on the regulation's list. It will not tell you that the one control you did implement is misconfigured. It will not weigh a low-likelihood, catastrophic-impact scenario against a high-likelihood, minor one, so it gives you no basis for prioritizing remediation. And because it never establishes scope, it cannot demonstrate that all of your ePHI was considered — which is precisely what an enforcement reviewer will ask.
Risk analysis findings also appear repeatedly in OCR enforcement actions and in the HIPAA Audit Program's areas of focus. An organization that cannot produce a documented, current, organization-wide risk analysis is in a weak position regardless of how many individual controls it has bought.
Elements of a defensible risk analysis
OCR's Guidance on Risk Analysis lays out the elements any methodology must incorporate. Use them as your table of contents:
- Scope. All ePHI in all electronic media, wherever it is created, received, maintained, or transmitted.
- Data collection. Identify and document where ePHI actually is, using system reviews, interviews, and documentation. Vendors and cloud systems count.
- Threats and vulnerabilities. Identify and document reasonably anticipated threats — natural, human, and environmental — and the technical and non-technical vulnerabilities they could exploit.
- Current security measures. Assess what is in place, whether it is required by the rule, and whether it is configured and used properly.
- Likelihood. Estimate the probability that each threat-vulnerability pair occurs.
- Impact. Assess the magnitude of harm if it does. Qualitative, quantitative, or both.
- Risk level. Combine likelihood and impact into an assigned risk level, with a list of corrective actions.
- Documentation. No format is mandated, but the analysis must be documented — and it becomes the direct input to risk management.
- Periodic review. The process is ongoing. New systems, a merger, key staff turnover, or a security incident are all triggers to reassess.
How the two work together
The productive sequence is: risk analysis first, then risk management, with a gap assessment used as a supporting instrument rather than the main event. The risk analysis tells you where the exposure is; the gap assessment translates part of that into a regulatory to-do list; the risk management plan sequences the work by risk level rather than by ease. Organizations that invert this order end up buying controls in the order vendors sell them, which is rarely the order the risk demands.
A note on the proposed Security Rule updates
HHS has published a Notice of Proposed Rulemaking that would revise the Security Rule, including how risk analysis is documented and how often certain activities recur. Those changes are proposed. They are not final, they are not in effect, and it is not settled whether or in what form they will be adopted. The risk analysis requirement discussed on this page is the one in force now, and it has been in force for years. The right response to the NPRM is to read it and follow the rulemaking — not to assume new obligations have already attached, and not to postpone the risk analysis you already owe.
The bottom line
A gap assessment measures you against a list. A risk analysis measures you against your actual environment, and it is the one the Security Rule requires. Do the risk analysis: scope all ePHI, document threats and vulnerabilities, weigh likelihood and impact, assign risk levels, write it down, and keep it current. Use gap assessments alongside it, never in place of it.
Common questions
Is a gap assessment enough to satisfy the HIPAA Security Rule?
No. A gap assessment compares your controls to the rule's requirements but does not assess threats, vulnerabilities, likelihood, or impact across all of your ePHI. The Security Rule requires a risk analysis under 45 CFR 164.308(a)(1)(ii)(A).
How often must a HIPAA risk analysis be done?
The Security Rule does not set a fixed interval. OCR's guidance describes risk analysis as an ongoing process that should be reviewed and updated as the environment changes — for example after a security incident, a change in ownership, key staff turnover, or the introduction of new technology.
Does the Security Rule require a specific risk analysis methodology?
No. OCR states the rule does not prescribe a methodology, recognizing that approaches vary by size, complexity, and capability. NIST SP 800-30 and SP 800-66 are commonly used frameworks and are referenced in OCR's guidance.
Does a vendor's security certification replace our risk analysis?
No. A vendor attestation says something about the vendor's environment, not yours. The obligation to assess risks to the ePHI your organization creates, receives, maintains, or transmits stays with your organization.