The precise regulatory term, what a defensible one contains, and the methodology choices that hold up under scrutiny.
The regulatory text
The risk analysis is a required implementation specification — not addressable. There is no rationale that excuses skipping it.
The text itself, at 45 CFR §164.308(a)(1)(ii)(A), requires you 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.” Every word carries weight. Accurate and thorough rules out the questionnaire-only exercise. Potential means you assess threats that have not materialised yet. Confidentiality, integrity, and availability means ransomware and data loss are in scope, not just snooping. And held by means all ePHI, everywhere — the EHR, the cloud databases, the analytics warehouse, the backup vault, the laptops, the vendor systems processing on your behalf. Scoping to one flagship system is the single most common way an otherwise competent analysis fails.
It is paired with an equally required sibling: risk management, §164.308(a)(1)(ii)(B), the documented programme of measures reducing identified risks to a reasonable and appropriate level. An analysis without a management plan is a diagnosis without treatment, and OCR requests them together.
Analysis versus assessment, and versus everything else
The rule says “risk analysis”; practitioners say “risk assessment”; the terms are interchangeable in practice — the fuller discussion lives in the risk assessment guide. What the risk analysis is not: it is not a gap assessment (which compares you to the rule’s checklist rather than to threats), not a penetration test (which probes specific technical weaknesses), and not the breach-time four-factor assessment (which evaluates one incident). All four are useful; only one is this required specification, and substituting any of the others for it is a finding.
Choosing a methodology
NIST SP 800-30 is the reference most assessors expect. What matters is that your methodology is written down, applied consistently, and repeatable by someone else.
HHS deliberately mandates no methodology, and its own guidance points to the NIST framework as one reasonable approach. The elements any defensible methodology needs: a scoping statement of where ePHI lives (built on a real asset and data-flow inventory), identified threat sources and events, identified vulnerabilities, an assessment of current controls, likelihood and impact determinations, a resulting risk level, and documentation of all of it. Write the methodology down before running it — a documented method applied consistently is what turns your conclusions from opinions into findings. Qualitative scales are fine at most organisations’ size; quantitative modelling is not required and usually not worth the ceremony. The test of repeatability is concrete: could a new hire, given your methodology document and inventory, produce materially the same register? If not, the analysis lives in someone’s head, and heads leave.
Likelihood and impact scoring
Use a defined scale with written definitions for each level. A 1–5 scale where nobody can say what a 3 means produces numbers that mean nothing.
Definitions do not need to be elaborate — likelihood anchored to rough frequency (“has happened here or to peers within a year” versus “conceivable but no known occurrence”) and impact anchored to consequence (“regulatory notification plus material care disruption” versus “contained inconvenience”) are enough to make two assessors converge. Score likelihood after accounting for current controls: the point is residual exposure, not theoretical horror. And resist the tidy diagonal — a register where every risk lands medium is a register that avoided decisions. The scoring exists to force a ranking, because the ranking becomes the remediation queue, and the remediation queue becomes your risk management plan with owners and dates attached.
Documenting accepted risk
When you accept a risk, record who accepted it, on what date, with what business justification, and when it will be revisited. This single practice separates programs that survive an investigation from those that do not.
Accepting risk is legitimate — the rule requires reducing risk to a reasonable and appropriate level, not to zero, and a small organisation cannot fund every mitigation at once. What is not legitimate is silent acceptance: the risk identified in the register and then simply never mentioned again. To an investigator, that reads as negligence. The same item with a signed acceptance — who decided, when, why the residual risk is tolerable given cost and mission, and the date it comes back for review — reads as governance. The difference between those two readings maps directly onto the penalty tiers, which turn on whether an organisation knew and acted reasonably or knew and neglected.
Keeping it current
The analysis is not an annual ritual so much as a living document with an annual heartbeat. Review it on a schedule — yearly is the defensible convention — and re-open it whenever the environment materially changes: a new system holding ePHI, a new vendor category, an acquisition, a shift to remote work, or an incident that revealed a threat you had underweighted. Keep every version for six years under §164.316; the superseded versions are how you prove the programme existed at any given moment. If you are starting from a blank page, the free risk assessment template provides the register structure and methodology skeleton, and a gap assessment can tell you whether your existing analysis would survive scrutiny.
What reviewers reject, in practice
Having read many risk analyses on both sides of the table, the rejections cluster predictably. The questionnaire wearing a register’s clothes: control questions answered yes/no, relabelled as “risks”, with no asset inventory attached — identifiable in under a minute. The borrowed register: threat entries for systems the organisation does not run, inherited from a template or another client, which tells the reviewer nobody read it. The orphaned analysis: a competent document with no visible connection to anything — safeguard choices, remediation tickets, budget decisions — suggesting it was produced for the shelf. And the frozen analysis: thorough, well-scored, and dated eighteen months before the incident under review, with a migration and two acquisitions in between.
What earns acceptance is almost boring by contrast: a stated methodology, an inventory a stranger could check against reality, scores that force a ranking, treatment decisions with names and dates on them, and a version trail showing the thing breathes. None of that requires sophistication; all of it requires the analysis to be a working document rather than a compliance performance. If yours would fail two or more of the tests above, that is worth knowing before someone else runs them — a gap assessment applies exactly this scrutiny with time to fix what it finds.
Where SuperHIPAA fits
Everything above is work. The platform does the parts that are mechanical — evidence collection, acknowledgement tracking, register maintenance, renewal reminders — and our team does the parts that need judgement. You keep the parts that need to be yours.
Start where you are
Take the free readiness assessment — 24 questions, about eight minutes, no call required. You get a scored report identifying which required specifications you are missing and what to fix first. If it turns out you are further along than you thought, we will tell you that too.