Is a vulnerability scan the same as a HIPAA Security Risk Analysis?

No. A vulnerability scan is an automated technical assessment of specific systems. A HIPAA Security Risk Analysis is a documented evaluation of all the ways risks to ePHI could materialize across people, process, and technology. Scans inform the analysis but are not a substitute for it. Substituting one for the other is a common compliance deficiency.

How often must a HIPAA Security Risk Analysis be performed?

HHS Office for Civil Rights guidance and §164.308(a)(8) require periodic review and updates. There is no statutory interval, but the prevailing standard is annually and after any significant change — new systems, new business associate, new physical site, or a security incident. Many covered entities perform the analysis once and never refresh it, which is itself a deficiency.

What does HHS look at if my organization is investigated?

The OCR will ask for a current, documented Risk Analysis covering all ePHI across the organization, the risk management plan that addresses identified risks, evidence those mitigations were implemented, and the periodic review history. Inability to produce these is one of the most common findings in OCR settlements. Penalties for "willful neglect" of the Risk Analysis requirement can exceed $1.9 million per violation category, per year.

Can our existing IT provider perform our HIPAA Security Risk Analysis?

Yes in theory, no in most practical cases. The Risk Analysis must evaluate the IT provider itself as a Business Associate, which creates a conflict of interest when the provider audits its own work. Best practice — and what OCR auditors expect — is an independent assessment by a firm that does not also operate your environment.

What §164.308 Actually Requires: A Real HIPAA Security Risk Analysis

Q: What is a HIPAA Security Risk Analysis?

A HIPAA Security Risk Analysis is the formal assessment required by 45 CFR §164.308(a)(1)(ii)(A). It evaluates risks and vulnerabilities to the confidentiality, integrity, and availability of electronic Protected Health Information (ePHI) across a covered entity's administrative, physical, and technical safeguards. It is the foundational document of HIPAA Security Rule compliance.

Roughly half the medical and dental practices we audit cannot show us their HIPAA Security Risk Analysis. Most have something — a "HIPAA assessment," a "security questionnaire" their IT provider filled out, a 2018 PDF from a vendor that no longer exists. None of those are what the rule asks for.

The Risk Analysis is the most-cited deficiency in OCR HIPAA enforcement actions. It is also the most fixable. The rule is short, the requirements are knowable, and the cost of getting it right is materially less than the cost of getting it wrong. This is a working walkthrough.

What the rule literally says

The text of 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.

Four words in that sentence do most of the work. "Accurate" means the analysis must reflect what is actually in your environment, not a template. "Thorough" means all ePHI, everywhere — including the laptop that left the office, the printer with the hard drive, the SaaS vendor your billing team uses. "Risks and vulnerabilities" are not the same thing. A vulnerability is a weakness. A risk is the impact of that weakness being exploited, weighted by likelihood. The analysis must address both.

What gets called a Risk Analysis and isn't

We see these three deficient artifacts repeatedly:

The vulnerability scan report. An automated tool produced a 60-page PDF listing CVEs across the network. Useful. Not a Risk Analysis. The scan identifies technical vulnerabilities on systems it could see; it does not evaluate workflow, business associates, physical access, or risks the scanner cannot detect.

The compliance checklist. A 200-item questionnaire with yes/no answers and a percentage score at the bottom. Often produced annually as a renewal exercise. Useful as a self-attestation aid. Not a Risk Analysis, because a checklist does not analyze. It records.

The IT provider's "we got you" letter. A signed letter from the MSP stating that the practice is HIPAA compliant. This is not a regulatory document. It is a marketing artifact. OCR does not credit it.

What a defensible analysis actually contains

The OCR and NIST have published guidance on what a defensible Risk Analysis looks like. The structure converges on six elements:

Scope. A documented inventory of every system, location, device, application, and business associate that creates, receives, maintains, or transmits ePHI. Most analyses we review are wrong here — they miss BAA-covered SaaS tools and any device that touches PHI outside the four walls.
Threat sources. A documented list of the threat actors and threat scenarios relevant to this environment — external attackers, insiders, environmental hazards, third-party breaches.
Vulnerability identification. The technical and non-technical weaknesses that those threats could exploit, captured from scans, interviews, observation, and documented controls testing.
Likelihood and impact. For each risk, a rated assessment of how likely it is to occur and the magnitude of impact on ePHI. NIST 800-30 provides the standard rating methodology.
Risk determination. Combined likelihood and impact rankings, producing prioritized risks. This is what becomes the risk management plan under §164.308(a)(1)(ii)(B).
Documentation and review. The whole analysis must be in writing, dated, with a review schedule. Three years is the federal documentation retention floor under §164.316(b).

The conflict-of-interest problem

The most subtle issue we see: the IT provider performs the Risk Analysis on the environment they themselves built and operate. In nearly every audit we run, the IT provider is also a Business Associate under HIPAA. The Risk Analysis is supposed to evaluate them, among other risks. They cannot independently audit themselves.

OCR has not formally required independent assessment, but every settlement we have read involving a Risk Analysis deficiency has identified self-assessment as a contributing factor. The standard of care has shifted. If your IT provider performs your Risk Analysis, your defensibility under audit is materially weaker than if a separate firm performs it.

What this costs to get right

A real Risk Analysis for a mid-sized practice — five to fifty users, one to three locations — takes three to six weeks and produces a 40 to 80 page document plus a risk management plan. A boutique firm with healthcare experience can deliver this for materially less than the cost of one settlement with HHS, and meaningfully less than a Big Four-style engagement that produces a similar deliverable.

What we recommend is not heroic. Schedule the analysis annually. Use an independent firm. Make sure the document covers all ePHI everywhere it lives. Document the management plan. Implement the high-priority mitigations. Review on schedule. The HIPAA Security Rule was written to be doable by an organization that takes it seriously. Most don't. The ones that do don't appear in OCR settlement filings.

If you're due for an analysis — or have not had one in two years — Caveo Security runs HIPAA-specific compliance work through our Compliance & Audit practice.