Yes. HIPAA requires an “accurate and thorough” risk analysis under 45 C.F.R. §164.308(a)(1)(ii)(A), and OCR expects specific outputs, not just a good-faith effort. This isn’t a checkbox exercise you do once and file away. It’s an ongoing obligation, and the outputs need to be concrete enough that an investigator could review them and see exactly how you found and handled risk.
Here’s what “done right” actually produces:
- A documented scope covering every place ePHI lives, moves, or gets touched
- Identified threat and vulnerability pairs, mapped to real systems
- Likelihood and impact determinations for each risk
- Risk ratings that drive prioritization
- A Risk Management Plan with named owners and real deadlines
Pro Tip: If you can’t point to a document with an owner’s name and a due date next to a risk, you don’t have a risk management plan. You have a list of problems.
If your organization hasn’t done this yet, or hasn’t touched it in a while, start with three moves this week: assign a single owner for the assessment (not a committee), inventory where ePHI actually lives across your systems and vendors, and schedule the first focused assessment session or bring in a qualified assessor. The clock on “ongoing” starts the moment you have ePHI, not the moment you get audited.
Key Takeaways
A defensible HIPAA risk assessment requires documented ePHI scope, identified threats and vulnerabilities, risk ratings, and a Risk Management Plan with named owners and deadlines.
| Point | Details |
|---|---|
| Legal requirement | 45 C.F.R. §164.308 mandates an accurate and thorough risk analysis, kept ongoing and updated as needed. |
| Full scope required | Assessments must cover all ePHI across devices, networks, cloud services, and business associates. |
| Findings need owners | Every identified risk should have a named owner, deadline, and evidence of remediation. |
| Use federal tools wisely | The HHS SRA Tool suits smaller practices; NIST SP 800-30 and 800-66 support more complex environments. |
| Managed support available | Total Cyber offers managed risk assessments, vulnerability analysis, and vCSO oversight for organizations needing continuous coverage. |
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.
Table of Contents
- What Does the HIPAA Security Rule Actually Require?
- How Do You Conduct a HIPAA Risk Assessment Step by Step?
- How Do You Turn Risk Assessment Findings Into a Risk Management Plan?
- Which Tools Help You Run a HIPAA Risk Assessment?
- What Mistakes Do OCR Investigators Commonly Find?
- How Total Cyber Approaches HIPAA Risk Assessments
- What Compliance Officers Get Wrong About Risk Assessments
- Sources
What Does the HIPAA Security Rule Actually Require?
The Security Rule is built on two connected provisions. §164.306 sets the general goal: covered entities and business associates must ensure the confidentiality, integrity, and availability of ePHI, while weighing their own size, complexity, and resources when choosing safeguards. §164.308(a)(1)(ii)(A) turns that goal into an action item: conduct an accurate and thorough assessment of the potential risks and vulnerabilities to that ePHI.
Neither provision hands you a template. OCR deliberately built flexibility into the rule, because a five-person clinic and a 400-bed hospital system don’t face the same risks or have the same resources to address them. That flexibility is often misread as looseness. It isn’t. The rule doesn’t tell you how to assess risk, but it’s very specific about what your assessment has to prove.
The regulation asks you to weigh your organization’s size, technical infrastructure, and the cost of security measures against the risk you’re actually carrying. It does not let you skip the analysis because you’re small, and it does not let a large system substitute size for thoroughness.
Scope is where most assessments quietly fail before they even start. “All ePHI” means:
- Electronic health records and practice management systems
- Email, texts, and any messaging platform that might carry patient information
- Mobile devices, laptops, and removable media
- Cloud-hosted applications and backups
- Network infrastructure, including remote access and VPNs
- Third-party vendors and business associates who create, receive, maintain, or transmit ePHI on your behalf
Miss any one of those categories and your risk analysis has a hole in it, whether or not you ever get audited. OCR’s own guidance on risk analysis treats an incomplete inventory as one of the most common reasons an otherwise well-intentioned assessment falls short. The scope question isn’t academic. It’s usually the first thing that determines whether your entire assessment holds up.
How Do You Conduct a HIPAA Risk Assessment Step by Step?
A defensible risk assessment follows a sequence, and skipping steps to save time is exactly how organizations end up with documentation gaps. NIST SP 800-66 lays out a practical version of this process for the healthcare context, and it maps cleanly onto what OCR looks for during enforcement reviews.
-
Prepare. Assign a security official, or confirm the one you already have on paper. Define your scope in writing, listing systems, applications, and dataflows. Pull together existing documentation, prior assessments, network diagrams, and vendor contracts before you touch anything new.
-
Identify assets and dataflows. Map where ePHI is created, received, maintained, and transmitted. This is more than a server list. Trace how a patient record moves from intake to billing to the cloud backup, and note every stop along the way.
-
Identify threat sources. Think in three categories: human (phishing attempts, disgruntled staff, careless password sharing), technical (unpatched systems, misconfigured firewalls, expired encryption), and natural or environmental (power outages, flooding, regional disasters that take out a data center).
-
Identify vulnerabilities. This is where you combine internal sources, prior assessments, vulnerability scan results, and audit logs, with external sources like vendor security bulletins and the National Vulnerability Database. NIST guidance is explicit that relying on internal knowledge alone leaves gaps a scan would have caught, and relying on a scan alone misses the process failures a scan can’t see.
-
Analyze likelihood and impact. Every organization has to decide whether it’s assessing risk qualitatively (using scales like Low, Medium, High) or quantitatively (assigning dollar values and probability percentages). NIST SP 800-30 frames risk as likelihood multiplied by impact, and that formula works whether you’re using words or numbers.
-
Determine risk level and prioritize. A high-likelihood, high-impact finding (say, an unpatched, internet-facing server hosting patient records) gets addressed before a low-likelihood, low-impact one (an outdated policy document nobody reads).
-
Document everything. Build a risk register, map each finding back to the specific Security Rule provision it violates, and collect evidence: configuration snapshots, ticket numbers, scan reports, and screenshots of settings before and after remediation.
Qualitative scales are faster and easier for smaller organizations to sustain without a dedicated analyst. Quantitative scoring takes more effort to build and maintain, but it gives you sharper prioritization when you’re managing dozens of findings across a large health system. Most mid-sized healthcare organizations land somewhere in between: qualitative ratings for day-to-day findings, with quantitative detail reserved for the highest-risk items headed to leadership for budget approval.
| Risk Factor | Low | Medium | High |
|---|---|---|---|
| Likelihood | Rare, no known active exploit | Possible, some exposure exists | Likely, active exploitation or known gap |
| Impact on ePHI | Minimal, limited or no data exposure | Moderate, partial data set exposed | Severe, large-scale or sensitive data exposed |
| Example finding | Outdated but unused test server | Weak password policy on one system | Unpatched, internet-facing EHR server |
Pro Tip: Don’t let a vulnerability scan report stand in as your risk analysis. A scan tells you what’s technically exposed. It says nothing about whether your staff is trained, whether your vendor contracts include breach notification clauses, or whether your backup process actually works. Treat scan output as one input among several, not the finished product.
How Do You Turn Risk Assessment Findings Into a Risk Management Plan?
A risk analysis without a Risk Management Plan is a list of problems nobody owns. OCR’s own guidance treats this connection as foundational: identifying risk is only half the requirement, and the analysis has to lead directly into documented, tracked mitigation.
A plan that would hold up under review needs, at minimum:
- A remediation step for each identified risk, written specifically enough that someone new to the organization could execute it
- A named owner, a person, not a department
- A deadline, with enough lead time to be realistic but short enough to show urgency
- A note on cost versus benefit, especially for expensive fixes that compete for budget
- A documented decision on any residual risk your organization has formally accepted rather than remediated
That last point matters more than most compliance officers realize. You’re allowed to accept a risk instead of fixing it immediately, but only if that decision is written down, dated, and signed off by someone with the authority to make it. An undocumented “we’ll get to it” is not the same thing as a documented risk acceptance, and OCR treats them very differently.
Evidence is what separates a plan on paper from a plan OCR will actually credit. Keep ticket IDs tied to remediation work, configuration snapshots from before and after a fix, audit logs showing access changes, signed vendor confirmations for third-party remediation, and training records showing staff completed required security awareness sessions. NIST SP 800-66 is direct on this point: documentation should tie each remediation to a specific implementation specification in the Security Rule, with evidence the fix was actually applied, not just scheduled.
Your Risk Management Plan shouldn’t sit in isolation from the rest of your compliance program. Feed findings into your change management process so new systems get vetted before deployment. Tie them into incident response so a breach investigation starts with a risk register that already flags the weak points. Update policies when a finding reveals a gap in written procedure, not just a technical hole. Set a review cadence, monthly for high-risk items, quarterly for the rest, and hold to it. A risk scoring approach can help you decide which findings get monthly attention and which can wait.
| Point | Details |
|---|---|
| Owner assignment | Every finding needs a named person responsible, not a department. |
| Deadline discipline | Set realistic but firm dates for remediation completion. |
| Residual risk documentation | Formally document and sign off on any risk your organization accepts rather than fixes. |
| Evidence trail | Keep ticket IDs, configuration snapshots, and training records tied to each remediation. |
Which Tools Help You Run a HIPAA Risk Assessment?
You don’t have to build a risk assessment methodology from scratch, and you shouldn’t. Several federal resources exist specifically to give healthcare organizations a structured starting point.
- HHS SRA Tool: Built by HHS and ONC for small and medium-sized practices, it walks you through a series of questions covering administrative, physical, and technical safeguards, and generates a report you can use as a working risk register. It’s a strong entry point, but larger organizations with complex environments, multiple facilities, or extensive vendor networks often outgrow what the tool can capture on its own.
- ONC / healthit.gov resources: Beyond the SRA Tool itself, ONC maintains checklists and guidance specifically aimed at mapping ePHI flows in clinical settings, useful during the identify-assets step of your assessment.
- NIST SP 800-30: The federal government’s own guide for conducting risk assessments, useful as a methodological backbone for likelihood and impact scoring, especially once your organization has outgrown a simple checklist approach.
- NIST SP 800-66 Rev. 2: Written specifically to help healthcare organizations map risk assessment activities to Security Rule standards, this is the closest thing to an official translation layer between “what NIST recommends” and “what HIPAA requires.”
| Tool | Best fit | Limitation |
|---|---|---|
| HHS SRA Tool | Small to mid-sized practices getting started | Limited depth for complex, multi-site, or enterprise environments |
| NIST SP 800-30 | Organizations building a formal likelihood/impact methodology | Requires internal expertise to apply well |
| NIST SP 800-66 Rev. 2 | Mapping assessment activities directly to Security Rule citations | A reference guide, not an interactive tool |
| ONC / healthit.gov checklists | Mapping ePHI dataflows in clinical settings | Narrower scope than a full risk assessment |
Keep three templates on hand regardless of which tool you start with: a risk register (spreadsheet columns for asset, threat, vulnerability, likelihood, impact, risk rating, owner, deadline, status), a risk matrix for visualizing likelihood against impact, and an evidence checklist listing exactly what documentation each remediation type requires. If your organization is expanding its use of connected health technology, a broader look at digital health tools is worth reviewing alongside your assessment, since new platforms almost always expand your ePHI footprint.
What Mistakes Do OCR Investigators Commonly Find?
OCR enforcement history shows the same deficiencies over and over, and almost none of them involve exotic technical failures. They involve gaps in scope and documentation that were entirely avoidable.
The most frequent problems: incomplete scope that leaves out mobile devices, cloud services, or entire departments; business associates left out of the risk analysis entirely, even though a BA handling ePHI carries the same analytical obligation as the covered entity itself; remediation decisions that were discussed but never written down; and a risk register full of findings with no evidence anything was ever actually fixed.
Best practices that consistently produce a defensible assessment:
- Include every business associate and vendor with ePHI access in your scope, not just your internal systems
- Treat automated vulnerability scans as one input feeding your analysis, never the entire analysis
- Trace dataflows end-to-end, from the point ePHI is created to every place it’s stored, backed up, or transmitted
- Assign a named owner and a real deadline to every finding, without exception
- Combine vulnerability scan data with manual configuration reviews and process audits, since scans catch technical gaps but consistently miss human and procedural ones
For organizations managing a large number of facilities or systems, a full assessment of every asset at once is rarely realistic. Sampling representative systems across departments, then extrapolating findings with documented rationale, is an accepted approach as long as you can explain why the sample was representative.
Pro Tip: If your risk register hasn’t changed in over a year, that’s not a sign you’re secure. It’s a sign the assessment stopped being a living document. OCR investigators notice static risk registers immediately.
How Often Should You Run a HIPAA Risk Assessment?
There’s no fixed federal cadence written into the Security Rule. What §164.308 requires is that your risk analysis stays “ongoing” and gets updated “as needed.” That phrase does real work: it means your assessment can’t be a one-time event, but it also doesn’t hand you a mandatory annual deadline the way some other frameworks do.
In practice, many healthcare organizations run a full baseline assessment periodically and layer event-driven updates on top. The following events should trigger an immediate reassessment, not a wait-until-next-year note:
- A major system change, new EHR platform, upgraded network infrastructure, or new medical device integration
- A cloud migration or new cloud service handling ePHI
- Onboarding a new third-party vendor or business associate
- A security incident or suspected breach, even a small one
- A merger, acquisition, or major organizational restructuring
- New or updated state or federal regulatory requirements
Document why you chose your cadence, whether annual, semiannual, or continuous, and keep a clear record every time an event triggers an off-cycle reassessment. That documentation is often what separates “we take this seriously” from “we got lucky” in an OCR review.
What Should You Do in the First 30, 60, and 90 Days?
Momentum matters more than perfection here. A prioritized timeline gets you from zero to a defensible program faster than trying to solve everything at once.
-
Start immediately: Appoint a named security official to own the assessment. Inventory every ePHI entry point, systems, devices, cloud services, vendors. Run the HHS SRA Tool or a scoped vulnerability scan to get a technical baseline. Start collecting evidence immediately, don’t wait until the analysis is “done.”
-
Next phase: Complete a full risk register for your highest-risk findings, the ones with high likelihood and high impact. Assign owners and deadlines to each. Begin active remediation on anything rated critical or high, don’t let these sit in a queue.
-
Ongoing steps: Validate that remediation actually worked, not just that a ticket got closed. Update your Risk Management Plan to reflect what’s been fixed and what remains. Set your ongoing reassessment cadence and put it on a calendar with named responsibility attached.
How Total Cyber Approaches HIPAA Risk Assessments
Total Cyber runs HIPAA risk assessments the way OCR guidance describes them: a full ePHI inventory, vulnerability analysis across systems and endpoints, a prioritized remediation plan with real owners and deadlines, and ongoing oversight through a vCSO who tracks the plan instead of letting it go stale. Being veteran-owned shapes how we approach this work. We’re methodical about scope, and we don’t consider an assessment finished until the remediation plan has teeth.
You don’t need outside help for every assessment. If you have dedicated security staff, a manageable environment, and the bandwidth to keep a risk register current between audits, doing it in-house is entirely workable. Bring in an MSP when internal capacity is thin, your environment spans multiple locations or a complicated vendor network, or you want continuous monitoring instead of a once-a-year fire drill.
What to expect from an engagement: a scoped inventory of your ePHI environment, a vulnerability assessment mapped to Security Rule citations, and a remediation plan with deadlines you can actually show an investigator.
| Point | Details |
|---|---|
| Assessment scope | Full ePHI inventory across systems, devices, and vendors before any technical scanning begins. |
| Remediation ownership | Every finding gets a named owner and deadline, tracked under vCSO oversight. |
| When to engage | Best suited to limited internal capacity, complex environments, or a need for continuous coverage. |
What Compliance Officers Get Wrong About Risk Assessments
The conventional advice treats a HIPAA risk assessment as a compliance artifact, something you produce once, file, and pull out if an auditor asks. That framing misses what OCR actually rewards, which is evidence of an active, working system. A risk register that hasn’t moved in a year tells an investigator more about your organization’s real posture than any policy document ever could.
The other place conventional advice falls short is tool selection. Plenty of guidance treats the HHS SRA Tool as sufficient for any organization, when it’s genuinely built for smaller, less complex practices. A multi-site health system that leans entirely on a self-assessment questionnaire, without NIST-based methodology or professional scanning behind it, is building a paper trail that looks compliant and isn’t.
If you take one thing from this, prioritize the connection between finding and fix. A risk analysis that identifies twenty vulnerabilities and remediates none of them with a documented owner and deadline is worse than a shorter analysis that closes every finding it makes. Depth of remediation beats breadth of discovery, every time OCR actually looks closely.
— Alden
Get a Defensible HIPAA Risk Assessment Without the Guesswork
Running a HIPAA risk assessment in-house is achievable, but it eats real time: scoping ePHI across every system, running scans, building a risk register, and keeping the remediation plan current month after month. Total Cyber handles the whole cycle for you, managed risk assessments, vulnerability scanning, remediation tracking, and ongoing vCSO leadership, so the documentation OCR expects gets built continuously instead of scrambled together before an audit.
That means faster identification of high-risk findings, evidence collection that happens automatically as remediation gets done, and a Risk Management Plan that stays current instead of gathering dust between annual reviews. If your team is stretched thin or your environment has grown more complex than a single in-house analyst can cover, request an assessment through our MSP form and we’ll walk you through what a managed engagement looks like for your organization.
Sources
- Hhs
- SP 800-66 Rev. 2, Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide | NIST
- Guide for Conducting Risk Assessments | NIST SP 800-30
- Security Risk Assessment Tool – ONC