What Counts as a HIPAA Security Risk Analysis?
A HIPAA Security Rule “risk analysis” is not a generic security review, a vendor questionnaire, or a one-time IT project you check off and file away. Under HIPAA, a security risk analysis is a documented, accurate, and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information (ePHI). In plain English: you must be able to show that you understand where ePHI exists, how it moves, what can realistically go wrong, how bad it would be if it did, and what you are doing about it.
If you are a small clinic, this is often the most misunderstood requirement in HIPAA. Many organizations assume that having an EHR, using “HIPAA-compliant” vendors, or running a vulnerability scan satisfies the obligation. Those items can support a risk analysis, but none of them automatically is a HIPAA security risk analysis. HIPAA expects a risk analysis to be comprehensive in scope, grounded in your actual environment, and used to drive risk management decisions over time.
Informational note: This article is for informational purposes only and does not constitute legal advice.
What HIPAA actually requires
The Security Rule makes risk analysis a required implementation specification. The regulation requires covered entities and business associates to conduct an “accurate and thorough assessment” of the potential risks and vulnerabilities to ePHI. It separately requires you to implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level. These are related but different obligations. Risk analysis is the assessment. Risk management is what you do in response.
HIPAA is intentionally flexible in how you implement safeguards, because organizations vary widely in size and complexity. That flexibility does not remove the obligation to perform the assessment. It means your analysis should fit your environment, your technology footprint, and your realistic threats, not someone else’s template.
HIPAA also expects documentation. The Security Rule requires you to maintain policies and procedures and retain required documentation for a defined period. A risk analysis that was “done in someone’s head” or discussed verbally but not recorded is not a defensible position during an audit, complaint investigation, or incident response.
The definition that matters: “accurate and thorough”
HIPAA uses the phrase “accurate and thorough” for a reason. It implies more than a superficial checklist. A risk analysis must be correct enough that someone knowledgeable could follow your logic, understand your scope, and see why you ranked risks the way you did. It must also be thorough enough that it reasonably covers all ePHI in your environment, not just the systems IT happens to like.
When regulators evaluate risk analyses after incidents, the common failure mode is not that an organization did not try. It is that the assessment did not meaningfully cover real ePHI flows, did not identify the actual attack paths, or did not drive follow-up risk management actions. In other words, the risk analysis looked like paperwork rather than a model of the environment.
A good way to interpret “accurate and thorough” is this: if you had to explain your risk decisions to a third party, could you demonstrate that you knew where ePHI was, how it could be exposed, and what you prioritized to reduce that exposure?
What a HIPAA security risk analysis must cover to “count”
It must be scoped to ePHI, not to “IT”
HIPAA’s Security Rule is about ePHI. That means your risk analysis must include every place ePHI is created, received, maintained, or transmitted. In modern healthcare environments, ePHI is rarely confined to the EHR alone. It often includes patient portals, billing systems, file storage, email, messaging, scanned documents, integrations, backups, endpoints, and remote access pathways. If ePHI touches it, it is in scope.
A risk analysis that only covers servers and firewalls, but ignores cloud services, vendor platforms, endpoints, and operational workflows, is incomplete by definition. The risk surface of a small clinic is usually dominated by identity access, endpoints, email, and vendor connectivity, not by a data center.
It must include an inventory and data flow understanding
A meaningful risk analysis starts with knowing what you have. That includes systems, devices, accounts, and where ePHI lives. It also includes how ePHI moves. For example, an intake form might enter through a website, route to email, get uploaded into the EHR, be exported to billing, and then be stored in a shared drive. Each hop creates different threat exposure and different control opportunities.
HHS guidance consistently frames risk analysis around identifying where ePHI is stored, received, maintained, or transmitted. If you cannot map ePHI flows, you cannot credibly assess risks to confidentiality, integrity, and availability.
It must identify reasonably anticipated threats and vulnerabilities
HIPAA does not expect you to model every theoretical threat. It expects you to model reasonably anticipated threats. For most small clinics, these are predictable: phishing and credential compromise, ransomware, misdirected communications, lost or stolen devices, improper access by workforce members, weak authentication, poor vendor controls, and inadequate backups.
Vulnerabilities are the weaknesses that threats exploit. Shared logins, lack of MFA, unmanaged endpoints, overbroad access, weak incident response procedures, untested backups, and inconsistent offboarding are common vulnerabilities in small organizations. Your risk analysis needs to connect threats to vulnerabilities in your specific environment, not generically.
It must assess likelihood and impact in a documented way
HIPAA does not prescribe a single scoring model. You can use qualitative categories (low/medium/high) or quantitative scoring, but you must show your logic. Likelihood is how probable the threat scenario is, given your environment and controls. Impact is the effect if it happens, typically including patient privacy harm, operational disruption, financial loss, and compliance consequences. A “risk level” is usually derived from these two variables.
The important part is consistency. If you call phishing “low likelihood” while also admitting that staff receive phishing emails daily and MFA is not enabled, your analysis stops being credible.
It must evaluate existing safeguards and control effectiveness
HIPAA expects safeguards to be reasonable and appropriate. A real risk analysis accounts for what controls you already have and whether they actually work. “We have backups” is not a meaningful statement unless you also know whether backups are protected from ransomware and whether you have tested restore capability. “We have policies” is not meaningful unless staff follow them and the policies match actual workflows.
This is where many assessments fail. They list controls as if the mere existence of a policy eliminates risk. HIPAA is concerned with real-world protection of ePHI, which includes whether safeguards are implemented and effective.
It must produce actionable outputs that drive risk management
A risk analysis that does not drive decisions is a compliance artifact, not a risk tool. The Security Rule pairs risk analysis with risk management for a reason. The expected operational outcome is a prioritized set of mitigation actions that reduce risk to a reasonable and appropriate level.
That does not mean you must remediate everything instantly. It means you must demonstrate that you identified the risks, prioritized them rationally, and implemented or planned measures to address them. If you have high-risk findings and no documented plan, you are effectively documenting your own inaction.
It must be maintained over time, not treated as a one-time event
HIPAA does not set a fixed annual schedule for risk analysis, but it expects the analysis to be updated as the environment changes and reviewed periodically. The logic is simple: if you change systems, vendors, workflows, access pathways, or threat exposure, an old risk analysis becomes stale.
A defensible posture is to treat risk analysis as living documentation that is revisited when meaningful changes occur, such as new EHR deployment, new patient messaging tool, new remote access method, a merger, a move to cloud file storage, or a security incident.
What does not count as a HIPAA security risk analysis
This is where organizations get burned, because they confuse supporting inputs with the required assessment.
A vulnerability scan is useful, but it is not a full risk analysis. Scans often focus on technical findings in a subset of systems and do not address workflows, access governance, vendor relationships, or impact to ePHI confidentiality, integrity, and availability across the environment.
A penetration test is also not a full risk analysis. A pen test can validate specific exploit paths, but it is scoped, time-bound, and rarely covers the full ePHI footprint, administrative safeguards, physical safeguards, and business associate pathways.
A generic “HIPAA checklist” or template is not sufficient unless it is tailored to your environment and includes the actual required elements: inventory, threats, vulnerabilities, likelihood and impact evaluation, and documented outputs tied to risk management.
A vendor’s “HIPAA-compliant” marketing statement does not satisfy your obligation. Vendors can be part of your safeguards, but HIPAA places responsibility on the covered entity or business associate to understand its own risk posture. You still need to evaluate how ePHI flows through vendor systems, what access exists, what controls are in place, and how incidents would be handled.
A policy binder is not a risk analysis. Policies support safeguards. A risk analysis evaluates risks and vulnerabilities and uses that evaluation to drive safeguards and decisions.
A practical, defensible approach for small clinics
A lot of HIPAA guidance becomes usable when you treat risk analysis like engineering: define the system boundary, map flows, identify failure modes, assess probability and consequence, and prioritize mitigations.
A small clinic does not need an enterprise GRC program. It needs a disciplined method that produces a durable record. Many organizations use NIST risk assessment concepts as a foundation because they align well with HIPAA’s expectations and terminology.
Start by defining scope in plain language. Document what you included: which systems, which locations, which workforce access pathways, and which vendors. If you exclude something that touches ePHI, document why and how you will address it later. Scope clarity prevents the most common failure: an assessment that accidentally ignores major parts of the environment.
Next, inventory where ePHI exists and how it moves. Do not aim for perfection. Aim for a map that would allow someone else to understand your footprint. In small clinics, this usually surfaces ePHI in places leadership did not expect, like email threads, scanning workflows, shared drives, portal exports, and third-party messaging tools.
Then identify threat scenarios that match your reality. Use concrete scenarios rather than generic labels. “Phishing” is abstract. “Credential theft leads to unauthorized portal access and bulk record export” is a scenario you can evaluate. “Ransomware encrypts shared drive containing exported visit summaries and disrupts operations for one week” is a scenario you can evaluate.
For each scenario, document relevant vulnerabilities and current safeguards. This is where you stop guessing and start measuring. Do you have MFA? Are there shared accounts? Are devices managed? Are backups isolated and tested? Is offboarding timely? Is audit logging enabled? If you cannot answer, the uncertainty itself is a finding.
Then evaluate likelihood and impact in a consistent model and derive a risk rating. You can keep this qualitative and still be defensible, as long as the logic matches the evidence you documented.
Finally, produce a risk management plan that is proportional and prioritized. Small clinics cannot do everything at once, and HIPAA does not expect infinite resources. It expects reasonable safeguards. A risk management plan should specify what you will implement, who owns it, and when it will be done. If you choose not to implement a safeguard, document why and what alternate measure you use instead.
This is the difference between a risk analysis that exists and a risk analysis that counts.
What your completed risk analysis should look like
A HIPAA security risk analysis is not defined by a specific form. It is defined by its content and defensibility. At minimum, you should be able to produce documentation that shows:
You knew the scope and boundary of the assessment, including all systems and vendors that handle ePHI.
You inventoried where ePHI is stored, received, maintained, and transmitted, with enough detail to understand flows.
You identified realistic threats and environment-specific vulnerabilities.
You evaluated likelihood and impact, producing risk levels in a consistent way.
You documented existing safeguards and whether they are effective.
You produced a set of mitigation decisions and a plan to reduce risks to a reasonable and appropriate level.
You maintained the analysis over time, updating it when meaningful changes occurred.
That is what “counts” under HIPAA: an assessment that is accurate, thorough, documented, and used to drive real safeguards.
Sources
45 CFR § 164.308(a)(1)(ii)(A) (Security Rule risk analysis requirement)
https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308
45 CFR § 164.308(a)(1)(ii)(B) (Security Rule risk management requirement)
https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308
45 CFR § 164.306 (Security standards: general rules, including flexibility of approach and protection against reasonably anticipated threats)
https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.306
45 CFR § 164.316(b) (Security Rule documentation requirements and retention)
https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.316
HHS OCR, Guidance on Risk Analysis Requirements under the HIPAA Security Rule
https://www.hhs.gov/hipaa/for-professionals/security/guidance/guidance-risk-analysis/index.html
HHS OCR, Summary of the HIPAA Security Rule
https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html
NIST SP 800-66 Rev. 2, Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide
https://csrc.nist.gov/pubs/sp/800/66/r2/final
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-66r2.pdf
NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments
https://csrc.nist.gov/publications/detail/sp/800-30/rev-1/final
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf