The short version: “adequate” means accurate and thorough, covering all electronic protected health information your organisation creates, receives, maintains or transmits — everywhere it lives, not just in the obvious system. The Security Rule uses that phrase and then declines to tell you how to get there, which is why so many organisations produce something they believe is a risk analysis and later discover it was not.
This post describes general requirements. HIPAA applies differently depending on whether you are a covered entity or a business associate, what you do with the data, and how you are structured, and none of what follows is legal advice. Treat it as a way to interrogate your own document rather than as a compliance checklist.
Where the requirement comes from, and why it is not optional
The Security Rule’s administrative safeguards include a security management process standard, and risk analysis sits inside it as a required implementation specification. Risk management — actually reducing the risks you identified to a reasonable and appropriate level — is a separate required specification alongside it.
That word “required” matters because the Security Rule splits implementation specifications into required and addressable. Addressable does not mean optional; it means you assess whether the specification is reasonable and appropriate for your environment and, if it is not, document why and implement an equivalent alternative where reasonable. Risk analysis is not in that category. There is no version of the rule under which you can document your way out of doing one.
The rule also builds in flexibility. It says explicitly that you may take into account your size, complexity and capabilities, your technical infrastructure, the cost of security measures, and the probability and criticality of potential risks. A twelve-person digital health startup and a hospital system are held to the same standard but not to the same implementation. That flexibility is real, and it is frequently over-read: it flexes how you mitigate risk, not whether you identified it.
What a defensible risk analysis contains
No specific methodology is mandated. Many organisations use NIST-derived approaches because they are well documented and map cleanly onto the rule, but the method is your choice. Whatever you use, the output needs to show these elements and show them explicitly.
A complete inventory of ePHI and where it flows. Not just the primary application database. Backups, log aggregators, analytics warehouses, support ticket attachments, email, engineering laptops, mobile devices, staging environments seeded with production data, third-party services you send data to. If you cannot list where ePHI is, you cannot assess risk to it.
Threats and vulnerabilities identified against those assets. Both are needed. A threat without a corresponding vulnerability is noise; a vulnerability with no plausible threat actor is a low-priority finding. Cover the unglamorous categories too — lost devices, misdirected email, insider misuse, vendor failure, ransomware, natural disruption of availability.
An assessment of the security measures currently in place. What controls exist today, and are they configured and operating as intended. A risk analysis that assumes controls work because they are written in a policy is measuring the policy, not the risk.
Likelihood and impact, reasoned rather than asserted. You do not need a quantitative model. You do need to be able to explain why a given scenario was rated the way it was, and the explanation should survive a follow-up question.
A resulting risk level per finding, so that risk management has something to prioritise against.
Documentation, retained. The analysis itself, the decisions, and the rationale. Documentation retention obligations under the rule run for a substantial period, and the practical implication is that you keep prior versions rather than overwriting one living document.
The scoping failure that comes up most often
If there is a single pattern worth naming, it is incomplete scope. Organisations analyse risk to the main clinical or platform system and stop there, because that is where they think of ePHI as living.
Then someone asks about the data warehouse the analytics team built, or the CSV a customer success manager exported to troubleshoot a ticket, or the backup bucket in a second region, or the sandbox environment loaded with a copy of production because synthetic data was inconvenient. Each of those holds ePHI. Each of them is in scope. A risk analysis that does not mention them has not analysed the risk to that data, and no amount of rigour applied to the primary system compensates.
The practical fix is to start from the data rather than from the system list. Ask where ePHI enters, every place it is stored or cached along the way, everywhere it is transmitted, who can reach each of those, and how it eventually gets deleted. Then reconcile that map against your asset inventory and your vendor list. The gaps in the reconciliation are usually the interesting part.
Three things that are not a risk analysis
A gap analysis against the Security Rule. Walking the standards and implementation specifications and marking each as met, partially met or not met is a useful exercise. It tells you about your compliance posture. It does not identify threats to specific ePHI assets, and it does not produce risk ratings. It is a complement, not a substitute.
A vendor security questionnaire or a checklist product. Filling in a template someone sold you produces a document. Whether it produces an accurate and thorough analysis depends entirely on whether the underlying inventory and reasoning are yours and are real.
A penetration test or vulnerability scan. These are inputs. They identify technical vulnerabilities in tested systems at a point in time. They do not cover administrative and physical safeguards, workforce risk, vendor risk, or availability, and they are scoped to what you pointed them at.
Analysis and management are two different obligations
The risk analysis identifies and rates. Risk management decides what to do and then does it. In practice the second is where organisations get into difficulty more often than the first, because producing a document is easier than closing findings.
A defensible programme shows the thread from end to end: this risk was identified, rated at this level, this decision was made, this control was implemented or this risk was formally accepted by a named person, and here is the evidence and the date. Findings that appear in three consecutive analyses with no movement and no documented acceptance are the ones that are hard to explain later.
How often to do it again
The rule does not set a fixed interval. What it does require is that you review and modify security measures as needed to continue providing reasonable and appropriate protection, and that periodic evaluation happens in response to environmental or operational changes.
The workable reading is annual as a baseline, plus a triggered update whenever something material changes: a new product handling ePHI, a migration to a different cloud or region, an acquisition, a significant new vendor in the data path, a security incident, or a substantial change in how workforce members access data. An analysis that is three years old and describes an architecture you no longer run is not an accurate assessment of your current risk, whatever its original quality.
What to do next
Open your current risk analysis and check one thing: does it list every place ePHI exists, including backups, logs, analytics stores, non-production environments and third-party services? If it does not, the scope is the problem and nothing else in the document will fix it.
Then pick the three highest-rated risks and trace each one forward. If you cannot point to a decision, an owner and a date for all three, your risk management specification is the gap, not your analysis.
Assurion performs HIPAA security risk analysis work alongside SOC and ISO engagements, and we are glad to review an existing analysis before you commission a new one.