Risk Analysis, Gap Assessment, or Audit? They Are Not the Same Thing
Practices regularly tell us they have had 'a HIPAA assessment' and produce a document that would not satisfy the regulation. The terms are used loosely in the market; the regulation is not loose at all.
Security Risk Analysis — the one the rule requires
Required by 45 CFR 164.308(a)(1)(ii)(A). It is an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of the ePHI your organisation holds. That means identifying where ePHI lives and moves, enumerating threats and vulnerabilities against each, and scoring them for likelihood and impact. It is specific to your environment and it produces a risk register, not a pass mark.
- →Scoped to your actual systems, sites, and data flows
- →Threat and vulnerability register with likelihood and impact scores
- →Feeds a written risk management plan under 164.308(a)(1)(ii)(B)
- →Dated, refreshed annually and after any material change
Gap assessment — useful, but not sufficient
A gap assessment compares your current state against a control framework and lists what is missing. It is genuinely useful as a starting point and often cheaper. What it is not is a risk analysis: it has no threat modelling and no risk scoring, so it cannot tell you which gaps matter most in your environment. Submitting one in response to an OCR request for a risk analysis does not satisfy the request.
Compliance audit — testing whether controls operate
An audit tests operating effectiveness against a defined protocol, typically the HHS OCR Audit Protocol plus, in Texas, HB300. Where a risk analysis asks what could go wrong, an audit asks whether the controls you claim to have actually work. Practices usually want this once the risk analysis findings have been remediated, to confirm the remediation held.
Penetration test — proving the technical controls
A penetration test is an authorised attempt to defeat your technical safeguards. It answers a narrow question extremely well and tells you nothing about training records or Business Associate Agreements. Under the 2026 NPRM annual technical testing becomes an explicit requirement, so this moves from good practice to obligation. Note that a vulnerability scan is not a penetration test — a scan enumerates known weaknesses, a test attempts exploitation and chains findings together.
Which to buy, and in what order
For a practice with nothing current on file, the order is not a matter of taste.
- →Start with the Security Risk Analysis — it is the legal requirement and it scopes everything else
- →Remediate the high-severity findings it produces, in risk-reduction order
- →Add a penetration test once the obvious technical gaps are closed, so you are testing a real environment
- →Run a compliance audit annually thereafter to confirm the controls still operate
How to tell what you were actually sold
Open the document you have. If it contains a scope statement, a data-flow map, and a table of threats with likelihood and impact scores, it is a risk analysis. If it is a checklist with ticks, it is a gap assessment. If it is one page on letterhead asserting that you are HIPAA compliant, it is marketing, and it will not survive contact with a reviewer.
Key takeaways
- 1.Only a Security Risk Analysis satisfies 164.308(a)(1)(ii)(A) — gap assessments do not
- 2.A risk analysis scores threats by likelihood and impact; a gap assessment only lists gaps
- 3.A vulnerability scan is not a penetration test
- 4.If your document has no data-flow map and no risk scores, it is not a risk analysis