The risk assessment is the foundational requirement of the Security Rule and the first document OCR requests after an incident.
What the rule requires
45 CFR §164.308(a)(1)(ii)(A) requires an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI held by the organisation.
Three things follow from that sentence that shape everything else on this page. First, it is a required implementation specification — not addressable, not scalable away, applicable to a two-person telehealth startup and a hospital system alike. Second, “held by the organisation” scopes the exercise to all of your ePHI, wherever it sits: production databases, backups, analytics pipelines, laptops, email, and vendor systems processing on your behalf. Third, it is the foundation the rest of the Security Rule builds on — your safeguard decisions, including every addressable-specification rationale, are supposed to trace back to what the assessment found. That is why it is the first document OCR requests: without it, none of your other choices have a documented basis.
The nine steps
Scope the ePHI. Inventory assets and data flows. Identify threats. Identify vulnerabilities. Assess current controls. Determine likelihood. Determine impact. Determine risk level. Document and plan treatment.
In slightly more operational detail:
- Scope the ePHI. Write down every place ePHI is created, received, stored, or transmitted. Interview engineers and operations staff — the documented architecture always misses the exports, the test databases, and the shared drive.
- Inventory assets and data flows. For each system: what it holds, who accesses it, what it connects to, which vendor runs it. This inventory is the most labour-intensive step and the substrate for everything after.
- Identify threats. Human (phishing, insider misuse, lost devices), technical (ransomware, credential stuffing, misconfiguration), environmental (fire, outage). Pair threats to assets — generic threat lists floating free of systems are the mark of a template exercise.
- Identify vulnerabilities. Missing MFA, unencrypted laptops, stale accounts, no backup testing, vendors without BAAs.
- Assess current controls. What already mitigates each threat–vulnerability pair. Credit yourself accurately; the point is residual risk.
- Determine likelihood and 7. impact, using defined scales with written level definitions.
- Determine risk level — the combination that produces your ranked register.
- Document and plan treatment. For each risk: mitigate with an owner and a date, or accept with a signed rationale and a review date. This plan is the required risk management companion at §164.308(a)(1)(ii)(B).
Assessment versus analysis
The rule says ‘risk analysis’. Most people say ‘risk assessment’. They are used interchangeably in practice; what matters is that the output is asset-based, threat-paired, scored, and documented — not a questionnaire score.
The terminology confusion has one genuinely dangerous variant: mistaking a compliance questionnaire — or the four-factor breach assessment, which shares the name — for this requirement. A questionnaire tells you which controls you claim to have; a risk analysis tells you what threatens your actual data given your actual systems. Reviewers distinguish them in about a minute, because a questionnaire output has no asset inventory attached. The methodology deep-dive — choosing a framework, defining scales, documenting accepted risk — lives in the companion risk analysis guide.
Common failures
Scoping to the EHR only. Skipping the asset inventory. No documented methodology. No rationale for accepted risks. Never updated after a material change.
Each of these has a signature. EHR-only scoping shows up as a register with no mention of email, backups, or endpoints — instantly implausible for any real organisation. The missing inventory shows up as threats without systems attached. The missing methodology shows up when a reviewer asks “why is this a medium?” and the answer is a shrug. Silent risk acceptance shows up as register items that appear in year one and are never mentioned again. And staleness shows up as an assessment dated before the migration, the acquisition, or the incident everyone in the room remembers. The common root cause is treating the assessment as a deliverable to be filed rather than a register to be governed — which is also why the fix is structural (ownership and a calendar) rather than heroic (a better one-off document).
How often to redo it
The rule requires periodic review. In practice: annually, plus after any material change to systems, vendors, workforce structure, or after any incident.
“Redo” overstates it after the first cycle. The initial assessment is the expensive one because the inventory starts from nothing; subsequent cycles update the inventory, re-score what changed, and re-visit the accepted risks whose review dates have arrived. An annual refresh on a maintained register is a fraction of the original effort — and the version history it produces, retained six years under §164.316, is itself evidence that the programme runs continuously rather than being reconstructed before audits.
Doing it yourself versus buying it
A first assessment is genuinely doable in-house for a small organisation: the free risk assessment template provides the register structure and scales, and your own engineers know the systems better than any consultant will. The honest case for outside help is calibration and credibility — an experienced assessor has seen where organisations like yours actually fail, and enterprise customers sometimes weight independent work more heavily. If you want a reality check before deciding, the free readiness assessment will tell you whether the risk analysis is even your biggest gap, and the gap assessment service pairs naturally with a first formal analysis since both share the inventory.
A worked example, briefly
To make the nine steps concrete: a 20-person telehealth company scopes its ePHI and finds it in six places — the EHR, the video platform, email, an analytics warehouse, engineer laptops, and backups. The inventory records each system’s owner, vendor, and BAA status, and immediately surfaces the first finding: the analytics warehouse has no BAA. Threat pairing puts phishing against email, ransomware against backups, lost devices against laptops. Control assessment credits MFA on the EHR but not the warehouse, and full-disk encryption on managed laptops but not the two contractors’ personal machines. Scoring ranks the unencrypted contractor laptops and the BAA gap as the top risks — neither of which is what the team expected, which is precisely the value. Treatment: BAA chased this week, contractor devices enrolled or excluded this month, warehouse MFA this quarter, and the residual email risk accepted with a signed rationale and a review date. Total effort: one focused week, most of it interviews. The document that results is short, specific, and defensible — thoroughness is about coverage, not page count. Next year’s refresh starts from this register, takes a fraction of the time, and produces the version trail that proves the programme runs.
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.