The risk analysis is one sentence in the HIPAA Security Rule, and it carries more of the rule than any other. It decides which safeguards you need, how strong they should be, and how you justify each addressable specification. A weak or missing risk analysis is also among the problems most often cited in the resolution agreements HHS's Office for Civil Rights (OCR) publishes.
Teams usually have something called a risk assessment. The question is whether it is the thing the rule asks for. This article covers what the requirement says, the elements HHS guidance expects, how to scope it, and the documents that are commonly mistaken for one.
What the rule says
The requirement sits in the security management process standard at 45 CFR 164.308(a)(1). Two of its implementation specifications are the core of it, and both are required:
Risk analysis. Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of the ePHI you hold.
Risk management. Implement security measures sufficient to reduce those risks and vulnerabilities to a reasonable and appropriate level.
Three phrases do the work. "Accurate and thorough" sets the quality bar. "Confidentiality, integrity, and availability" means outages and data corruption count, not only disclosure. "ePHI you hold" means all of it, in every system and on every device.
The rule does not prescribe a method, a template, or a frequency. HHS has published guidance on what an acceptable analysis contains, and it points to NIST SP 800-30 as one recognized approach. Neither is mandatory, but an analysis that skips the elements below is hard to defend.
The elements HHS guidance expects
HHS's guidance on risk analysis lists the elements an analysis should include. In order:
Scope. All ePHI the organization creates, receives, maintains, or transmits, in any electronic medium.
Data collection. Where ePHI is stored, received, maintained, or transmitted, gathered from inventories, interviews, and documentation.
Threats and vulnerabilities. Reasonably anticipated threats, and the vulnerabilities they could exploit, documented.
Current security measures. What is in place, and whether it is configured and used properly.
Likelihood. How likely each threat is to exploit each vulnerability.
Impact. What would happen to ePHI if it did.
Level of risk. A risk rating from likelihood and impact.
Documentation. A written record of the analysis and its results.
Periodic review and update. A commitment to keep it current.
A finished analysis therefore reads as a table of threat and vulnerability pairs, each tied to an asset, each with existing controls, a likelihood, an impact, and a resulting rating. If yours is a narrative with no ratings, it is missing most of the elements.
Scoping all ePHI, not the production database
Scope is where a risk analysis most often falls short. The instinct is to assess the system the product runs on. The rule asks about all ePHI, and it rarely lives in one place.
Build the scope from data flows, not from the system list. For each way ePHI enters the organization, follow it until it is deleted. Common places that fall outside an analysis built from the architecture diagram:
Laptops and phones of staff who handle ePHI
Email, chat, and file sharing, where reports and exports end up
Backups, snapshots, and replicas in other regions or accounts
Logs and monitoring tools that capture request data
Non-production environments loaded with real data
Vendors and subcontractors that receive ePHI
Removable media and printed output, where any still exist
Vendors are in scope as a source of risk even though they run their own safeguards. Your analysis should rate the risk of each vendor that handles ePHI and record what you rely on, such as their agreement and attestations.
Rating risk without inventing precision
Likelihood and impact ratings are judgments. The aim is consistency, not false accuracy. A three or five point scale with written definitions for each level is enough for most organizations. Define the levels in terms your team recognizes: what "high impact" means for patient data in your product, and what "likely" means over a year.
Two rules keep ratings honest. Rate each risk against controls as they operate today, not as planned. And record who rated it and when, so a later reviewer can see why a risk moved. Risk scoring with likelihood and impact covers scale design in more depth.
From analysis to risk management
An analysis that ends in a report has done half the job. The risk management specification requires security measures that bring each risk to a reasonable and appropriate level. That means a decision for every risk above your threshold: reduce it, transfer it, avoid it, or accept it with a stated reason. The four risk treatment options explains when each fits.
The decisions belong in a risk register with owners and dates. The register is what shows the work happened across the year, not only on the day the analysis was written. Building a risk register auditors accept covers the fields.
This is also where addressable specifications get resolved. If you decide an addressable specification is not reasonable and appropriate, the reasoning should cite the risk analysis. Without that link, the decision looks like an omission.
How often to update it
The current rule sets no fixed interval. It requires security measures to be reviewed and modified as needed, and the evaluation standard calls for evaluation in response to environmental or operational changes. HHS guidance describes risk analysis as an ongoing process.
A defensible practice has two parts. Review the whole analysis on a stated cycle, and write that cycle in your policy. Also update it when something material changes: a new product feature that stores ePHI, a new vendor, a cloud migration, an acquisition, or a security incident that exposed a risk you had not rated.
HHS has proposed Security Rule changes that would set more specific expectations for risk analysis, among other things. A proposal is not current law. Check the rulemaking's status before you rely on either version.
What a risk analysis is not
Several documents get presented as a risk analysis. Each has value, and none is a substitute:
A gap assessment. It compares your controls with the rule's list of standards. It shows what is missing, but it does not identify threats, vulnerabilities, likelihood, or impact.
A SOC 2 report or penetration test. Both test controls. Neither rates risk to all your ePHI, and a penetration test covers only what was in its scope.
A completed questionnaire. Answering yes or no to a list of controls produces an inventory of practices, not an analysis of risk.
Tool output alone. HHS offers a free Security Risk Assessment Tool aimed at small and medium-sized providers. It can structure the work, but its output is only as accurate as what you enter.
The test is simple to state. Could someone read your analysis and see each risk to ePHI, how you rated it, and what you decided to do? If not, it is probably one of the documents above.
The analysis is one part of the security management process, alongside the sanction policy and activity review covered in HIPAA administrative safeguards in practice.
How TrustLynce helps
TrustLynce's risk register holds each risk with its asset, likelihood, impact, owner, and treatment plan, with the history of every change. Risks link to the controls that treat them, so a HIPAA review can trace from the analysis to the evidence that each measure operates.