Risk analysis, risk assessment, gap assessment: the differences that matter

A practice manager we spoke with had paid for a "HIPAA security assessment" and received a forty-page report. It was professionally formatted and full of findings. It was also a gap assessment, and when the practice was later asked to produce its risk analysis, it had nothing that qualified. The vendor had not lied. The terms had simply been used interchangeably by everyone involved, and nobody had asked which one was being delivered.

This happens constantly. The vocabulary of healthcare security is imprecise, and the differences between these documents are real and consequential. Here is a plain-language guide.

Risk analysis and risk assessment

Start with the good news: these two are the same thing.

The HIPAA Security Rule uses the term "risk analysis" at 45 CFR 164.308(a)(1)(ii)(A). The National Institute of Standards and Technology, whose publications HHS points to as the reference methodology, uses "risk assessment" in NIST Special Publication 800-30. Different agencies, different vocabulary, same activity: identify where the data is, identify what could go wrong, rate the likelihood and impact of each, and prioritize the results.

If a vendor proposes a "risk assessment," that is not a red flag by itself. What matters is whether the deliverable contains the substance the Security Rule requires. The question to ask is whether the result will include, for each identified risk, a likelihood rating, an impact rating, and a resulting risk level specific to your organization. If yes, the label does not matter. If the answer is vague, keep asking.

Gap assessment

A gap assessment is a different exercise. It starts with a list of requirements, in this case the provisions of the Security Rule, and checks each one: do you have this control or not? The output is a list of gaps, meaning requirements you have not addressed.

This is useful. It tells you where your program is incomplete relative to the regulation. Many organizations should do one, particularly early in building a compliance program.

But it is not a risk analysis, and OCR has said so directly. In its April 2018 cybersecurity newsletter, OCR addressed this confusion explicitly: a gap analysis identifies whether controls are in place, while a risk analysis evaluates the actual risk to ePHI, and the former does not satisfy the requirement for the latter.

The reason is instructive. A gap assessment tells you that you lack, say, a documented sanction policy. It does not tell you what that gap means for your particular patient data, how likely it is to cause harm, or how it ranks against the fifteen other gaps on the list. It cannot, because it is comparing you to a checklist rather than analyzing your environment. Two organizations with identical gap lists can have wildly different risk profiles depending on what data they hold, how it flows, and who has access.

The other things that get confused

Vulnerability scan

An automated tool examines your systems for known technical weaknesses: unpatched software, open ports, weak configurations. The output is a list of findings, usually with severity scores. Scans are valuable and should happen regularly. They cover technical controls only. They know nothing about your policies, your training, your physical security, or your business associates. A scan report is a useful input to a risk analysis. On its own it is not one.

Penetration test

A skilled person attempts to break into your systems the way an attacker would, and reports what they were able to reach. This tests whether your controls actually work under pressure, which is different from whether they exist. Penetration tests are more expensive than scans and answer a narrower question. They are appropriate for organizations that have already done the foundational work, not a substitute for it.

Audit

An audit examines whether you are doing what you said you would do. It checks your practices against your own policies and against regulatory requirements, typically with evidence review. HIPAA requires periodic evaluation at 164.308(a)(8), and an audit is one way to meet that. An audit assumes the policies and controls already exist. It does not tell you which ones you need.

Compliance attestation or certification

Worth naming because it is sold aggressively. No organization can be "HIPAA certified." HHS does not certify, does not recognize any private certification, and has said so. A vendor offering a HIPAA certificate is offering something with no regulatory standing. That does not mean their underlying assessment is worthless, but the certificate itself is marketing, and if you are asked to produce your risk analysis, a certificate will not be accepted in its place.

How they fit together

A mature security program uses several of these, in a logical order.

Activity	Question it answers	Required by HIPAA?
Risk analysis	What could go wrong with our ePHI, how likely is it, and how much would it matter?	Yes, explicitly
Gap assessment	Which Security Rule requirements have we not addressed?	Not by name, but useful for building the program
Vulnerability scan	Which of our systems have known technical weaknesses right now?	Not by name, but expected as part of ongoing risk management
Penetration test	Could a determined attacker actually get in, and how far?	No, though proposed rule changes would require it annually
Audit or evaluation	Are we doing what our policies say we do?	Yes, periodic evaluation at 164.308(a)(8)

The risk analysis comes first, because it tells you where to focus everything else. A gap assessment might run alongside it when a program is new. Scans feed the analysis with current technical findings. Penetration testing validates that high-priority controls hold up. Audits confirm the program is operating as designed. Each has a role. Only one of them is what OCR asks for by name.

What to ask before you buy

When a vendor proposes any kind of HIPAA assessment, four questions cut through the vocabulary:

1. Will the deliverable rate specific risks to my specific data by likelihood and impact, or will it list requirements I have or have not met?
2. What is the scope? Every system holding ePHI, or the EHR only?
3. Will it include a prioritized remediation plan, or stop at findings?
4. If OCR asked for my risk analysis, is this the document I would hand them?

A vendor who can answer those clearly is selling something real, whatever they call it. A vendor who gets vague at question one is probably selling a gap assessment or a scan under a more impressive name.