The short answer

A HIPAA risk assessment is a formal, documented process required under the Security Rule’s risk analysis standard — not a conversation, not a mental checklist, a written analysis you can produce on request. It identifies where PHI lives, how it moves through your systems and vendors, and what could realistically go wrong: unauthorized access, a lost device, an unpatched integration endpoint, a vendor with no signed BAA. It is not the same thing as a HIPAA compliance audit. The audit checks whether your safeguards meet the rule; the risk assessment is the analysis that determines what those safeguards need to cover in the first place. The output is a written risk register and remediation plan, not a pass/fail grade.

What a HIPAA risk assessment actually is (and isn’t)

The requirement itself is narrow and specific. The Security Rule’s risk analysis standard, 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 the electronic PHI they hold. Two words carry the weight there: accurate and thorough. A verbal walk-through in a Monday standup, a founder’s mental list of “things we should probably fix,” or a vendor questionnaire filled out once at signup isn’t a risk analysis under this standard — it has to be documented, dated, and specific to your actual systems. That distinction matters because a risk assessment and a compliance audit get used interchangeably in casual conversation, and they are not the same exercise. The risk assessment is the analysis step: what could go wrong, and where. The audit, covered below, checks whether the safeguards addressing that analysis actually exist.

Who is required to conduct one, and who should actually run it

Covered entities and business associates are both required to conduct a risk analysis under the Security Rule — there’s no small-practice exemption, no it-only-applies-to-hospitals carve-out. Scale changes who should run it, not whether it’s required.

A small, single-product system with a designated security officer and a contained, well-understood architecture can often run its first internal assessment, provided it’s genuinely documented and not just a checklist filled out from memory. That changes once PHI moves at scale, once multiple integrations or EHR connections are in play, or once an enterprise customer’s vendor-due-diligence team is going to ask for the report directly. At that point, an independent third-party assessor buys objectivity a self-assessment structurally can’t produce, and a defensible result if OCR or an enterprise buyer ever asks how the analysis was conducted.

The stakes for getting this wrong aren’t abstract. OCR’s Risk Analysis Initiative, built to target exactly this failure, had reached 14 settlements as of July 2026 — and four recent ransomware-related resolutions all cited the same root cause: failure to conduct an accurate and thorough risk analysis before the breach happened.

What scope does a HIPAA risk assessment actually cover?

The required inventory is every system, application, and integration that creates, receives, maintains, or transmits PHI — not just the EHR sitting at the center of the practice. HHS’s own guidance on risk analysis requirements frames that inventory around the Security Rule’s three safeguard categories, and a real assessment works through all three, not just the technical one most engineering teams default to:

  • Administrative — documented policies, workforce access management, training records, a named security official who actually owns the process.
  • Physical — device disposal procedures, facility and server-room access, and increasingly, remote and hybrid work setups where a laptop with PHI on it goes home every night.
  • Technical — encryption in transit and at rest, role-based access controls enforced server-side, integration endpoints, cloud infrastructure configuration, mobile apps, and EHR/EMR interfaces.

The gap we see most often isn’t inside any of those three categories — it’s at the edges. Vendors and integrations are in scope, not just internally built systems. An EHR integration that pipes data to a third-party analytics tool, a texting platform handling appointment reminders, a billing clearinghouse — every one of those is a place PHI flows outside your own infrastructure, and every one of them belongs in the inventory whether or not your team wrote the code. Specialty practices add their own scope wrinkles: a dermatology EHR, for instance, has to treat clinical photography and imaging as PHI in scope, not an afterthought bolted onto a generic template built for a practice that never handles images at all.

The methodology: how a risk assessment is actually conducted

A risk assessment isn’t a form you fill in once and file. It’s a sequence, and each step depends on the one before it actually being done well:

  • Asset and data-flow inventory. Map every place PHI is created, stored, or transmitted, across every system identified in the scope above — a generic template can’t know your actual data flows, only your team can map them.
  • Threat and vulnerability identification. List what could realistically go wrong, split between internal risk (misconfigured access permissions, an unpatched dependency sitting in an integration library) and external risk (unauthorized access attempts, interception of data in transit).
  • Likelihood × impact scoring. Each identified risk gets rated on how likely it is to happen and how bad it would be if it did — typically following a NIST-aligned methodology like NIST SP 800-30, the federal government’s own guide for conducting risk assessments, adapted for a healthcare-specific threat environment. This scoring is what turns a flat list of risks into a prioritized one: an unpatched integration endpoint handling live PHI scores very differently than an encrypted laptop that would need to be physically stolen and then decrypted to expose anything.
  • Existing-safeguard documentation. For each scored risk, document what safeguard is already in place, if any, so the gap that’s left is the actual gap — not a theoretical one built from assuming nothing exists.

None of this is a fill-in-the-blank exercise, and a real assessment shows its work — which systems were inventoried, which threats were considered and why, how each score was reached. That’s also what makes it evidence rather than an opinion: anyone can hand over a document that says “we assessed our risk.” Fewer can show the inventory, the scoring logic, and the safeguard mapping that produced it.

What the output actually looks like

The deliverable is not a certificate, a badge, or a pass/fail grade — nothing about a risk assessment “passes.” It’s a written risk register: every identified risk, its likelihood and impact score, the existing safeguard addressing it (or the fact that none exists), and a specific remediation action with an owner and a timeline attached. A risk without an owner and a date next to it is a risk that gets rediscovered, unfixed, at the next assessment.

HHS expects that documentation retained and available on request, not filed away and forgotten — it’s the evidence a real compliance audit asks to see first, before it looks at anything else. A risk register that can’t be produced on request is functionally the same as a risk register that was never written.

There’s a real difference between a genuine risk register and the superficial version some vendors generate: a report that restates the Security Rule’s three safeguard categories in generic language, with no findings specific to your actual systems, your actual vendors, or your actual architecture. That kind of report photographs well in a board deck and does nothing when OCR or an enterprise security team asks a follow-up question. The test is simple — does the report name your systems, or could it be handed to any practice in the country unchanged?

How this differs from a HIPAA compliance audit — and why you need both

The overlap between these two terms is where most confusion — and most thin content about both — comes from. The risk assessment produces the analysis: what could go wrong, and where, based on your actual systems. The compliance audit checks whether the safeguards addressing that analysis actually exist and actually work. Neither substitutes for the other. An audit performed against an outdated or absent risk assessment is checking your safeguards against a map of risks that may no longer reflect your actual system — new integrations, new vendors, and new features all shift where the real exposure sits, and an audit can’t catch a gap the underlying analysis never identified.

Run the assessment first, because it defines what the audit needs to check. Then treat the audit as the recurring verification layer sitting on top of it. Our HIPAA compliance audit checklist covers that broader, recurring compliance program — BAAs, access reviews, audit logs, and the annual cadence this risk assessment feeds directly into.

Common mistakes that make a risk assessment worthless

A handful of patterns show up again and again in assessments that don’t hold up:

  • Generic, templated assessments that restate the Security Rule’s categories without reflecting the organization’s actual systems — the same failure mode covered above, and the reason architecture-specific work like custom EHR development starts from your actual system instead of a template built for someone else’s.
  • Scoping out vendors and third-party integrations because nobody remembered they touch PHI, or because “we didn’t build it” got treated as “it’s not our risk.”
  • Treating the assessment as a one-time launch event instead of updating it after a material system change — a new integration, a new vendor, a new feature that touches PHI for the first time.
  • A report that identifies risks but assigns no owner and no timeline for remediation, so the findings sit in a document nobody actually acts on.

The most durable fix for most of these isn’t a better assessment template — it’s building the system to handle PHI correctly from the start. Our HIPAA-compliant app development guide covers that broader groundwork.

Related reading / quick Q&A

Is a HIPAA risk assessment the same as a HIPAA audit? No. The assessment identifies and scores what could go wrong; the audit checks whether the safeguards addressing those risks are actually in place.

How long does a HIPAA risk assessment take? It depends heavily on scope — a narrow, single-system assessment moves faster than one covering multiple integrations, vendors, and locations. What sets the timeline is less the paperwork than how many systems and data flows have to be mapped and scored honestly.

Do small practices need a third-party risk assessment? Not always for the first pass, if there’s a designated security officer and a genuinely contained system. Once integrations, vendors, or enterprise due diligence enter the picture, an independent assessor is worth the objectivity. If you’re weighing which side of that line you’re on, talk to our team about a risk assessment — we’ll help you scope it honestly before you commit to either path.