A HIPAA risk assessment, also called a security risk analysis, is a documented review of where electronic protected health information (ePHI) lives, what could threaten it, and how likely and damaging each threat is. The Security Rule requires it. HHS states that covered entities and business associates must conduct an accurate and thorough assessment of the risks and vulnerabilities to the confidentiality, integrity, and availability of the ePHI they hold. This guide explains the requirements, walks through the steps, shows what a template should contain, and covers how often to repeat the work.
TL;DR
- The Security Rule requires a risk analysis from every covered entity and business associate. It is the foundation of the rest of your security program.
- The analysis must cover all ePHI you create, receive, maintain, or transmit, not just your EHR.
- Identify ePHI, threats and vulnerabilities, rate likelihood and impact, then write an action plan and document everything.
- HHS does not set a fixed frequency. Treat it as ongoing, and review it at least yearly and after any major change.
- The free HHS-linked SRA Tool helps, but using it does not by itself guarantee compliance.
Table of Contents
- What a HIPAA risk assessment is
- Who has to conduct one
- What the analysis must cover
- How to conduct a HIPAA risk assessment, step by step
- What a HIPAA risk assessment template should include
- How often to update it
- What regulators look for: lessons from enforcement
- Our perspective on risk assessments
- Get help with your HIPAA risk assessment
- FAQ
- Sources
What a HIPAA risk assessment is
Think of it as a map of your exposure. You list every system and device that touches patient data, ask what could go wrong with each (ransomware, a lost laptop, a misconfigured cloud bucket, a vendor breach, a staff mistake), then judge how likely each event is and how bad the result would be. The output is a ranked list of risks and a plan to reduce them.
A risk assessment is not a one-time checklist and it is not a penetration test, although a test can feed into it. It is also different from a breach risk assessment, which you run after an incident to decide whether notification is needed. This article covers the security risk analysis the Security Rule requires up front.
Who has to conduct one
The requirement is not limited to hospitals. The Security Rule applies to all covered entities: health plans, health care clearinghouses, and any health care provider that transmits health information electronically in connection with a HIPAA-standard transaction. It also applies to their business associates.
In practice that means a solo dental practice, a billing company, a cloud host storing patient records, and a health system all owe the same basic exercise. The depth scales with size and complexity, but nobody is exempt. If you are a business associate, your own assessment must include the ePHI you handle for clients.
What the analysis must cover
Three points from HHS guidance shape the scope.
All ePHI, in every form. Per HHS OCR guidance citing 45 C.F.R. § 164.306(a), the scope includes all ePHI an organization creates, receives, maintains, or transmits, across hard drives, removable media, smart cards, transmission media and portable electronic media.
More than your EHR. The ONC Guide to Privacy and Security says the scope is much broader than the EHR incentive programs. It reaches practice management systems, claims processing, billing, patient flow, case management, document scanning, clinical portals and other ancillary systems.
Threats and vulnerabilities, documented. Organizations must identify and document reasonably anticipated threats to ePHI, and vulnerabilities that a threat could exploit to cause inappropriate access or disclosure, as the same HHS guidance explains.
The technical footprint is wide. It includes web-facing systems and the infrastructure behind them, so website security and customer trust basics belong in the inventory alongside servers, laptops and mobile devices. Cloud platforms, backups, medical devices and network gear belong there too. Our guides on cloud security in healthcare and medical device security go deeper on two areas that are often missed.
How to conduct a HIPAA risk assessment, step by step
HHS does not mandate one method. The ONC guide offers a sample seven-step approach: lead your culture and select your team, document your process, review existing security of ePHI, develop an action plan, manage and mitigate risks, attest where a program requires it, and monitor and update on an ongoing basis. Here is how that translates into working tasks.
- Assign ownership. Name a security officer and a small team (IT, compliance, clinical or operations lead). The ONC guide treats leadership commitment and a designated security officer as the first move.
- Inventory your ePHI. List every system, application, device, vendor and location where ePHI is created, received, stored or sent. Include email, text messaging tools, scanners, backups and anything staff use from home. Draw the data flow: where it enters, where it goes, who touches it.
- Identify threats. Natural, human and environmental: ransomware, phishing, insider misuse, theft or loss of devices, power or hardware failure, vendor outages, fire or flood.
- Identify vulnerabilities. Unpatched software, missing encryption, shared logins, weak or absent multi-factor authentication, flat networks, untested backups, untrained staff, vendors with no signed business associate agreement.
- Review current controls. Note what already reduces each risk: encryption, access controls, audit logging, monitoring, training, policies.
- Rate likelihood and impact. Use a simple scale (low, medium, high) for each, then combine them into an overall risk level per threat and vulnerability pair.
- Document the results. NIST SP 800-66r2 advises that once likelihood, impact and risk levels are determined, results should be documented, and that a risk register can be a useful format.
- Build the action plan. For each high and medium risk, assign an owner, a fix, a deadline and a way to confirm it worked. Record any risk you knowingly accept and who approved that decision.
- Re-run and monitor. Update the analysis when systems, vendors, locations or threats change.
A worked example
Say a clinic stores scanned referral letters on a file server. Threat: ransomware. Vulnerability: the server is reachable from a flat office network and the last restore test was never done. Likelihood: high. Impact: high, since scheduling and records stop. Overall: high. Action: segment the network, enforce MFA for remote access, and test restores quarterly, owned by the IT lead, with a completion date. That single line in a risk register is what regulators expect to see, repeated for every asset.
Backups deserve a specific look, because an untested backup is a common finding. See our guide to HIPAA-compliant backups and our piece on patient data encryption for audit readiness.
What a HIPAA risk assessment template should include
Searchers often look for a template. Whether you build a spreadsheet or use a tool, make sure it captures these fields.
| Section | What to record |
|---|---|
| Asset inventory | System or device, owner, location, type of ePHI, vendor |
| Data flow | How ePHI enters, moves, is stored and leaves |
| Threats | Threat source and event for each asset |
| Vulnerabilities | Specific weakness that a threat could exploit |
| Existing controls | Technical, administrative and physical safeguards in place |
| Likelihood | Rating and the reasoning behind it |
| Impact | Rating tied to confidentiality, integrity and availability |
| Risk level | Combined rating and priority |
| Remediation plan | Action, owner, due date, status |
| Evidence | Links to policies, screenshots, logs, vendor agreements |
| Review log | Date, reviewer, what changed |
Using the HHS and ONC SRA Tool
The ONC Security Risk Assessment Tool guides users through a wizard with multiple-choice questions, threat and vulnerability assessments, and asset and vendor management. It is a sound starting point for small and medium practices. The same page notes that its use is not required by the Security Rule, does not guarantee compliance, and is not exhaustive: risks you know about that the tool does not flag should still be identified, assessed and documented.
The tool's user guide explains that its Remediation Plan section lets you record how you will mitigate each risk, and that you can attach supporting documents. Extra risks can sit in the tool or in a separate document that supplements it. HHS also released an updated version of the tool, so download the current one rather than reusing an old copy.
How often to update it
HHS is explicit that the Security Rule does not set a frequency. Some organizations review annually, others on a longer cycle, and the process is meant to be ongoing. The Rule also requires you to periodically evaluate your security measures, regularly reevaluate potential risks to ePHI, and modify measures as necessary.
Some contexts set a clearer cadence. CMS requires eligible hospitals and critical access hospitals in the Promoting Interoperability Program to conduct or review a security risk analysis and implement updates at least once each calendar year. Many organizations set their own policy: one university's procedure, for example, requires a documented analysis at least every two years, plus reevaluation after environmental changes or incidents, and keeps a written record for six years.
A practical rule: review at least once a year, and again after a new EHR or cloud migration, an acquisition, a new office, a major vendor change, or a security incident.
The proposed Security Rule update
On January 6, 2025, HHS published a proposal to overhaul the Security Rule. As summarized by a law firm, it would require the written risk assessment to be reviewed, verified and updated at least every 12 months, with evaluations after changes to the environment, and a written risk management plan reviewed annually. It would be the first update to the Security Rule since 2013. A proposal is not law, so check the HHS site for its current status. Building an annual cycle now keeps you ahead either way.
What regulators look for: lessons from enforcement
Missing or incomplete risk analysis is among the most common findings in OCR settlements. Three examples show what the consequences look like.
- Heritage Valley Health System. Under its resolution agreement, HHS required a comprehensive risk analysis covering all facilities, an enterprise-wide risk management plan, annual review of the analysis and prompt updates after operational changes, plus a $950,000 resolution amount.
- Elgon. After a ransomware attack affected about 31,248 people, OCR found the company had not conducted an accurate and thorough risk analysis. It agreed to pay $80,000 and update its analysis and management plan, as reported by the New York State Dental Association.
- L.A. Care Health Plan. It settled multiple violations for $1,300,000 and agreed to a corrective action plan that includes an organization-wide risk analysis and a risk management plan.
The pattern is consistent: regulators want an analysis that covers everything, and a management plan that shows you acted on it. For more on ransomware-related settlements, see our comparison of HITRUST and HIPAA.
Acting on your findings
A finished analysis that sits in a drawer helps nobody. One organization's procedure requires findings to reach the privacy and security officers within 30 days of concluding the analysis, with risk acceptance decisions documented alongside leadership and fixes done within a reasonable timeframe. You can borrow that discipline: set an internal deadline, rank the fixes, and report progress to leadership.
People are part of the risk picture too. Phishing and credential misuse show up in nearly every assessment, so link your findings to training. Our guides on common employee vulnerabilities and employee cybersecurity training can help.
Our perspective on risk assessments
Most of the weak assessments we see share one trait: they were built from fragments. The EHR was reviewed by one party, the cloud environment by another, the network by a third, and nobody owned the full picture. The Security Rule asks for all ePHI, so an assessment that stops at the edge of one system is incomplete by design.
We believe the assessment works best when it sits inside one security and IT program. When the people who monitor your environment around the clock, manage your cloud and run your compliance work share one view, the risk register stays current instead of going stale after the audit. Findings turn into fixes faster because the same team can make them.
Our approach is to pair a compliance assessment with senior practitioners in each domain, a single point of accountability and a unified SLA, so every risk has an owner and a date. That is how we aim to make the analysis a living process rather than an annual scramble.
Nick - Sr. Executive
Get help with your HIPAA risk assessment
If you would rather not carry the assessment alone, we can help. Nexus provides compliance and risk assessments covering HIPAA, SOC 2, PCI-DSS and ISO 27001, alongside 24/7 threat detection, cloud management, network infrastructure, data protection and managed IT services, under one contract with fixed-fee pricing. You can see how the pieces fit on our services page, or start from the Nexus home page.
For healthcare teams, one provider across security, cloud and compliance means your risk assessment and your remediation plan are handled by the people who run your environment.
FAQ
Is a risk assessment required by HIPAA?
Yes. The Security Rule requires covered entities and business associates to conduct an accurate and thorough assessment of risks and vulnerabilities to ePHI. It applies to organizations of every size, from a single practice to a large health system.
How often does HIPAA require a risk assessment?
HHS does not name a fixed interval. It expects the process to be ongoing, with regular reevaluation of risks. Annual review is a common standard, and some programs, such as CMS Promoting Interoperability for hospitals, require updates at least once each calendar year.
Does using the SRA Tool make me HIPAA compliant?
No. ONC states that use of the tool is not required and does not guarantee compliance. It is a structured way to capture your assessment. You should still record any known risks it does not cover and keep a remediation plan.
What should I do first?
Name a security officer and build your ePHI inventory. Every later step depends on knowing which systems and vendors hold patient data. A short, complete inventory is more useful than a polished one with gaps.
Sources
- Guidance on Risk Analysis, HHS.gov
- Summary of the HIPAA Security Rule, HHS.gov
- Chapter 6, Guide to Privacy and Security of Electronic Health Information, ONC
- NIST SP 800-66r2
- Security Risk Assessment Tool, ONC
- Security Risk Assessment Tool v3.6.1 User Guide
- Security Risk Analysis fact sheet, CMS
- HIPAA Security Rule General Requirements, University of Alabama
- HHS Proposes Significant Updates to HIPAA Security Rule, Ballard Spahr
- Heritage Valley Health System Resolution Agreement, HHS.gov
- OCR Takes HIPAA Action Against Company for Allowing Ransomware Attack, NYSDA
- L.A. Care Health Plan Settles Multiple HIPAA Violations, HIPAA Journal
- Website Security: Safeguarding Brands and Customer Trust