A HIPAA risk analysis is an accurate and thorough assessment of the risks and vulnerabilities to the confidentiality, integrity and availability of ePHI. Risk management is the follow-on step: implementing security measures that reduce those risks to a reasonable and appropriate level. Both are required specifications in 45 CFR 164.308(a)(1)(ii).
The exact wording
Under the security management process standard, the rule lists four required specifications:
- Risk analysis: conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of ePHI held by the covered entity or business associate.
- Risk management: implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level.
- Sanction policy: apply sanctions against workforce members who fail to comply.
- Information system activity review: regularly review audit logs, access reports and incident tracking reports.
The standard's own purpose is stated in one line: implement policies and procedures to prevent, detect, contain and correct security violations.
How the two differ
| Risk analysis | Risk management | |
|---|---|---|
| Question | What could go wrong to our ePHI? | What are we doing about it? |
| Output | Inventory of assets, threats, vulnerabilities, ratings | Treatment decisions, owners, controls, dates |
| Failure mode | Narrow scope, out of date | Findings that never get fixed |
Many weak programs stop after the first column. A document that lists 60 risks and nothing else shows you found problems without doing the second required step.
Getting scope right
The words "held by" are broad. Scope should cover every place ePHI is created, received, maintained or transmitted: production systems, backups, laptops and phones, email, logging and monitoring tools, analytics stores, vendor systems and lower environments. Missing a system is the most common reason an analysis is judged inaccurate.
For software teams, a practical input list:
- A current asset and data flow inventory, including third party components and services.
- A vulnerability picture for each system, including open dependency issues.
- Existing controls mapped to the technical safeguards.
- Likelihood and impact ratings with a stated method.
Keeping it alive
The rule requires you to review and modify security measures as needed and update documentation, and it separately calls for periodic evaluation in response to environmental or operational changes. A new vendor, a new data store or a major release is a reason to revisit the analysis, not only the calendar.
Keep records. Documentation of required actions must be kept for six years, so each version of the analysis and each risk decision matters. See documentation retention.
Linking the two in practice
Give every identified risk a decision: reduce, accept with sign off, transfer, or avoid. Put a named owner and a date on every reduction. Track them in the same place you track engineering work so they do not sit in a PDF. Addressable specifications connect here too, since your analysis is the basis for deciding whether each is reasonable. See addressable vs required.
Quick check
Is a vulnerability scan a risk analysis?
No. A scan is one input. The analysis must cover risks to confidentiality, integrity and availability across all places ePHI lives, not only scanned hosts.
How often must the analysis be redone?
The text does not set a number. It expects ongoing review and updates when the environment or operations change, so set a cadence and trigger events and document them.
Sources
- 45 CFR 164.308, administrative safeguards
- 45 CFR 164.306, security standards general rules
- 45 CFR 164.316, documentation requirements
Last reviewed: 19 October 2026.
