HIPAA Security Risk Assessment: What It Requires and How to Run One

A HIPAA risk assessment is a required, enterprise-wide analysis of the risks to electronic protected health information your organization creates, receives, maintains, or transmits. The Security Rule calls it a "risk analysis," makes it mandatory at 45 CFR § 164.308(a)(1)(ii)(A), and grants no exemption for small practices. It is a recurring process, not a one-time project.

Does HIPAA require a risk assessment?

Yes. Risk analysis is a Required implementation specification under the HIPAA Security Rule at 45 CFR § 164.308(a)(1)(ii)(A). If your organization creates, receives, maintains, or transmits ePHI in any form, you must conduct one, and the rule leaves very little room to argue otherwise.

The obligation covers every covered entity (providers, health plans, and clearinghouses) and every business associate. Billing companies, cloud hosts, EHR vendors, transcription services, telehealth platforms, and IT providers all sit inside the requirement. A solo practice in a small West Texas town carries the same obligation as a multi-hospital system. There is no size threshold, no revenue floor, and no "we're too small to be a target" exception written anywhere in the regulation.

It reaches further than most organizations assume. In June 2026, OCR settled with the employer-sponsored group health plan of a national novelty retailer, not a healthcare company at all, for $450,000 following a ransomware attack on 10,023 plan members. If you sponsor a group health plan, that plan is a covered entity with its own risk analysis obligation, separate from anything clinical you do.

The scope follows the data, not the building. If ePHI lives in a cloud EHR, moves through a personal laptop at a physician's kitchen table, or sits in a vendor's data center three states away, it is in scope.

Risk analysis, risk assessment, and breach risk assessment are three different things

Two of these terms mean the same thing. The third does not, and conflating it with the others is a recurring and expensive mistake.

The gap between the first row and the third is where organizations get cited. A clinic's risk analysis identifies that staff reuse passwords across the cloud EHR and the practice management system, and rates it high likelihood, high impact. Risk management is what happens next: enabling MFA, tightening the password policy, assigning an owner and a date. OCR has repeatedly penalized organizations that documented the finding and never acted on it, and has since expanded its enforcement focus to cover risk management explicitly, not just the analysis.

Where the requirement comes from

The Security Management Process standard at 45 CFR § 164.308(a)(1) is the anchor. Risk analysis is a Required implementation specification, which is a formal term in HIPAA. Unlike "Addressable" specifications, there is no path where you document a reasonable alternative and move on.

Several neighboring provisions depend on it directly:

The regulation is deliberately technology-neutral. It tells you what to achieve, not what to buy. HHS guidance and NIST SP 800-66 Revision 2 (February 2024) describe what "accurate and thorough" tends to look like in practice.

What the proposed Security Rule update changes, and why it does not change what you owe today

In the Fall 2026 Unified Agenda, HHS moved the proposed Security Rule amendments (RIN 0945-AA22) to its Long-Term Actions list, with anticipated final action in July 2027, roughly a year later than the May 2026 target that had been widely circulated. The proposal itself is unchanged. It has simply moved further out.

The timeline, for context: OCR issued the Notice of Proposed Rulemaking in December 2024, published it in the Federal Register on January 6, 2025, and closed comments on March 7, 2025 with close to 5,000 submissions, many of them from provider organizations arguing the requirements were too costly to implement on the runway offered. HHS has not publicly explained the move to Long-Term Actions.

Two things follow, and they point in opposite directions from how the delay is usually reported.

Nothing was rolled back. The proposed amendments were never in force. The existing Security Rule remains fully enforceable exactly as it was, and it is what OCR is actively enforcing right now. A delay in future requirements is not a pause in current ones.

The direction of travel is clear enough to build toward. The proposal would largely eliminate the addressable and required distinction, make multi-factor authentication and encryption at rest and in transit mandatory, require network segmentation, and set explicit testing intervals. Those are already recognized as baseline practice, and OCR is penalizing organizations that lack them under today's standards. The extra year is runway for budgeting and sequencing, not a reason to defer.

Worth separating from all of this: the HIPAA Privacy Rule update is a different rulemaking, is targeted for August 2026, and is moving ahead. The thing that slipped is not the thing arriving soonest.

Who owns this internally?

HIPAA requires you to designate a Security Officer under § 164.308(a)(2). It does not tell you who runs the risk analysis.

In most organizations, the Security Officer leads it with IT, and pulls in the Privacy Officer and Compliance Officer for the administrative safeguards and vendor questions. In a ten-provider practice, that may be two people wearing four hats, one of whom also manages the front desk. In a multi-hospital system, it is a standing cross-functional team with a project plan and an executive sponsor.

The requirement is identical in both cases. The execution differs enormously.

You can bring in outside expertise to perform or support the analysis, and most organizations do, particularly for technical assessment work and data flow mapping. What you cannot outsource is accountability. If the scope was drawn too narrowly, or a system was left out, OCR holds the covered entity or business associate responsible for that decision, not the firm that helped run the workshop.

What has to be in scope?

All ePHI, everywhere, including systems that do not store it but control access to it.

That second half is where most incomplete assessments go wrong. Concretely, in scope means:

• Clinical and business systems: EHR and EMR, practice management, billing and revenue cycle, scheduling, reporting and analytics
• Communication: email, secure messaging, patient portals, telehealth, SMS solutions, fax servers
• Storage: file servers, NAS and SAN, on-premises and cloud databases, SharePoint, OneDrive, Google Workspace, imaging archives and PACS
• Endpoints: laptops, desktops, tablets, smartphones, workstations on wheels, connected medical devices
• Backup and recovery: backup appliances, replication targets, offsite media, cloud backup
• Access and remote work: VPNs, remote desktop gateways, identity platforms, SSO, MFA, MDM
• Infrastructure that gates access: Active Directory, firewalls, wireless controllers. These hold no ePHI and control all of it.
• Third parties: cloud hosting, transcription, imaging, reference labs, clearinghouses, IT support, managed security, and their subcontractors

Recurring scoping failures worth checking for specifically: legacy applications nobody has logged into in three years but that still hold records, practices acquired mid-cycle and never folded into the inventory, home offices, and vendor-hosted environments assumed to be "the vendor's problem."

What are the five things a risk assessment must include?

Every HIPAA risk assessment, regardless of organization size, has to contain five things:

1. A defined scope covering all ePHI: every system, site, device, and vendor that creates, receives, maintains, or transmits it
2. An inventory of ePHI and its data flows: where the data lives, how it moves, and who touches it along the way
3. Identified threats and vulnerabilities: documented against specific systems, not described generically
4. An evaluation of current safeguards: administrative, physical, and technical, assessed as implemented rather than as written
5. A risk rating for each finding, with documented rationale: likelihood and impact combined on a consistent, stated scale

Those five are the minimum a reviewer will look for. OCR's own risk analysis guidance breaks the same work into nine elements, adding data collection, likelihood and impact as separate determinations, final documentation, and periodic review. The eight-step process below covers all nine and adds the step that follows the assessment itself, which is turning findings into a risk management plan, which the Security Rule requires separately at § 164.308(a)(1)(ii)(B).

How to do a HIPAA risk assessment

Eight steps. The sequence matters more than the tooling.

Step 1: Define scope and objectives in writing

Write down what the assessment covers before anyone opens a spreadsheet. A usable scope statement names the period, the legal entities and affiliates, the physical sites including home offices and data centers, and the systems and cloud services that handle or provide access to ePHI. Something on the order of: "Calendar year 2026, all clinical, administrative, and remote locations across Texas and New Mexico, including the cloud EHR and all connected interfaces."

State the objectives too, because they change what evidence you gather. Meeting the Security Rule baseline is one. Preparing for an OCR inquiry, satisfying a payer security review, or supporting a Promoting Interoperability attestation are others, each with its own documentation expectations.

Assign an executive sponsor and a cross-functional team (IT, compliance, clinical leadership, operations) and agree on a timeline.

Step 2: Inventory ePHI systems and map data flows

You cannot assess risk to data you have not located. Build or refresh a complete asset inventory covering system name, business owner, hosting location, type and volume of ePHI, criticality, and connected vendors.

Then find the systems that are not on anyone's list. Shadow IT surfaces through interviews and network discovery, not through asking IT what they run. Look for ad-hoc file shares, an unsanctioned cloud storage account a department opened during a go-live, a messaging app a care team adopted because the sanctioned one was slow.

Data flow mapping is the part organizations skip and OCR notices. Follow ePHI from intake, including registration, referrals, and HL7 and FHIR interfaces, through treatment, billing, reporting, and finally archival and destruction. Note where data physically rests, including cloud regions, and identify every business associate and subcontractor along the path.

Incomplete inventories and missing data flows are among the most common pieces of evidence that a risk analysis was not, in fact, enterprise-wide.

Step 3: Identify threats and vulnerabilities

A threat is any circumstance or event with the potential to adversely affect ePHI. A vulnerability is a weakness a threat could exploit. NIST SP 800-30 Revision 1 is the standard reference for both.

• External: phishing and business email compromise, ransomware, credential stuffing, unpatched VPN and remote access appliances, cloud misconfiguration
• Internal: excessive access rights, departed staff whose accounts stayed live, improper media disposal, unmanaged personal devices
• Environmental: fire, flooding, tornadoes and severe weather, extended power loss, HVAC failure in a server room
• Process: missing or unenforced policies, no access review cadence, no termination checklist, no vendor due diligence

Ground the list in real activity. OCR's breach reporting, CISA and FBI advisories, and your own incident and helpdesk logs will tell you more than a generic threat catalog. Document threats against specific systems and data flows. "Unencrypted external backup drive stored in the supply closet at the Slaton clinic" is a finding. "Backup risk: medium" is not.

Step 4: Evaluate the safeguards you already have

Organize around the Security Rule's three safeguard families, and assess each one twice. Does it exist on paper, and is it actually operating?

Partial implementation is a finding in its own right and should be recorded as one. Disk encryption on laptops purchased after a certain date, with the older fleet unaccounted for, is not "encryption implemented."

Vulnerability scans and penetration tests feed this step. They do not replace it. Neither one evaluates whether your termination process actually revokes access.

Step 5: Analyze likelihood, impact, and risk level

For each threat and vulnerability pair, evaluate how likely it is that the threat exploits the vulnerability, and what the impact would be if it did.

Impact is broader than a fine. Consider confidentiality, integrity, and availability, then patient safety, clinical operations, and legal and financial exposure. A ransomware event that takes the EHR offline for six days is an availability and patient safety problem before it is a compliance problem.

Use a consistent, documented scale (low, medium, high or 1 to 5 both work) and a documented method for combining the two. A qualitative matrix is entirely acceptable. You are not required to build a quantitative model, and a simple 5 by 5 matrix applied consistently will hold up better than an elaborate one applied unevenly.

• Unencrypted laptop used by a provider traveling between three clinics weekly: high likelihood, high impact, high risk
• Isolated archive system, no network path, limited historical ePHI, tested backups: low likelihood, low impact, low risk

Tie every significant risk to a named asset or data flow. "Email risk = medium" tells a reviewer nothing.

Step 6: Document findings in an audit-ready report

The report is the artifact that survives. If OCR, a payer, or an acquirer asks what you knew and when, this is what you hand them.

A defensible report contains an executive summary readable by a board; the methodology, including frameworks and scales used; scope and assumptions, with exclusions and the reason for each; the ePHI inventory summary and data flow diagrams; threats, vulnerabilities and existing safeguards per system; risk ratings with rationale; and prioritized remediation recommendations.

That rationale requirement is the one that gets underestimated. A reviewer wants to see why a risk was rated low, not merely that it was. Scores without reasoning read as reverse-engineered.

Retain the documentation for at least six years from creation or last effective date, per § 164.316(b)(2)(i). Keep appendices covering system detail, diagrams, policy excerpts, and configuration evidence, organized well enough to produce quickly under pressure.

Step 7: Convert findings into a risk management plan

The analysis is the starting point. § 164.308(a)(1)(ii)(B) requires you to act on it, and OCR has expanded its enforcement focus to look specifically for evidence that identified risks were prioritized and remediated.

A workable plan includes a prioritized remediation list driven by risk level, a named owner for each item, target dates, dependencies, and the specific safeguard being added.

Worked example: the analysis finds an unsupported Windows Server hosting an imaging archive. The plan lays out a phased migration to a supported platform, interim network segmentation to limit exposure while that work happens, and accelerated backup restoration testing in the meantime. Three actions, one risk, dated and owned.

Not every risk gets mitigated. Responses can include transfer (cyber insurance, contractual allocation), avoidance (retiring the system), or acceptance. Accepted risks are legitimate, but they must be explicitly documented with the justification and the approver. Silent acceptance is indistinguishable from oversight.

Step 8: Make it an ongoing process

The Security Rule requires a periodically updated process, reinforced by § 164.308(a)(8), which calls for periodic evaluation in response to environmental and operational change.

An annual cycle is the practical norm and what most payers and reviewers expect. But the rule is triggered by events, not the calendar. Update the analysis when you deploy a new cloud EHR or telehealth platform, after a merger, acquisition, relocation, or significant network redesign, and following any serious security incident.

Between full cycles, a lightweight quarterly or semi-annual review keeps the document current: track remediation progress, evaluate new threats and newly adopted technology, and adjust risk levels as controls land.

What this means for MIPS and Promoting Interoperability

For clinicians and groups in the Merit-Based Incentive Payment System, the Security Risk Analysis measure sits inside the Promoting Interoperability performance category, which carries 25% of the MIPS final score. The measure itself is unscored, but failing any component of it zeroes the entire category regardless of performance on every other measure. It is a scoring cliff, not a deduction.

The 2026 performance year raised the bar in a way worth noting, because it mirrors exactly where OCR enforcement has moved. Attestation is now effectively dual: clinicians confirm they conducted or reviewed a risk analysis under § 164.308(a)(1)(ii)(A) and attest to having conducted risk management activities under § 164.308(a)(1)(ii)(B) to mitigate what the analysis found. Documenting the risk is no longer enough for the attestation, just as it is no longer enough for OCR.

Clinicians must also complete an annual self-assessment against the High Priority Practices SAFER Guide, marking each practice fully, partially, or not implemented, and submit a positive attestation to earn any points in the category. Two further attestations cover acting in good faith not to limit the interoperability of certified health IT, and cooperating with ONC direct review.

The analysis must be conducted or reviewed within the calendar year of the performance period.

How is this different from a vulnerability scan, pen test, or SOC 2 report?

All three are inputs. None is a substitute.

Consider a hospital with annual external penetration tests and a SOC 2 Type II certified EHR vendor that has never documented how ePHI flows into its in-house reporting tools and local imaging archive. Strong technical hygiene, real third-party assurance, and an incomplete risk analysis, because two entire data flows were never assessed.

Feed all three into the risk analysis as evidence, inside a governance view that covers what they do not.

What happens if you skip it

Failure to conduct an accurate and thorough risk analysis is the single most frequently cited finding in OCR's enforcement actions. OCR launched a dedicated Risk Analysis Initiative in October 2024, and the June 2026 settlement described above was its fourteenth enforcement action, alongside a two-year corrective action plan requiring the organization to conduct a proper risk analysis, rewrite its policies, and retrain its workforce under federal oversight.

That case is instructive for two reasons beyond the dollar figure. The breach was in November 2021; the settlement landed in June 2026. And the penalty was substantial relative to a population of just over 10,000 people. OCR priced the compliance failure, not the breach size.

The financial penalty is rarely the expensive part. Corrective action plans run multiple years with monitored reporting. Payer and regulator scrutiny increases. Legal and forensic costs following a breach frequently dwarf the fine, and incident response pulls clinical and IT staff away from operations for weeks.

The more useful framing is not enforcement at all. The findings in a serious risk analysis, such as no email encryption, RDP exposed to the internet, or backups that have never been restore-tested, are the same findings that show up in the post-incident report six months later. The assessment is simply the cheaper place to discover them.

Should you use the free HHS SRA Tool?

Yes, with clear eyes about what it is.

The Security Risk Assessment (SRA) Tool is published jointly by ONC and the HHS Office for Civil Rights, free, as a Windows desktop application and an Excel workbook. It walks users through structured questions mapped to Security Rule requirements and helps smaller organizations identify where ePHI lives and where obvious gaps sit.

Where it works: a starting point or sanity check for a solo practice or small clinic; a structured way to get non-technical staff into the conversation; one input among several for a larger organization.

Where it falls short: it is entirely self-guided, so output quality equals the knowledge and candor of whoever answers; it does not produce a complete enterprise-wide analysis for multi-site or complex environments; and it offers limited help prioritizing remediation or tailoring controls to your architecture.

Recent versions have made it more defensible as an audit artifact. Each section now carries a reviewed-by confirmation with a username and date stamp, which builds the review trail investigators ask for. The risk rating previously labeled "medium" was renamed "moderate" to align with NIST SP 800-30 scoring, and the generated PDF reports now include section-level approval details and user comments.

Treat it as a checklist-style aid, not evidence of compliance. Completing the SRA Tool and filing the output is not the same as having conducted an accurate and thorough risk analysis, and it has not been treated as such in enforcement.

How risk analysis connects to incident response and breach notification

Three related obligations, frequently conflated: the security risk analysis identifies systemic risk across the organization on a cycle; security incident procedures under § 164.308(a)(6) detect, respond to, and document specific events; and the breach risk assessment under § 164.402 is the four-factor evaluation performed after an impermissible disclosure to determine whether notification is required.

Your risk analysis should evaluate how well the incident procedures actually work, not just confirm a document exists. Have they been exercised? Does anyone know who calls the cyber insurer at 2 a.m.?

The flow runs the other direction too. Incidents are evidence: a phishing campaign that got past existing filtering, an unpatched remote access gateway at a satellite clinic nobody had inventoried, a gap in vendor notification timelines that only appeared under pressure.

After any significant incident, update the risk register, rescore affected risks, and adjust the risk management plan. Tabletop exercises and technical drills count as inputs here as well.

Vendor and business associate risk

A signed BAA is a contract. It is not a risk assessment, and it does not transfer your obligation to evaluate the vendor.

The scale of what flows through business associates is the argument. The 2024 ransomware attack on Change Healthcare compromised roughly 193 million individuals, the largest healthcare breach on record. The Conduent Business Services breach, discovered in January 2025, was reported to OCR at 62,224,658 individuals in June 2026, making it the third largest ever.

The Conduent timeline is the part worth sitting with. The count was first reported at about 10.5 million, revised to roughly 25.5 million in February 2026, then finalized above 62 million in June 2026, more than eighteen months after discovery. If you were a covered entity relying on that vendor, your exposure was five times larger than you were told, and you found out in stages, over a year and a half.

For each vendor handling ePHI, evaluate:

• Types and volumes of ePHI they process
• Where data is stored: data centers, cloud providers, specific regions, and any subcontractors
• What controls they attest to, and whether anyone has actually read the SOC 2, HITRUST, or ISO 27001 report rather than filing the certificate
• Incident notification timelines and responsibilities as written in the BAA, and whether they are realistic
• Whether the BAA flows equivalent obligations down to subcontractors, per § 164.504(e) and § 164.308(b)

Practically: standardized vendor questionnaires, ongoing monitoring for critical vendors, and vendor risks scored in the same likelihood and impact framework you use internally. A separate vendor spreadsheet that never merges into the risk register is how third-party risk goes unmanaged.

How Mandry Technology supports HIPAA risk assessments

Mandry Technology is a Lubbock-based IT and cybersecurity partner working with regulated, downtime-sensitive organizations: hospitals, rural and critical access facilities, specialty clinics, and multi-site provider groups. The company started in 2002 in the back shop of a family electrical business and now runs five practices (cybersecurity, managed IT, unified communications, cloud, and AI governance) under a single SOC 2 Type II attestation.

Typical support on a HIPAA risk analysis:

• Building or validating ePHI inventories and data flow maps across locations, interfaces, and cloud platforms
• Technical assessment work: vulnerability management, configuration review, log and access analysis, feeding the broader analysis as evidence
• Facilitated workshops with IT, compliance, and clinical leadership to surface realistic threats and agree on risk levels
• 24/7 detection and response with log retention aligned to HIPAA and CIS Controls, which addresses the audit controls requirement at § 164.308(a)(1)(ii)(D) directly
• Backup and recovery work that answers the contingency planning standard: recovery runbooks, RTOs and RPOs defined by data class, and quarterly restoration testing
• Cloud migrations under Texas-specific constraints, including TX-RAMP, with data classes mapped before cutover so access boundaries and compliance documentation survive the move

The work that matters most usually comes after the report: turning findings into a prioritized remediation roadmap tied to real budget cycles, and building a cadence that keeps the analysis current instead of annual and forgotten.

Next steps

• A HIPAA risk assessment is required and ongoing for every covered entity and business associate, with no size exemption, including employer-sponsored group health plans
• It covers all ePHI across every system, site, endpoint, and vendor
• A defensible assessment follows a sequence: scope it, inventory ePHI and map flows, identify threats and vulnerabilities, evaluate existing safeguards, rate risk, document with rationale, and drive a risk management plan
• Scans, tests, vendor attestations, and the free SRA Tool are inputs, not the analysis
• The Security Rule overhaul slipping to 2027 changes nothing about what you owe today

The practical question is whether your team has the bandwidth and specialist depth to produce something audit-ready, particularly across multiple sites, acquired practices, or a mixed cloud and on-premises environment. Many organizations have the expertise and not the hours.

If you want a second set of eyes on your current HIPAA risk assessment approach, including what is in scope, what is missing, and what an examiner would ask for first, schedule a consultation with Mandry Technology.

Frequently asked questions

How long does a HIPAA risk assessment take?

For a small practice with a single cloud EHR and a handful of locations, four to six weeks end to end is typical, with roughly one to two weeks of active fieldwork. Multi-site systems and organizations with on-premises infrastructure, imaging archives, or recent acquisitions generally run eight to twelve weeks. The variable that moves the timeline most is inventory quality. Organizations with a current asset list and existing data flow diagrams finish considerably faster.

What does a HIPAA risk assessment cost?

Cost tracks scope more than organization size: how many locations and systems are in play, how many business associates need evaluating, whether technical testing is bundled in, and whether the engagement ends at findings or continues into a remediation plan. The variable that moves it most is inventory maturity. An organization that already knows where its ePHI lives is buying analysis, while one that does not is buying discovery first.

Who needs to be involved from our side?

At minimum, the Security Officer and someone with administrative access to the systems in scope. Most assessments also need time from the Privacy or Compliance Officer for policy and vendor questions, a clinical leader to validate workflows, and an executive sponsor to approve scope and accept residual risk. Expect a few hours each from most participants, concentrated in the fieldwork window.

How often should a HIPAA risk assessment be done?

Annually is the practical norm and what most payers and reviewers expect. The rule also requires updates in response to change: new systems, mergers and acquisitions, relocations, major network redesigns, and significant security incidents. Clinicians attesting under Promoting Interoperability must conduct or review one within each performance period.

Does the delayed Security Rule update mean we can wait?

No. The proposed amendments were never in force, so nothing was rolled back. The existing Security Rule remains fully enforceable and is what OCR is actively enforcing, and its Risk Analysis Initiative has produced fourteen enforcement actions to date. The delay affects future requirements, not current obligations.

Does the free HHS SRA Tool count as a risk assessment?

Not on its own. It is a useful structured starting point for small practices, but it is self-guided, does not produce an enterprise-wide analysis for complex environments, and does not prioritize remediation. Completing it and filing the output has not been treated as sufficient in enforcement.

Sources

• 45 CFR § 164.308, HIPAA Security Rule administrative safeguards
• 45 CFR Part 164 Subpart D, Breach Notification Rule
• HHS OCR, Guidance on Risk Analysis Requirements under the HIPAA Security Rule
• HHS OCR, HIPAA Security Rule Notice of Proposed Rulemaking, Federal Register, January 6, 2025
• HHS OCR, ransomware settlement with employer-sponsored health plan, June 18, 2026
• HHS OCR breach portal
• NIST SP 800-66 Revision 2, Implementing the HIPAA Security Rule
• NIST SP 800-30 Revision 1, Guide for Conducting Risk Assessments
• ONC and HHS OCR Security Risk Assessment (SRA) Tool
• CMS Quality Payment Program, 2026 MIPS Promoting Interoperability Security Risk Analysis measure specification