The HIPAA Security Rule has been in effect since 2005. In those two decades, OCR has pursued hundreds of enforcement actions against covered entities. Across all of them, one finding appears more consistently than any other: the absent or inadequate risk analysis.
The risk analysis is not a technical document written by IT professionals. It is a business document written by organizational leadership — with technical input — that identifies the risks to patient data in your specific environment and documents what you are doing to address them. Every home health agency can produce one. Most do not have one that would survive scrutiny.
This guide walks through the process step by step, using the methodology OCR expects, with specific examples from the home health operating environment.
What the Risk Analysis Is — and What It Is Not
What it is: A documented assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI in your organization. A living document that is updated when your environment changes. The foundation of your entire HIPAA Security Rule compliance program.
What it is not: A checklist of security tools you have installed. A policy document describing what you plan to do. A one-page summary of your IT setup.
The risk analysis answers three questions for every system in your environment:
- What could go wrong with the ePHI in this system?
- How likely is it to go wrong, and how bad would it be if it did?
- What are you doing about it?
Step 1: Scope — Identify Every System Touching ePHI
Before assessing risk, you must know what you are assessing. Create an inventory of every system, device, and process that stores, processes, or transmits ePHI at your agency.
For a typical home health agency, this inventory includes:
Systems: - Electronic Health Record (EHR) — name, vendor, hosting model (cloud vs. on-premises) - Practice management / scheduling system - Billing software or billing service portal - Email platform (Microsoft 365, Google Workspace) - Cloud document storage (SharePoint, OneDrive, Google Drive) - Any telehealth or remote monitoring platforms - Medicare and Medicaid billing portals
Devices: - Office workstations and laptops - Tablets used by field staff - Smartphones used to access EHR or email - Any shared devices in the office
Processes: - Electronic claims submission - Fax (if electronic fax service is used for referrals) - Electronic prescribing or medication documentation - Patient record sharing with hospitals or specialists via health information exchange
Step 2: Identify Threats and Vulnerabilities
For each system or category in your inventory, identify the realistic threats and vulnerabilities.
A threat is something that could cause harm to ePHI. Examples: - Ransomware encryption of the EHR - Phishing attack capturing staff credentials - Theft of a field nurse's laptop or tablet - Unauthorized access by a former employee - Natural disaster (flood, fire) destroying servers - Cloud service outage making ePHI temporarily unavailable
A vulnerability is a weakness that increases the likelihood or impact of a threat materializing. Examples: - EHR accessed without MFA (vulnerability increases credential theft risk) - Field devices not encrypted (vulnerability increases data exposure from theft) - No backup or untested backup (vulnerability increases ransomware impact) - No phishing simulation training (vulnerability increases phishing susceptibility) - Former employee accounts not deactivated promptly (vulnerability increases unauthorized access risk)
Document each threat-vulnerability pair for each system. This does not need to be exhaustive — it needs to be realistic and honest about your environment.
Step 3: Assess Likelihood and Impact
For each identified threat-vulnerability pair, assess:
Likelihood: How likely is this threat to materialize, given the vulnerability and your environment? - Low: Unlikely to occur without a specific targeted attack - Medium: Possible based on current threat environment and vulnerability - High: Likely to occur without intervention; consistent with current attack patterns
Impact: If this threat materializes, how serious is the consequence? - Low: Limited ePHI exposure, quickly contained - Medium: Moderate ePHI exposure, significant operational disruption - High: Significant ePHI exposure, major operational disruption, regulatory exposure
Risk Level: Combine likelihood and impact into an overall risk rating: - High likelihood + High impact = Critical risk - High likelihood + Medium impact = High risk - Medium likelihood + High impact = High risk - Medium likelihood + Medium impact = Medium risk - Low likelihood + any impact = Low-Medium risk
Step 4: Identify Existing Controls and Residual Risk
For each threat-vulnerability pair, document the controls currently in place that reduce likelihood or impact. Then reassess the risk level after accounting for existing controls.
Example: - Threat: Ransomware encryption of EHR - Vulnerability: No immutable backup - Existing controls: Daily backup to external drive; Windows Defender active - Likelihood (pre-control): High — ransomware against healthcare is pervasive - Impact (pre-control): High — EHR locked, patient care disrupted, ransom demand - Likelihood (post-control): High — external drive backup often encrypted alongside production - Impact (post-control): High — backup cannot recover systems if drive is encrypted - Residual risk level: Critical — existing controls are insufficient
Document the residual risk for every pair. This becomes the basis for your risk management plan.
Step 5: Risk Management Plan
The risk analysis is not complete without a risk management plan — the document that specifies what you will do about the risks you identified. For each Critical and High risk item, document:
- The specific control you will implement to reduce the risk
- Who is responsible for implementation
- The target completion date
- The expected risk level after the control is implemented
Example risk management entry: - Risk: Critical — ransomware, no immutable backup - Control: Deploy cloud-based immutable backup for EHR data - Responsible: ShieldForce (managed security provider) - Target date: Within 30 days of contract start - Expected residual risk post-control: Low — immutable backup in isolated cloud storage enables recovery without paying ransom
Step 6: Document, Sign, and Date
The completed risk analysis document should include:
- The scope inventory (all systems and devices)
- The threat-vulnerability assessment table
- The likelihood-impact-residual risk ratings
- The list of existing controls
- The risk management plan
- The date of completion
- The name and signature of the HIPAA Security Officer or executive responsible
Update the risk analysis when significant changes occur in your environment — new EHR, new devices, new staff access patterns, new locations, or after any security incident.
How Often to Update the Risk Analysis
OCR guidance specifies that the risk analysis must be "ongoing" — not a one-time exercise. In practice, this means:
- Full review and update: annually
- Triggered update: whenever a significant operational change occurs (new system, new location, major staff change)
- Post-incident update: after any security incident, to document lessons learned and risk reduction
Let ShieldForce complete your HIPAA risk analysis as part of your managed security onboarding. Every ShieldForce engagement begins with a comprehensive risk analysis — the foundational document OCR requests first.
Explore Home Healthcare Cybersecurity →
Start with a free HIPAA assessment to see where your risk analysis stands.