If there is one HIPAA Security Rule requirement that practices get wrong more than any other, it is the risk analysis. The Office for Civil Rights (OCR) has cited it in the overwhelming majority of enforcement actions going back more than a decade. Penalties have ranged from five figures for small practices to eight figures for large health systems — and the root cause is almost always the same: the practice had something they called a risk analysis, but it did not meet the standard.
This guide explains what the HIPAA risk analysis actually is, what it is not, the steps OCR expects to see, and the common mistakes that turn a well-intentioned document into an audit liability.
What the Security Rule actually requires
The HIPAA Security Rule, at 45 CFR §164.308(a)(1)(ii)(A), requires covered entities and business associates to “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.”
Three words in that sentence do most of the work.
Accurate. The analysis has to reflect your actual environment — not a template, not last year’s version, not a generic industry description. It must be based on real inventory, real data flows, and real controls.
Thorough. It must cover all systems that create, receive, maintain, or transmit ePHI. That includes your EHR, email, laptops, mobile devices, backups, cloud services, and every business associate connection. Missing a system — or a whole class of systems like a shadow-IT SaaS tool — is the single most common deficiency.
Potential risks and vulnerabilities. This is the analytical heart of the requirement. You are not just cataloging what you have; you are identifying how it could fail, how badly, and how likely each failure is.
What a risk analysis is not
The confusion starts when practices substitute something easier for something harder. These are the most common impostors.
A vulnerability scan is not a risk analysis. A vulnerability scan lists technical weaknesses. A risk analysis asks: what is the likelihood each of those weaknesses is exploited, and what is the impact on ePHI if it is? Scans feed the risk analysis; they do not replace it.
A vendor security questionnaire is not a risk analysis. Checking that your vendors attest to controls is part of third-party risk management, but it does not tell you how your own environment could fail.
An asset inventory is not a risk analysis. Knowing what you have is a prerequisite. Knowing how it could be compromised, and with what consequence, is the actual work.
A SOC 2 or HITRUST report is not a risk analysis. These are third-party attestations of a vendor’s program. They inform your assessment of that vendor but do not substitute for the analysis of your own environment.
A policy manual is not a risk analysis. Policies describe what you intend to do. A risk analysis describes what could go wrong if those policies fail — or if they do not exist in the first place.
If any of these documents sit in the folder labeled “HIPAA Risk Analysis,” your analysis is at risk of being judged inadequate.
The nine steps OCR expects to see
OCR has published guidance, most notably the Guidance on Risk Analysis Requirements under the HIPAA Security Rule, that lays out what an acceptable risk analysis looks like. The guidance draws on NIST SP 800-30 (Risk Management Framework) and describes nine analytical steps.
1. Define the scope. Identify every location, system, and process where ePHI is created, received, maintained, or transmitted. This includes on-premise servers, cloud services, email, mobile devices, USB drives, printers with hard drives, backup media, and every system of record that touches patient data. Scope misses are the most common gap — shadow-IT SaaS and personal devices are frequent offenders.
2. Collect data. Document how ePHI flows. Who creates it? Where does it live? Who has access? Who transmits it outside the organization and by what means? Data-flow diagrams are not required but are strongly recommended — they make scope gaps visible.
3. Identify and document threats. Threats are anything that could compromise the confidentiality, integrity, or availability of ePHI. Categories include human (malicious actors, negligent insiders, disgruntled ex-employees), environmental (fire, flood, power loss), and technical (malware, ransomware, supply-chain compromise, cloud provider outage).
4. Identify and document vulnerabilities. Vulnerabilities are weaknesses that a threat could exploit. Examples: unpatched operating systems, shared logins, unencrypted laptops, absent MFA, weak backup procedures, untrained staff, missing BAAs.
5. Assess current security measures. What controls are already in place, and how effective are they? Be honest. “We have a policy” is not a control; “we have a policy that is enforced and audited” is.
6. Determine the likelihood of threat occurrence. For each threat-vulnerability pair, how likely is it? Use a consistent scale (for example: very low / low / moderate / high / very high). Base judgments on industry data, your own incident history, and the maturity of existing controls.
7. Determine the potential impact of threat occurrence. If the threat materialized, how bad would it be? Consider confidentiality (how much ePHI exposed), integrity (how much data altered or destroyed), and availability (how long care delivery is disrupted). Impact must be rated on the same consistent scale used for likelihood.
8. Determine the level of risk. Combine likelihood and impact to produce a risk rating for each threat-vulnerability pair. Most organizations use a matrix. The output is a prioritized list of risks.
9. Document and finalize. Write it down. OCR expects a written report with the methodology, scope, findings, and risk ratings clearly presented. This document, along with the risk management plan that follows, must be retained for at least six years.
Risk analysis vs risk management: two different documents
The Security Rule actually requires two things: the risk analysis (above) and the risk management program at §164.308(a)(1)(ii)(B), which requires you to “implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level.”
The risk analysis identifies and rates the risks. The risk management plan is what you are going to do about them. It should include, for each identified risk above a threshold you set: the treatment (mitigate, transfer, accept, avoid), the specific controls you will implement, the owner, the target date, and the evidence that will demonstrate closure.
Practices routinely produce a risk analysis and stop there. That is half the requirement. The risk management plan is what OCR asks about when they want to know whether you acted on your findings.
How often to redo it
The Security Rule requires the risk analysis to be conducted and kept current. OCR has made clear that “current” means updated when there is a material change to the environment — a new EHR, a new office, a new cloud service, a significant new regulatory requirement, a security incident, a merger or acquisition. In practice, most practices should refresh the analysis annually at minimum, with interim updates whenever the environment changes materially.
If you have not updated your risk analysis in the last 12 months, you have a gap. If you have never done one that meets all nine steps above, you have a bigger one.
The seven most common mistakes
1. Substituting a checklist for an analysis. A yes/no checklist of Security Rule standards is not a risk analysis.
2. Missing scope. Shadow IT, personal devices used for work, paper-to-digital workflows, and cloud services signed up by individual departments are routinely missed.
3. No likelihood or impact ratings. A list of vulnerabilities without probability and consequence ratings is a vulnerability inventory, not a risk analysis.
4. No risk management plan. The analysis ends at identification; nothing is assigned, tracked, or closed.
5. Generic threats and vulnerabilities. Copy-pasted threat lists that do not reflect the practice’s actual technology, geography, workforce, or patient population.
6. One-and-done documentation. The risk analysis sits in a folder and does not get updated. When OCR asks when it was last reviewed, the answer is “three years ago.”
7. No evidence that findings were acted on. Risk management plan exists but has no owners, no dates, no proof of completion. OCR will ask to see closure evidence for high-risk findings.
When to engage outside help
A practice with strong internal security expertise can do a defensible risk analysis in-house, especially using NIST SP 800-30 as a guide. Most practices do not have that expertise — not because they are deficient, but because their clinicians and administrators did not train as risk analysts.
Third-party assessment brings three benefits: independence (your documented assessment is not written by the people whose work is being assessed), methodology (a consistent analytical framework applied the same way year over year), and experience (you benefit from what the assessor has seen at other practices — not just theory).
How Atlantic Computer Systems can help
Atlantic Computer Systems provides a free HIPAA Security Assessment that follows the NIST SP 800-30 methodology OCR expects. Our assessment produces a written risk analysis report, a prioritized risk management plan, a non-invasive vulnerability scan, and a leadership-ready executive summary. It typically takes 4–8 hours on-site with full report delivery in 1–2 weeks. Findings are confidential and covered by NDA.
Whether you engage us to remediate the findings, take them to your internal team, or simply use the report as the baseline for your next annual review, you will leave with a defensible risk analysis that would stand up to OCR scrutiny.
Schedule your free HIPAA Security Assessment →
Related reading:
Last updated: April 2026. This post is educational and does not constitute legal or compliance advice. Consult your compliance counsel for decisions specific to your organization.