What Is a HIPAA Risk Assessment? (Complete 2026 Guide)

A HIPAA risk assessment — formally called a Security Risk Analysis (SRA) — is a mandatory requirement under the HIPAA Security Rule for every covered entity and business associate that creates, receives, maintains, or transmits electronic protected health information (ePHI). It is the foundational compliance activity that the Office for Civil Rights (OCR) cites most often in HIPAA penalty actions, and it’s the single most common deficiency identified in OCR audits.

This guide walks through what a HIPAA risk assessment is, the six-step process auditors expect to see, the three safeguard categories you have to evaluate, and what’s changing under the proposed 2026 Security Rule update.

The legal requirement, in one sentence

Under 45 CFR § 164.308(a)(1)(ii)(A), you must “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.” That’s the entire legal text. Everything else — methodology, scoring, documentation depth — is interpretive, with practical expectations set by OCR enforcement actions and the NIST SP 800-66 Rev. 2 implementation guide.

What “accurate and thorough” actually means

OCR has never published a prescribed methodology, but its enforcement actions and audit findings make the operational definition clear. Your SRA has to demonstrate that you:

  1. Identified every system that touches ePHI — EHR, billing, cloud storage, mobile devices, email, vendor systems, and physical media.
  2. Mapped how ePHI flows between those systems, including internal handoffs and external transmissions.
  3. Enumerated specific threats and vulnerabilities — not generic categories. “Ransomware” is a category; “unpatched Windows 10 workstations in the billing office without endpoint detection” is a threat.
  4. Scored each risk on likelihood and impact, typically Low / Moderate / High / Critical.
  5. Produced a risk management plan that ties each high-priority risk to a specific control, owner, and deadline.
  6. Documented everything in writing, with leadership sign-off and dated revisions.

If a security measure isn’t documented, OCR treats it as if it doesn’t exist. This is the single most common reason organizations fail an audit on a control they actually implemented.

The 6-step assessment process

The structure below mirrors NIST SP 800-30 Rev. 1 — the risk assessment methodology HHS explicitly references — adapted to the healthcare context.

Step 1 — Inventory and data mapping

List every device, software application, cloud service, and third-party vendor (business associate) that creates, receives, maintains, or transmits ePHI. Document data flows: where ePHI enters, where it sits at rest, where it leaves, and who has access at each stage.

A complete inventory typically includes:

Step 2 — Threat and vulnerability identification

For each ePHI-touching system, identify threats (what could go wrong) and vulnerabilities (weaknesses that could be exploited). Common categories:

Step 3 — Risk determination

For each threat-vulnerability pair, calculate likelihood and impact. Multiply (or matrix-combine) to produce a risk rating. A typical scoring scheme:

The 2026 Security Rule update (proposed in January 2025) signals that OCR wants quantitative risk ratings tied to NIST methodology, not narrative descriptions of “high concern.” Pure qualitative scoring is increasingly insufficient for audit defense.

Step 4 — Current safeguard assessment

For each identified risk, evaluate what controls are currently in place across the three HIPAA safeguard categories (detailed below). Be specific: “we have encryption” is not a control statement; “we have AES-256 encryption at rest on the EHR database via [vendor], and TLS 1.3 in transit, verified [date]” is.

Step 5 — Risk mitigation plan

Build a prioritized remediation plan. For each high-priority risk:

OCR’s recent enforcement signal is unambiguous: identifying a risk in an SRA is no longer enough. Covered entities must demonstrate actual remediation of identified high risks, with evidence. Risk management plans that sit unexecuted are themselves an audit finding.

Step 6 — Documentation, sign-off, and ongoing review

Compile findings, scoring methodology, and remediation plans into a formal report. Leadership reviews, dates, and approves. Review and update the assessment at minimum annually, and immediately following:

The three HIPAA safeguard categories

Your SRA must evaluate controls across all three categories. Missing one is itself a compliance gap.

Administrative safeguards

These are the policies, procedures, and workforce activities that govern how your organization handles ePHI:

Physical safeguards

These cover the physical environment where ePHI lives and the devices that access it:

Technical safeguards

These cover the technology controls that protect ePHI:

How often do you have to do this?

HIPAA doesn’t specify a frequency. Best practice — and OCR’s de facto expectation — is:

If your last SRA is more than 12 months old, you are out of compliance regardless of how thorough the previous one was.

What’s changing under the proposed 2026 Security Rule update

In January 2025, HHS published a Notice of Proposed Rulemaking that would substantially update the HIPAA Security Rule for the first time since 2013. The proposed changes most relevant to risk assessments:

The rule has not been finalized as of this writing, but the direction is clear: OCR wants more rigorous, more technical, more documented, and more frequent risk assessments. Practical implication for 2026 SRA work: build to the proposed standard now rather than retrofit later.

Doing a HIPAA risk assessment in practice

Three realistic paths:

1. The free HHS/ONC SRA Tool

The HHS Office of the National Coordinator for Health IT, in partnership with OCR, provides a free downloadable Security Risk Assessment Tool. It’s a Windows desktop application with a wizard-style questionnaire covering administrative, physical, and technical safeguards.

Best for: Solo practitioners and very small practices with zero compliance budget who need to demonstrate that a documented SRA was performed.

Limitations: It’s a standalone desktop tool. It doesn’t support cloud collaboration, multi-site aggregation, continuous remediation tracking, BAA management, or ongoing review workflow. The 156-question format produces a defensible baseline but does little to help you actually fix the gaps it identifies. Typical completion time: 20–60+ hours of internal staff time.

2. Build it internally

For organizations with a dedicated compliance officer and security analyst, an internally built SRA against NIST SP 800-66 Rev. 2 is workable. It requires custom spreadsheets, document templates, and a tracking mechanism for the remediation plan. The risk is consistency: a good internal SRA depends entirely on the rigor of the person doing it, and is hard to defend if the responsible person leaves.

3. Use purpose-built HIPAA SRA software

The market for HIPAA-specific SRA platforms has matured significantly since 2024. The strongest options combine:

Medcurity is one of the platforms in this category. See our Best HIPAA SRA Software 2026 comparison for an honest review of the market, including where Medcurity fits and where it doesn’t.

Common HIPAA risk assessment mistakes

Patterns we see repeatedly:

Frequently asked questions

Is a HIPAA risk assessment the same as a HIPAA audit? No. A risk assessment is something you do to yourself to identify and remediate risks. A HIPAA audit is performed by OCR (or a third party on OCR’s behalf) to verify your compliance program. Your risk assessment is one of the artifacts OCR will request during an audit.

Do business associates have to do their own SRA? Yes. Since the 2013 Omnibus Rule, business associates are directly liable under HIPAA and must perform their own SRA covering the ePHI they handle on behalf of covered entities.

What happens if we never did one? Failure to conduct an SRA is one of the most common HIPAA violations cited in OCR penalty actions. Settlement amounts for SRA-related deficiencies have ranged from approximately $25,000 to over $5,000,000 in recent enforcement, with the larger penalties typically reflecting a combination of failed SRA + downstream breach.

Does HIPAA require encryption? Under the current Security Rule, encryption is “addressable” — meaning you must either implement it or document a reasonable alternative. Under the proposed 2026 update, encryption at rest would become mandatory. In practice, modern healthcare organizations should treat encryption as required regardless of the current rule’s wording.

Can we use an SRA performed by our EHR vendor? Your EHR vendor’s SRA covers their systems, not yours. You can incorporate their relevant safeguards (and should request a copy as part of vendor due diligence), but your organization must produce its own SRA covering your environment, your workflows, and your vendor relationships in aggregate.

Where Medcurity fits

Medcurity is a healthcare-native HIPAA compliance platform built specifically around the SRA-as-program workflow described above. We provide guided NIST-aligned risk assessments, dynamic risk registers tied to remediation tracking, built-in BAA management, automated workforce training, and audit-ready reporting for OCR and HRSA operational site visits. Pricing starts at $499/year for the smallest practices and scales by site count and feature tier.

If you’d like to see how a structured SRA program runs end-to-end inside Medcurity, book a 20-minute demo or read our comparison of the Best HIPAA SRA Software for 2026.