The HIPAA Security Rule requires covered entities and business associates to conduct an accurate and thorough assessment of the risks to the electronic protected health information (ePHI) they hold, then reduce those risks to a reasonable and appropriate level. In practice, that means finding every place ePHI lives, identifying what could go wrong, rating each risk by likelihood and impact, documenting the results and acting on them.
HHS doesn't prescribe a single method. It does publish guidance on what a compliant analysis includes, and this post follows those steps in order.
What does HIPAA require for a security risk analysis?
Two implementation specifications in 45 CFR 164.308(a)(1)(ii) work together. Both are required, not addressable.
- Risk analysis, 164.308(a)(1)(ii)(A): "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."
- Risk management, 164.308(a)(1)(ii)(B): "Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level" to comply with the general requirements of 164.306(a).
The Security Rule is flexible by design. Under 164.306(b)(2), you consider your size, complexity and capabilities, your technical infrastructure, the costs of security measures, and the probability and criticality of potential risks to ePHI. The risk analysis is how you apply those factors and justify your choices, especially for addressable specifications.
Documentation matters too. Under 164.316(b)(2), you must keep required documentation for six years from its creation or the date it was last in effect, whichever is later. You must also review it periodically and update it in response to environmental or operational changes.
Which HHS and NIST resources should you use?
Three resources cover most of what you need:
- HHS OCR's Guidance on Risk Analysis Requirements under the HIPAA Security Rule (2010). It lists the elements a risk analysis should include and states that there is no single method or "best practice" that guarantees compliance.
- NIST SP 800-30 Revision 1, Guide for Conducting Risk Assessments (2012). OCR's guidance draws on NIST's approach, and 800-30 gives you a detailed, widely used method for identifying threats and vulnerabilities and rating likelihood and impact.
- The HHS Security Risk Assessment (SRA) Tool. HHS's Office of the National Coordinator for Health Information Technology and OCR offer this free, downloadable tool to help small and medium-sized providers work through the process.
Use the tool or method that fits your organization. What counts is whether the result is accurate, thorough and documented.
How do you conduct a HIPAA security risk analysis?
The steps below follow the elements in OCR's guidance.
Step 1: Define the scope
The scope is all ePHI your organization creates, receives, maintains or transmits, in every form of electronic media. That includes servers, workstations, laptops, mobile devices, removable media, cloud services, networks and medical devices that store or transmit patient data.
The analysis should be enterprise-wide. An assessment that covers only your electronic health record system, or only one location, is incomplete.
Step 2: Identify where ePHI is created, received, maintained or transmitted
Build an inventory of systems and data flows. For each one, record what ePHI it holds, where it's located, who uses it, how it connects to other systems, and which vendors or business associates are involved.
Useful sources include asset inventories, network diagrams, interviews with department leads, vendor contracts and business associate agreements. Don't forget backups, archives, email, scanned documents, and devices used from home. If the 2020 shift to remote work and telehealth moved ePHI onto new devices and services in your organization, make sure the inventory reflects that.
Step 3: Identify threats and vulnerabilities
OCR's guidance defines a vulnerability as a flaw or weakness in security procedures, design, implementation or internal controls that could be accidentally triggered or intentionally exploited. A threat is the potential for a person or thing to trigger or exploit a specific vulnerability.
List the threats reasonably anticipated for each system, then the vulnerabilities they could exploit.
| Threat category | Examples |
|---|---|
| Natural | Fire, flood, severe weather |
| Environmental | Power failure, cooling failure, water damage |
| Human, unintentional | Misconfiguration, lost devices, data sent to the wrong recipient, accidental deletion |
| Human, intentional | Unauthorized access by workforce members, device theft, exploitation of unpatched systems, malicious software |
| Technical | Hardware failure, software defects, failed backups |
Pair each threat with a specific vulnerability. "Unencrypted laptops used by billing staff" is actionable. "Laptops" is not.
Step 4: Assess your current security measures
For each threat and vulnerability pair, document the safeguards already in place and whether they're configured and used properly. Include administrative, physical and technical measures, such as policies, workforce training, facility access controls, access controls, audit logging, encryption, backups and contingency plans.
A control on paper that isn't enforced doesn't reduce risk. Verify, don't assume.
Step 5: Determine likelihood and impact
Estimate how likely each threat is to exploit the vulnerability, given your current safeguards. Then estimate the impact if it does. Consider the effect on confidentiality, integrity and availability of ePHI, patient care, operations, legal obligations and your organization's reputation.
Qualitative ratings such as low, medium and high are acceptable and common. Define what each rating means so different assessors apply them consistently.
Step 6: Assign risk levels
Combine likelihood and impact to assign a risk level. A simple matrix works for most organizations:
| Likelihood / Impact | Low impact | Medium impact | High impact |
|---|---|---|---|
| High likelihood | Medium | High | High |
| Medium likelihood | Low | Medium | High |
| Low likelihood | Low | Low | Medium |
Record the risk level for each threat and vulnerability pair, along with the reasoning. The ratings drive your priorities in the risk management plan.
Step 7: Document the analysis
OCR's guidance doesn't require a specific format, but the analysis must be documented. A complete record includes:
- Scope and methodology, including rating definitions
- The ePHI inventory and data flows
- Threats, vulnerabilities and current safeguards
- Likelihood, impact and risk ratings, with reasoning
- The date, the people involved, and management review or approval
Retain it for six years from creation or the date it was last in effect, whichever is later.
Step 8: Build a risk management plan
The risk analysis identifies risks. Section 164.308(a)(1)(ii)(B) requires you to do something about them. For each risk, decide how you'll treat it and record:
- The security measure you'll implement or improve
- An owner and a target date
- The expected residual risk
- Any decision to accept a risk, with the rationale and who approved it
Prioritize by risk level. Track progress and update the risk ratings as measures are put in place.
Step 9: Review and update the analysis
A risk analysis isn't a one-time project. OCR's guidance notes that the frequency of reviews varies by organization. Some update annually and others less often, depending on their circumstances.
Beyond a regular schedule, update the analysis whenever something significant changes, such as:
- New systems, applications or cloud services that handle ePHI
- Office moves, mergers or new locations
- New business associates or major changes to existing ones
- Security incidents or findings from audits and testing
- Changes in how your workforce accesses ePHI, including remote work
What are the most common risk analysis gaps?
Watch for these weaknesses in your own analysis:
- Not enterprise-wide. The analysis covers the EHR but misses email, file shares, imaging systems, mobile devices or business associates.
- Never updated. A risk analysis from several years ago doesn't reflect today's systems or ways of working.
- A checklist instead of an analysis. Confirming that each Security Rule standard has a policy is a gap assessment. It doesn't identify threats, vulnerabilities, likelihood and impact.
- No ePHI inventory. Without knowing where ePHI lives, the scope can't be accurate or thorough.
- No link to risk management. Risks are rated but never assigned owners, dates or remediation plans.
- Thin documentation. Ratings appear without reasoning, or there's no record of who performed and approved the analysis.
Frequently asked questions
Is a risk analysis the same as a HIPAA gap assessment?
No. A gap assessment checks whether you've implemented the Security Rule's standards. A risk analysis identifies and rates the specific risks to your ePHI. You need the risk analysis, and a gap assessment can be a useful input.
How often should we update our risk analysis?
HIPAA doesn't set a fixed interval. Review it on a regular schedule, and update it whenever your environment or operations change in ways that affect ePHI security.
Does using the SRA Tool make us compliant?
Not by itself. The tool helps structure the process, but compliance depends on whether your analysis is accurate, thorough, documented and followed by a risk management plan.
Do business associates need their own risk analysis?
Yes. The requirement applies to ePHI "held by the covered entity or business associate," so business associates must analyze the risks to the ePHI they handle.
Key takeaways
This guide reflects HHS guidance as of June 2020 and isn't legal advice, so confirm specifics with counsel.
- The risk analysis and risk management specifications are both required, and they work as a pair.
- Scope the analysis to all ePHI across the whole organization, starting with an accurate inventory.
- Rate each threat and vulnerability pair by likelihood and impact, and document your reasoning.
- Turn the results into a risk management plan with owners, dates and approved risk acceptances.
- Revisit the analysis regularly and whenever your systems or ways of working change.