HIPAA Risk Assessment: The 2026 Step-by-Step Guide

Risk analysis vs. risk management vs. gap assessment

The words people use interchangeably are three different things under the Security Rule, and OCR settlements repeatedly turn on the confusion. A HIPAA risk analysis identifies and rates the risks to ePHI. Risk management is the separate, also-required step of actually reducing those risks. A gap assessment is a useful internal exercise — but it is not what the regulation names, and on its own it does not satisfy the standard.

OCR’s own Guidance on Risk Analysis is explicit that the analysis (a)(1)(ii)(A) and risk management (a)(1)(ii)(B) are separate requirements. Getting the vocabulary right in your documentation matters, because auditors and OCR investigators look for both artifacts by name.

Is a HIPAA risk assessment legally required?

Yes — unambiguously. The risk analysis sits inside the Security Management Process standard at 45 CFR 164.308(a)(1)(i), and it is one of that standard’s required implementation specifications. Unlike addressable specs (where you may implement an equivalent alternative and document why), a required spec must be performed. The general requirements at 45 CFR 164.306(a) frame the whole obligation: protect the confidentiality, integrity, and availability of all ePHI you create, receive, maintain, or transmit.

Three points founders and compliance leads consistently get wrong:

• There is no “HIPAA certification.” HHS does not certify or endorse compliance. You conduct the analysis yourself (optionally with a CPA or security firm), and it produces internal evidence — not a certificate. Any vendor selling a “HIPAA certified” badge is describing their own attestation, not a government seal.
• Business associates are directly liable. Since the 2013 Omnibus Rule, business associates — SaaS, cloud, and IT vendors that create, receive, maintain, or transmit ePHI — must conduct their own risk analysis, independent of their covered-entity customers, and sign a business associate agreement (BAA).
• It is not a one-time deliverable. Under 45 CFR 164.316, Security Rule documentation must be retained for six years from creation or last effective date, and the analysis must be reviewed and updated periodically and in response to environmental or operational change.

The nine required elements of a compliant risk analysis

The regulation says conduct an accurate and thorough assessment but does not prescribe a methodology. OCR’s 2010 Guidance on Risk Analysis Requirements fills that gap with nine elements every compliant analysis must contain. That guidance is 16 years old but remains operative; the current implementation companion is NIST SP 800-66 Revision 2 (Feb 2024), which maps each Security Rule spec to NIST CSF subcategories and SP 800-53r5 controls.

How to conduct a HIPAA risk assessment — six practical steps

OCR describes nine elements; in practice they group into six steps. We reconcile both here so your documentation maps cleanly to the guidance while your project plan stays workable. Steps 8 (document) and 9 (review) are continuous and run through every step below.

Step 1 — Define scope and build the ePHI asset inventory & data-flow map

(OCR elements 1–2.) Start by listing every place ePHI is created, received, maintained, or transmitted: production databases, backups, log stores, email, ticketing systems, laptops, mobile devices, SaaS subprocessors, and cloud object storage. Draw a data-flow map showing how ePHI moves between them and across trust boundaries. Scope errors are the most expensive mistake — a missed S3 bucket or an unmanaged laptop is exactly where breaches originate. The 2025 NPRM would make a written asset inventory and network map explicit, so building them now is future-proofing, not busywork.

Step 2 — Identify threats and vulnerabilities to ePHI

(OCR element 3.) Use the NIST SP 800-30 Rev. 1 threat-source taxonomy — adversarial (external attackers, malicious insiders), accidental (user error, misconfiguration), structural (equipment or software failure), and environmental (power loss, natural disaster). Pair each threat source with the vulnerabilities it could exploit: an unencrypted laptop (vulnerability) exposed to theft (adversarial threat); a misconfigured storage bucket exposed to internet scanning; a phishing email leading to EHR credential theft.

Step 3 — Document current security measures

(OCR element 4.) For each threat/vulnerability pair, record the safeguards already in place across all three HIPAA safeguard categories — administrative, physical, and technical. This is the point where a HIPAA technical safeguards checklist is useful: this page is the assessment (identifying and rating risk), while that page covers the control implementation that reduces it.

Step 4 — Rate likelihood and impact

(OCR elements 5–6.) Using a defined scale (see the scoring model below), rate how likely each threat is to exploit each vulnerability, and how severe the impact on the confidentiality, integrity, or availability of ePHI would be if it did. Rate residual likelihood and impact — that is, with your current controls from Step 3 already accounted for.

Step 5 — Determine and prioritize the level of risk

(OCR element 7.) Combine likelihood and impact into a single risk rating and sort. High-likelihood, high-impact risks to ePHI go to the top of the remediation queue. The output of this step is your risk register.

Step 6 — Document, treat, and review

(OCR elements 8–9, plus the handoff to risk management.) Write the analysis up, retain it for six years, feed the rated risks into your risk-management plan (Step below), and schedule the review cadence. Auditsuisse follows this exact sequence — see our audit methodology for how we run it.

The scoring model — likelihood × impact

HIPAA does not mandate a scoring formula, so a defensible analysis borrows one from NIST SP 800-30 Rev. 1 (the canonical guide for conducting risk assessments) and NIST SP 800-66r2. The workhorse is a qualitative Likelihood × Impact matrix. A 3×3 matrix is the simplest defensible version; a 5×5 gives more granularity and is what most compliance platforms use. On a 1–5 scale, Risk = Likelihood × Impact, producing a 1–25 score with common bands of 15–25 High, 8–14 Medium, 1–7 Low.

Whatever scale you choose, the two rules that matter are: define each level in writing (so ratings are repeatable), and rate residual risk after existing controls. The exact numeric bands are a business decision — document yours in the analysis so an auditor sees the method, not just the result.

Sample HIPAA risk register (worked example)

A risk register is the primary output artifact of the analysis. Below is a worked example using the 1–5 × 1–5 model above, mapping each risk to a 45 CFR safeguard and a treatment decision (accept, mitigate, transfer, or avoid). Walk one row end-to-end: R-002 — a developer laptop (asset) holding a local ePHI export (vulnerability) is exposed to theft (adversarial threat); the only existing control is a screen lock; likelihood 4, impact 5 → score 20 (High); treatment is to mitigate via full-disk encryption and remove local exports, mapped to 45 CFR 164.312(a)(2)(iv), owned by the CISO with a near-term target date.

Auditsuisse provides clients a working risk-register template as part of an engagement; you can also reproduce the structure above in any spreadsheet. To reuse the same rows across frameworks, see how to map HIPAA controls to SOC 2 and GDPR.

From analysis to risk management: the remediation plan

The risk analysis is only half the requirement. 45 CFR 164.308(a)(1)(ii)(B) — risk management — requires you to “implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level.” In practice, this is your remediation plan: each High and Medium risk from the register gets a treatment decision, an owner, a target date, and a mapped safeguard. “Reasonable and appropriate” is scaled to your size, complexity, and capabilities — a two-person startup and a hospital system are held to the same standard but not the same controls.

Document your treatment rationale, especially for accepted risks. If you accept a Low risk rather than mitigate it, write down why — that documented decision is itself evidence of due diligence. Re-run the loop on material change: a new subprocessor, a merger, a new ePHI data flow, or a security incident all trigger a refresh of the affected rows.

What OCR looks for — enforcement and the cost of skipping the SRA

The absence of an accurate, thorough risk analysis is among the most commonly cited deficiencies in OCR resolution agreements. Several of the largest HIPAA settlements name it explicitly — for example, the Anthem settlement ($16 million, 2018), Premera Blue Cross ($6.85 million, 2020), and Excellus Health Plan ($5.1 million, 2021) all cited failures tied to risk analysis and risk management among other findings. These are published on the OCR resolution-agreements page.

Enforcement typically begins with a breach. Under the Breach Notification Rule (45 CFR 164.400–414), breaches affecting 500 or more individuals must be reported to HHS without unreasonable delay and no later than 60 days, and are posted publicly on the OCR breach portal — which is frequently where an investigation starts. For the breach-handling side, see our guide to HIPAA incident response and breach notification requirements.

Civil money penalties are tiered by culpability under 42 USC 1320d-5 and 45 CFR 160.404, and the dollar figures are inflation-adjusted every January under 45 CFR 102.3. Because they change annually, always confirm the current amounts against the latest Federal Register notice before relying on them.

The figures above reflect the January 28, 2026 inflation adjustment (per-violation minimum $145; annual cap $2,190,294 per identical provision). Tier maximums must be pulled fresh from the current 45 CFR 102.3, because they are re-indexed each January and the older “$100–$50,000 / $1.5M” figures you may see elsewhere are the pre-inflation statutory floor and ceiling.

What is changing in 2026 — the HIPAA Security Rule NPRM

On January 6, 2025, OCR published a Notice of Proposed Rulemaking (NPRM) to modernize the Security Rule (90 FR 898, RIN 0945-AA22). The comment period closed March 7, 2025, and OCR received over 4,700 comments. As of this article’s publication, the rule is proposed — not final — and no final rule has been issued. Confirm current status at reginfo.gov (RIN 0945-AA22) and the HHS NPRM page before making commitments based on it. Every provision below is proposed, not current law.

How to prepare without over-committing: build the written asset inventory and network map now, treat encryption and MFA as if required (most enterprise buyers already do), and keep your risk analysis written and versioned. None of that is wasted effort if the rule changes shape in finalization.

Tools and shortcuts — the SRA Tool, SOC 2, and pen testing

HHS and ONC offer a free downloadable Security Risk Assessment (SRA) Tool at HealthIT.gov. It walks you through a structured, multi-section questionnaire and is a reasonable starting point — but it is designed with smaller organizations in mind, and using it does not by itself produce a compliant analysis. For a SaaS business associate with cloud infrastructure, multiple subprocessors, and a real threat surface, the tool’s questionnaire rarely captures the asset inventory, data-flow mapping, and residual-risk scoring depth that a defensible analysis requires.

Three adjacent activities are frequently mistaken for the risk analysis. They are inputs, not substitutes:

• A SOC 2 report examines controls against the Trust Services Criteria — overlapping but not identical scope. It does not assess risks to ePHI specifically, and it is not documented as a HIPAA risk analysis. If your buyers ask for both, plan a SOC 2 audit alongside, not instead of, the SRA.
• A penetration test surfaces technical vulnerabilities only. It feeds Step 2 of the analysis but ignores administrative and physical safeguards entirely. Treat penetration testing as one threat-identification input.
• HITRUST CSF can be mapped to the Security Rule and reduce duplicate effort, but certification against HITRUST is not the same as performing and documenting the 164.308(a)(1)(ii)(A) analysis.

HIPAA risk assessment checklist

• Scope covers all ePHI — every system, device, medium, and subprocessor (elements 1–2).
• ePHI asset inventory and data-flow / network map are written down.
• Threats catalogued across adversarial, accidental, structural, and environmental sources (element 3).
• Existing administrative, physical, and technical safeguards documented per risk (element 4).
• Likelihood and impact rated on a defined, written scale; residual risk scored (elements 5–7).
• Risk register produced and prioritized High → Low.
• Risk-management / remediation plan created with owners and target dates (164.308(a)(1)(ii)(B)).
• Analysis written, signed, and retained for six years (164.316).
• Review cadence set; refresh triggered on material change (element 9).
• BAAs in place with every subprocessor that touches ePHI.

Glossary of key terms

• ePHI — electronic protected health information; individually identifiable health information created, received, maintained, or transmitted in electronic form.
• Risk analysis — the required assessment (45 CFR 164.308(a)(1)(ii)(A)) that identifies and rates risks to ePHI.
• Risk management — the required activity (164.308(a)(1)(ii)(B)) of implementing measures to reduce identified risks.
• Likelihood — the probability that a threat exploits a vulnerability, rated on a defined scale.
• Impact — the severity of harm to the confidentiality, integrity, or availability of ePHI if a risk is realized.
• Addressable vs. required — current implementation-spec categories under 45 CFR 164.306(d); the 2025 NPRM proposes to remove the distinction.
• Business associate — a vendor that handles ePHI on behalf of a covered entity; directly liable under the Security Rule and bound by a BAA.