The HIPAA risk analysis is the most important compliance document you’ll ever produce, and the one most organizations get wrong. It’s the first thing investigators ask for after a breach, the most frequently cited gap in enforcement actions, and the foundation every other safeguard decision is supposed to rest on.
It’s also — despite what the consulting industry implies — something a competent team can do themselves. This guide walks through the process step by step: what the regulation actually requires, how to scope it, how to score risk without pretending to false precision, and how to turn the output into a risk register you’ll actually use.
What the regulation actually requires
The requirement lives at 45 CFR §164.308(a)(1)(ii)(A): 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.”
Unpack the load-bearing words:
- Accurate and thorough — it must reflect your real environment, all of it. An analysis covering only your production database while ignoring laptops, email, and vendors is the classic failure mode cited in enforcement.
- Confidentiality, integrity, and availability — not just “can data leak” but “can data be corrupted” and “can data become unavailable.” Ransomware is an availability risk; this is why it’s squarely a HIPAA issue.
- Held by — everywhere you hold ePHI, including systems run by vendors on your behalf.
HHS guidance points to the NIST risk assessment methodology (SP 800-30) as a reasonable framework, but no specific method is mandated. What’s mandated is that the process happened, was documented, and is maintained. The companion requirement — risk management at §164.308(a)(1)(ii)(B) — obligates you to actually reduce the risks you find to a reasonable and appropriate level. An analysis with no follow-through is half a compliance program.
One distinction worth stating plainly: a risk analysis is not a gap assessment. A gap assessment compares you to a checklist of controls; a risk analysis reasons about threats to your specific assets. You need both, they reinforce each other, but regulators specifically require the risk analysis. (Our HIPAA checklist handles the control-coverage side.)
Step 1: Define your scope honestly
Scope failures sink more risk analyses than methodology failures. Your scope is: all ePHI, in all forms, in all locations. Before touching a spreadsheet, answer these:
- Which products, services, and business processes involve ePHI?
- Which environments — production, staging, analytics, backups, archives?
- Which endpoints — laptops, phones, home machines under BYOD?
- Which communication channels — email, chat, SMS, support tools, voicemail transcription?
- Which vendors hold or process ePHI on your behalf?
- Any paper or physical media with PHI (yes, the Security Rule covers ePHI, but note where paper exists for your Privacy Rule work)?
Write a one-paragraph scope statement, and just as importantly, write down what’s out of scope and why. “Marketing website excluded — collects no PHI, verified by reviewing all forms on 2026-08-04” is exactly the kind of sentence that makes an analysis credible.
Step 2: Build your asset and data-flow inventory
You can’t assess risk to assets you haven’t listed. For each system in scope, record:
- Name and description — “PostgreSQL production DB (patient records),” “Google Workspace email,” “Support laptop fleet”
- What ePHI it holds — demographics, clinical notes, claims, identifiers
- Owner — a named person, not a team
- Location — cloud region, office, vendor
- Existing controls — encryption at rest/in transit, MFA, access model, backup coverage, logging
Then sketch the data flows: how ePHI enters (patient intake, API from a partner, file upload), where it moves internally (queues, ETL, analytics), and where it exits (claims submission, vendor integrations, patient portals). A boxes-and-arrows diagram on one page is plenty.
Two field-tested tips. Interview staff rather than trusting architecture docs — shadow IT and “temporary” workarounds are where breaches actually happen. And explicitly hunt for ePHI in places it shouldn’t be: exported CSVs in downloads folders, screenshots in ticketing systems, test databases seeded with production data.
Step 3: Identify threats and vulnerabilities per asset
For each asset, ask: what could realistically go wrong here? Work from categories so you don’t anchor on last month’s headline:
- External attack: phishing and credential theft, ransomware, exploitation of unpatched software, cloud misconfiguration discovered by scanners
- Insider: curiosity snooping, disgruntled-employee exfiltration, well-meaning workarounds (emailing PHI to personal accounts to work from home)
- Vendor: breach at a business associate, subcontractor you didn’t know existed, vendor going out of business with your data
- Physical and environmental: stolen laptops, lost phones, office break-ins, fire and flood affecting on-prem gear
- Process failures: offboarded users retaining access, backups that never restore, misdirected email or fax, disposal of unwiped devices
Pair each threat with the vulnerability that would let it succeed: “ransomware” is a threat; “no MFA on VPN and untested backups” is the vulnerability pairing that makes it a high risk. This pairing is what makes the next step scoreable rather than hand-wavy.
Don’t aim for an exhaustive taxonomy. Fifteen to forty well-chosen threat/vulnerability pairs covering your real environment beat three hundred generic rows copied from a template.
Step 4: Score likelihood and impact — simply and consistently
Resist the temptation to invent decimal-point risk math. A 3×3 or 5×5 qualitative scale is accepted practice and far easier to apply consistently. Define your anchors in writing:
Likelihood
- Low: no plausible path today given current controls; would require multiple failures
- Medium: plausible within a year; partial controls exist
- High: expected to occur, is occurring, or has occurred; control missing entirely
Impact
- Low: minimal ePHI exposure; no notification likely; quick recovery
- Medium: reportable breach affecting a limited population; days of disruption
- High: large-scale breach (500+ individuals), extended outage of clinical or core systems, or data integrity loss affecting care or claims
Score each threat/vulnerability pair with current controls taken into account (this is “residual likelihood,” and it’s the honest number). Then combine: high/high pairs are critical, low/low pairs are noted and accepted. Write one sentence of rationale per score. The rationale is what turns a spreadsheet into evidence — it shows a reasoned process, which is precisely what “accurate and thorough” means in practice.
Consistency beats sophistication. Two people scoring the same risk should land within one level of each other; if they don’t, tighten your anchor definitions.
Step 5: Build the risk register
The risk register is the living output — the document that survives after the analysis narrative is filed. One row per risk:
- ID and short name — “R-07: Ransomware via phished credentials”
- Asset(s) affected
- Threat/vulnerability pair
- Likelihood, impact, and resulting rating
- Existing controls
- Treatment decision (next step)
- Owner — a person accountable for the treatment
- Target date and status
Sort by rating, review the top ten with leadership, and get sign-off. That leadership review isn’t ceremony: risk acceptance is a management decision, and documenting who accepted which residual risks protects both the company and the compliance officer.
Keep the register in a system with revision history. When an auditor or a customer’s security team asks “how do you manage risk,” the register with six months of dated updates is the answer.
Step 6: Choose a treatment for every risk
Every row gets one of four dispositions:
- Mitigate: implement or improve a control. Most high risks land here — enable MFA, encrypt the laptop fleet, segment the network, fix the offboarding process.
- Accept: for low risks where the mitigation cost clearly exceeds the exposure. Acceptable only when documented and signed off by someone with authority.
- Transfer: shift the exposure — cyber insurance, or moving a workload to a vendor with stronger controls under a BAA. Note that you can transfer financial exposure but never regulatory responsibility.
- Avoid: stop the risky activity — retire the legacy tool, stop collecting a data element you don’t need, de-identify the analytics pipeline.
Sequence mitigations by risk-reduced-per-dollar, not by what’s interesting. In most environments the first tranche is boring and predictable: MFA everywhere, full-disk encryption, access recertification, backup restore tests, and cloud storage configuration review. That tranche typically retires more risk than any product purchase.
This treatment plan is also your §164.308(a)(1)(ii)(B) risk management documentation — the analysis and the plan together satisfy the pair of requirements regulators check first.
Step 7: Document it like it will be read by a skeptic
Assemble a final package, because it will eventually be read by someone whose job is to doubt you — an OCR investigator, a customer’s counsel, an insurer:
- Scope statement, with exclusions and rationale
- Methodology description (scales, anchors, who participated, dates)
- Asset inventory and data-flow diagram
- Threat/vulnerability worksheet with scores and rationale
- Risk register with treatments, owners, and dates
- Leadership sign-off, dated
Date everything. §164.316 requires documentation to be retained six years, kept available to the workforce members who need it, and updated as things change. An undated risk analysis is nearly as weak as a missing one, because you can’t show it reflected the environment at any particular time.
Keeping it alive: review triggers and cadence
HIPAA doesn’t set a frequency; defensible practice does. Commit to:
- Annual full review — re-walk the inventory, rescore, refresh the register
- Event-driven updates — new product or system handling ePHI, new vendor, acquisition, major architecture change, or any security incident
- Quarterly register check-ins — are treatments on schedule, and did anything change?
A risk analysis last touched three years ago tells investigators the program stalled — and stalled programs are how “reasonable cause” findings drift toward “willful neglect.”
Common failure modes to avoid
- Scoping to one system. The enforcement record’s favorite finding is the partial analysis.
- Confusing a vendor’s product scan with your risk analysis. A vulnerability scan is an input, not the analysis.
- Buying a “certification.” No HIPAA certification exists — HHS neither issues nor recognizes one. What exists is a documented analysis and, if you want outside rigor, an independent assessment with a readiness report. That’s the artifact sophisticated buyers ask for; our gap assessment service produces exactly that, and pricing is public.
- A register no one owns. Risks without named owners and dates are observations, not a program.
- Perfectionism. A complete, honest, medium-resolution analysis finished this month beats an exquisite one finished never.
Start this week
The whole process, for a small or mid-size organization, is roughly two to four working weeks of part-time effort: a few days of inventory and interviews, a few days of threat scoring, a day of register-building and leadership review. Our free HIPAA templates include a risk analysis workbook and register format you can use as-is.
If you want a fast external read before you begin, the free HIPAA readiness assessment scores your current posture in about ten minutes and hands you a prioritized gap list — a useful seed for Step 3. And if you’d rather pressure-test your approach with someone who’s done this a few hundred times, book a 20-minute call. Bring your scope statement; we’ll tell you what a skeptic would say about it.