A HIPAA security risk analysis is a documented, accurate, and thorough assessment of risks to the confidentiality, integrity, and availability of electronic protected health information (ePHI), required under 45 CFR § 164.308(a)(1)(ii)(A). Compliance means producing a written record that identifies threats, evaluates existing safeguards, and ties findings to a remediation plan with owners and deadlines. That record isn't a one-time deliverable. It needs updating whenever your systems, vendors, or operations change in ways that affect ePHI risk.
TL;DR:
- Conducting a HIPAA risk analysis requires a documented, up-to-date assessment covering all systems, devices, and vendors that handle ePHI, with regular updates after major changes.
- The analysis must evaluate threats, vulnerabilities, safeguards, and risk levels across administrative, physical, and technical controls to be considered thorough and compliant.
- Organizations must produce a version-controlled record with evidence of remediation actions and updates, as outdated or missing analyses increase enforcement risks.
- Using the ONC SRA tool is recommended for small to medium providers but may need supplementation for complex or multi-site healthcare operations.
- Risk scoring should be consistent, involves mapping threat likelihood and impact, and guides prioritized remediation with clear ownership and deadlines.
Table of Contents
- What Does the HIPAA Security Rule Actually Require?
- Who Has to Do This, and Why OCR Keeps Flagging It?
- How Do You Conduct a HIPAA Risk Analysis Step by Step?
- When Should You Use the ONC SRA Tool?
- How Do You Scope ePHI Across Systems and Vendors?
- How Do You Score Risk Likelihood and Impact?
- What Documentation Does OCR Expect to See?
- When Do You Need to Update Your Risk Analysis?
- Why Standard Tools Miss Biotech-Specific Risk
- A Compliance Officer's Take on What Actually Moves the Needle
- Sources
- FAQ
What Does the HIPAA Security Rule Actually Require?
The Security Rule applies to two groups: covered entities (health plans, providers, clearinghouses) and their business associates, and it covers ePHI wherever it lives, moves, or gets backed up. That means laptops, cloud EHR platforms, lab instruments that generate patient data, fax-to-email gateways, and the backup tapes sitting in a storage closet all fall inside scope.
The HHS guidance on risk analysis frames the obligation around one requirement: the analysis must be accurate and thorough. Regulators deliberately avoid prescribing a single methodology because organizations vary wildly in size and complexity. What doesn't vary is the expectation that your process actually finds the real risks, not just the obvious ones.
The Security Rule organizes required controls into three safeguard categories, and a defensible risk analysis touches all three:
- Administrative safeguards cover policies, workforce training, access management, and the security management process itself.
- Physical safeguards address facility access controls, workstation security, and device and media disposal.
- Technical safeguards include access controls, audit logs, encryption, and transmission security for ePHI in transit.
A risk analysis that only checks technical boxes while ignoring workforce training gaps or unlocked server rooms isn't accurate or thorough. It's incomplete, and OCR treats incomplete the same as missing.
Who Has to Do This, and Why OCR Keeps Flagging It?
Every covered entity and every business associate handling ePHI on their behalf has to conduct and document a risk analysis. A hospital system counts. So does the billing vendor it contracts with, the cloud EHR provider hosting its records, and the transcription service typing up physician notes. If ePHI touches your systems, the requirement applies to you.
OCR's enforcement history shows a consistent pattern: missing or outdated risk analyses show up repeatedly in resolution agreements and settlements. It's often the first thing investigators ask for after a breach report, and organizations that can't produce one, or produce a stale one from three reorganizations ago, face a materially worse enforcement outcome.
That's why the paper trail matters as much as the analysis itself:
- A dated, version-controlled risk analysis document with named owners for each finding.
- Evidence that remediation actually happened, not just got proposed.
- A record showing the analysis was updated after major changes, not frozen in time.
An analysis that exists only in someone's head, or in a slide deck nobody can find, doesn't help you in an audit.
How Do You Conduct a HIPAA Risk Analysis Step by Step?
NIST SP 800-66 Revision 2 maps a practical methodology to the Security Rule's requirements, and most defensible risk analyses follow some version of this six-step arc.
-
Define scope and inventory everything that touches ePHI. List every system, application, device, and physical location where ePHI is created, received, maintained, or transmitted. Ask: does this include remote work laptops? Cloud storage synced by staff? Medical devices that log patient data? If ePHI could pass through it, it belongs on the list.
-
Identify reasonably anticipated threats and vulnerabilities. Think beyond ransomware. Consider insider misuse, lost devices, unpatched software, third-party vendor breaches, and social engineering aimed at scheduling or billing staff.
-
Assess current safeguards and map the gaps. For each threat, check whether an administrative, physical, or technical control already mitigates it. Where none exists, or where the control is weak, that's a gap.
-
Rate likelihood and impact. A simple 3x3 matrix (low, medium, high on each axis) works for smaller organizations. A missing patch on an internet-facing server might score high likelihood and high impact; an outdated policy binder in a locked cabinet might score low on both.
-
Determine risk level and prioritize remediation. Multiply or combine likelihood and impact into an overall risk rating, then rank findings so the highest-risk gaps get addressed first, each with an assigned owner and a deadline.
-
Document methodology, evidence, and review cadence. Record how you conducted the analysis, who signed off, and when you'll revisit it.
Pro Tip: Build your risk matrix as a living spreadsheet, not a static PDF. When you close a remediation item, timestamp it and keep the original risk score visible next to the updated one. That before-and-after record is exactly what OCR investigators want to see.
When Should You Use the ONC SRA Tool?
The ONC/HealthIT Security Risk Assessment Tool is a free, government-built resource designed mainly for small and medium providers who need a structured starting point. It's available as a Windows desktop application and an Excel workbook, and it walks users through a branching questionnaire rather than a blank page.
The SRA Tool's user guide documents seven assessment sections covering SRA basics, policies and documentation, workforce, data and technical safeguards, practice and physical safeguards, vendor management, and contingency planning. Version 3.6.1 updated its risk scoring to align with NIST's scoring approach, and it can export a Risk Report you can attach to your compliance file as evidence.
Where it falls short: large health systems, multi-site biotech operations, or organizations running complex, custom clinical data pipelines outgrow the tool's generic questionnaire fast. A branching form built for a single-location clinic doesn't capture the risk of a distributed clinical trial data flow crossing multiple CROs and cloud environments. If your organization fits that description, treat the SRA Tool's output as a baseline, not the finished product, and supplement it with tailored threat modeling. Haiphai's related breakdown on how AI tools intersect with HIPAA controls covers this gap in more depth for organizations layering AI into clinical or regulatory workflows.
How Do You Scope ePHI Across Systems and Vendors?
Scoping starts with an honest inventory, and most organizations underestimate how much ePHI they actually touch. Walk through every device (workstations, tablets, mobile phones with clinical apps), every application (EHR, billing, lab information systems), every backup location, and every channel ePHI moves through, including email, fax, and API integrations with outside systems.
Vendors deserve their own line item. Every business associate handling ePHI needs a signed Business Associate Agreement (BAA), and you need a clear picture of what access each vendor actually has, not just what the contract says they should have.
A few fast, practical ways to build this out:
- Data-flow mapping: trace ePHI from the point it enters your organization to every place it's stored, processed, or sent.
- Interviews with system owners: the person who administers the scheduling software often knows about integrations that never made it into the official architecture diagram.
- Audit-log review: logs frequently reveal access patterns and third-party connections nobody flagged during the initial inventory.
Haiphai's guide to vendor qualification workflows walks through structuring this vendor-access review in more detail, which is useful once your BAA list grows past a handful of names.
How Do You Score Risk Likelihood and Impact?
Qualitative scoring (low, medium, high) works well for most healthcare organizations because it's fast, easy for non-technical stakeholders to understand, and defensible when documented consistently. Quantitative scoring, assigning dollar values or statistical probabilities to each risk, makes more sense for larger organizations with the data to support it, or for board-level risk reporting where financial exposure needs a number attached.
A simple 5x5 matrix covers most needs: rate likelihood from rare to almost certain, rate impact from negligible to severe, and plot each identified risk on the grid. A risk landing in the top right corner (high likelihood, high impact) becomes your top remediation priority regardless of how simple or expensive the fix is.
Once risks are scored, translate that ranking directly into action:
- Critical risks get an assigned owner, a deadline inside 30 days, and executive visibility.
- Moderate risks get scheduled into the next quarterly remediation cycle.
- Low risks get logged and revisited at the next full review, not ignored indefinitely.
The scoring method matters less than consistency. An assessment that rates similar risks differently across departments won't hold up to scrutiny.
What Documentation Does OCR Expect to See?
Your risk analysis file needs to function as a standalone evidence package, one that an auditor with zero prior context could review and understand. That means including the scope statement, the methodology you used, the full asset inventory, every threat-vulnerability pairing you identified, the likelihood and impact ratings, and the remediation plan with sign-offs from responsible staff.
Attach supporting artifacts wherever you have them:
- Vulnerability scan results and penetration test summaries.
- Signed BAAs for every vendor with ePHI access.
- Relevant security policies and workforce training logs.
- Prior risk analysis versions, so reviewers can see the progression over time.
Pro Tip: Timestamp every document version and keep a simple review log: date, reviewer name, what changed, and why. A one-page change log at the front of your risk analysis file saves auditors hours and saves you the headache of reconstructing history under pressure.
When Do You Need to Update Your Risk Analysis?
HHS and OCR don't set a fixed annual deadline for updates. Instead, the expectation is that you update your analysis whenever material changes affect ePHI risk. Waiting for a calendar date to roll around while your environment has already changed underneath you is exactly how organizations end up with a stale, non-compliant file.
Typical triggers that should prompt a fresh look include:
- A security incident or near-miss, even a minor one.
- Onboarding a new vendor or software platform that touches ePHI.
- A merger, acquisition, or major reorganization.
- Significant infrastructure changes, including new cloud migrations.
- Adopting AI tools into clinical, regulatory, or administrative workflows.
The most reliable governance model assigns a single accountable owner (often the compliance officer or CISO), builds risk analysis review into your change control process, and sets a baseline review cadence, commonly annual, as a floor rather than a ceiling.
Why Standard Tools Miss Biotech-Specific Risk
Generic risk assessment tools are built around a typical clinic's workflow: front desk, EHR, billing, maybe a lab interface. Biotech and life sciences organizations run something different entirely: clinical trial data pipelines crossing multiple CROs, lab instruments feeding raw data into regulated systems, and regulatory submissions that mix ePHI with proprietary research data. A questionnaire designed for a single-location practice won't surface the risk sitting inside a poorly governed data handoff between a clinical site and a central data repository.
Extending a standard risk analysis for this kind of environment means mapping workflow-specific threats directly: clinical data flows between sites and sponsors, lab instrument integrations, and regulated-data exchanges with contract research organizations. It also means embedding remediation into actual project backlogs with executive sponsorship, so fixes get built instead of shelved after the audit ends.
Standardized government tools give you a defensible floor, not a finished assessment. For an organization running distributed clinical trials or complex regulatory workflows, the risks that actually matter live inside the operational process, not the generic checklist.
Haiphai works with biotech and life sciences teams on exactly this gap: mapping operational bottlenecks that also happen to be security and compliance risks, and building governance around AI-enabled workflows so remediation sticks. The related piece on identifying operational risk across a biotech portfolio covers how this connects to broader operational risk management. Organizations building HIPAA-compliant web infrastructure alongside this work may also find Klyr Media's guide to compliant website workflows useful for technical safeguard planning.
A Compliance Officer's Take on What Actually Moves the Needle
Most organizations treat the risk analysis as a compliance chore to survive, not an operational asset. That's backwards. A well-built analysis that maps risks to actual workflows, with owners and deadlines attached, tells you exactly where your operational fragility lives, whether an auditor ever asks for it or not. Haiphai's work with biotech operations teams keeps surfacing the same lesson: findings that never get converted into prioritized, tracked remediation just become next year's audit finding again.
— John
This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.
Sources
FAQ
How often does HIPAA require a security risk analysis?
There's no fixed annual mandate. HHS and OCR expect you to update your risk analysis whenever material changes occur, including new vendors, infrastructure changes, mergers, AI adoption, or security incidents, with most organizations also setting a baseline annual review as a floor.
What is the new HIPAA rule in 2026?
HIPAA's core Security Rule requirements, including the mandate for an accurate and thorough risk analysis under 45 CFR § 164.308(a)(1)(ii)(A), remain the governing standard; organizations should monitor HHS.gov directly for any proposed rule updates rather than relying on secondhand summaries.
What is a HIPAA security risk analysis?
It's a documented, accurate, and thorough assessment of risks and vulnerabilities to the confidentiality, integrity, and availability of all ePHI an organization creates, receives, maintains, or transmits, required under federal law.
What are the three major safeguard categories in HIPAA?
Administrative safeguards, physical safeguards, and technical safeguards. A defensible risk analysis evaluates threats and vulnerabilities across all three, not just one.