HIPAA Risk Analysis: The #1 OCR Audit Finding, Explained
Last updated: 2026-05-03 — ComplianceStack Editorial Team
If there is one HIPAA requirement that explains more enforcement actions than any other, it is the Security Risk Analysis — codified at 45 CFR §164.308(a)(1)(ii)(A). OCR's published audit findings consistently show that inadequate or missing risk analysis appears in more than **73% of HIPAA enforcement investigations**. It was the cited deficiency in Banner Health's $1.25 million settlement, LifeBridge Health's $9.76 million settlement, Premera Blue Cross's $6.85 million settlement, and dozens more. It is also the single most addressable gap in any HIPAA compliance program — unlike encryption infrastructure or full workforce training overhauls, a risk analysis can be initiated today with existing staff. This guide covers the statutory and regulatory requirements, the OIG and OCR audit protocols, what a compliant risk analysis must include, and a practical methodology for completing one.
The Statutory Basis: 45 CFR §164.308(a)(1)(ii)(A)
The HIPAA Security Rule's risk analysis requirement derives from Section 164.308 — the Administrative Safeguards section — which is one of three safeguard categories in the Security Rule (the others being Physical Safeguards at §164.310 and Technical Safeguards at §164.312).
The exact regulatory text. Under 45 CFR §164.308(a)(1)(ii)(A), covered entities and business associates must implement:
*Risk analysis (Required): 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].*
Required vs. addressable specifications. The Security Rule distinguishes between Required and Addressable implementation specifications. Required specifications must be implemented without exception. Addressable specifications must be implemented if reasonable and appropriate, or the covered entity must document why it is not reasonable and appropriate to implement and adopt an equivalent alternative measure.
Risk analysis is Required. There is no Addressable alternative, no exception for small practices, and no exemption for business associates. Every covered entity and every business associate that creates, receives, maintains, or transmits ePHI must perform a risk analysis. The proposed 2026 Security Rule NPRM does not change this requirement — it strengthens it by requiring annual updates and connecting risk analysis findings to specific technical control obligations.
The companion requirement: Risk Management. 45 CFR §164.308(a)(1)(ii)(B) — Risk management — is equally Required and is inseparable from risk analysis: covered entities must implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level. Risk analysis identifies the risks; risk management requires implementing controls to address them. An organization that completes a risk analysis but takes no remediation action has not satisfied the companion requirement.
The regulatory history. The risk analysis requirement was included in the original 2003 HIPAA Security Rule. The 2013 HITECH Omnibus Rule extended it explicitly to business associates. OCR's April 2016 Phase 2 HIPAA Audit Program — which audited both covered entities and business associates — found risk analysis deficiencies in 94% of covered entity audits and 88% of business associate audits. Eleven years after the requirement took effect, most regulated entities were still not meeting it. The numbers have improved since but the risk analysis remains the most frequently cited gap in OCR investigations.
What a Compliant HIPAA Risk Analysis Must Include
OCR's Guidance on Risk Analysis Requirements (published December 2010 and updated in subsequent guidance) specifies nine elements that a compliant risk analysis must address. These are not suggestions — they are the criteria OCR uses when evaluating whether a submitted risk analysis satisfies §164.308(a)(1)(ii)(A).
1. Scope of the analysis. The risk analysis must encompass all ePHI that an organization creates, receives, maintains, or transmits. This includes ePHI in: EHR and clinical systems, practice management software, billing systems, email (if PHI is sent via email), cloud storage, backup systems, portable devices (laptops, smartphones, USB drives), home office equipment used for remote access, and third-party vendor systems that touch ePHI through system integrations or direct access.
Common mistake: Organizations that scope their risk analysis only to their primary EHR system — without including all other ePHI repositories — have not met this requirement. The OCR guidance specifically states that the scope must include all ePHI in all forms of electronic media, not just systems on the primary network.
2. Data collection on threats and vulnerabilities. A risk analysis must include an inventory of threat sources and threat events. Threats include:
- Environmental threats: flood, fire, storm, utility failure
- Human threats: unauthorized access, malicious insider, phishing, ransomware, social engineering
- Technical threats: software vulnerabilities, hardware failure, configuration errors, patch management gaps
Vulnerabilities are system weaknesses that a threat could exploit. Examples: unpatched operating systems, shared login credentials, no multi-factor authentication, unencrypted portable devices, default vendor passwords, inadequate firewall rules.
3. Identify and document potential threats and vulnerabilities. This step requires creating a formal inventory of all identified threat-vulnerability pairs. Each pairing should be described with enough specificity to support the probability and impact assessment in step 5.
4. Assessment of current security measures. The risk analysis must assess the security measures already in place and whether they are adequate relative to the threats and vulnerabilities identified. Current measures include technical controls (encryption, access controls, audit logging), administrative controls (training, policies, procedures), and physical controls (facility access, workstation security).
5. Determine the likelihood of threat occurrence. For each threat-vulnerability pair, assign a probability that the threat will exploit the vulnerability to result in unauthorized access, use, disclosure, modification, or destruction of ePHI. The HHS guidance recommends using a qualitative probability scale (High, Medium, Low) with defined criteria for each level. Probability should account for the organization's specific environment — a rural practice with limited remote access has different threat probability from a large health system with thousands of remote users.
6. Determine the potential impact. Assess the impact on ePHI confidentiality, integrity, and availability if each threat-vulnerability pair were to result in a security incident. Consider: number of individuals affected, sensitivity of the data at risk, downstream consequences (patient care disruption, breach notification requirements, enforcement exposure).
7. Determine the level of risk. Combine probability and impact into a risk level rating. Common methodology: a 3x3 matrix (Low/Medium/High probability × Low/Medium/High impact) producing nine risk levels that can be reduced to a three-tier rating (High Risk, Medium Risk, Low Risk). Each identified threat-vulnerability pair should have an assigned risk level in the final risk analysis document.
8. Finalize documentation. The risk analysis must be documented in writing — whether in a structured risk register spreadsheet, a formal risk analysis report, or a purpose-built risk analysis tool output. The documentation must be retained for at least six years (45 CFR §164.530(j)) and be producible on request in an OCR investigation.
9. Periodic review and updates. The risk analysis is not a one-time event. OCR guidance states it must be updated in response to environmental or operational changes. Triggering events include: new ePHI systems deployed, new physical locations opened, workforce expansion with remote access, new vendor relationships involving ePHI, significant security incidents, changes in threat landscape (e.g., new ransomware variants), and changes in applicable regulations. Additionally, the proposed 2026 Security Rule NPRM would codify an annual review requirement.
OIG and OCR Audit Protocols: What Auditors Are Actually Looking For
Both the HHS Office of Inspector General (OIG) and the Office for Civil Rights (OCR) conduct audits and investigations involving HIPAA compliance. Understanding what they look for is the most direct path to understanding what a compliant program requires.
OCR's Phase 2 Audit Protocol (2016–present). OCR's audit protocol — publicly available on the OCR website — specifies exactly what documentation auditors request and what criteria they evaluate. For the Security Risk Analysis, the protocol includes:
*Inquiry 1:* Obtain and review documentation of the covered entity's/business associate's security risk analysis. Review for: scope (all ePHI in all locations and media), identification of threats and vulnerabilities, assessment of likelihood of occurrence and potential impact, documentation of current security measures, level of risk determinations, documentation of findings.
*Inquiry 2:* Was the risk analysis accurate and thorough? Auditors evaluate whether the analysis reflects the actual ePHI environment — they may compare the scope of the analysis against the organization's system inventory, vendor list, and physical locations.
*Inquiry 3:* Was the risk analysis completed within a reasonable timeframe, and has it been updated in response to environmental changes?
What OCR considers deficient. Based on OCR's published corrective action plans and enforcement resolution agreements, the following constitute inadequate risk analysis:
- No documented risk analysis exists
- Risk analysis exists but covers only some ePHI systems
- Risk analysis does not assess probability and impact — only lists vulnerabilities without risk rating
- Risk analysis was performed once and never updated despite system changes
- Risk analysis was performed by a third-party vendor but not reviewed or adopted by covered entity
- Risk analysis does not identify specific threats — only generic compliance categories
OIG's HIPAA oversight role. The HHS OIG conducts oversight audits of OCR's enforcement program, not direct HIPAA compliance audits of covered entities. However, OIG's work product — published in reports, audit findings, and the OIG Work Plan — signals OCR's enforcement priorities. The OIG 2025 Work Plan included: (1) assessing OCR's response to HIPAA complaints, (2) reviewing OCR's handling of multi-year corrective action plan monitoring, and (3) evaluating OCR's enforcement of the patient access right under 45 CFR §164.524.
State health department audits. In California, the California Department of Public Health (CDPH) conducts independent HIPAA-related audits of healthcare facilities. CalOHII (California Office of Health Information Integrity) runs HIPAA compliance reviews for Medi-Cal contractors. New York's Department of Health conducts inspections that include privacy and security components. These state audits are independent of OCR and can trigger separate enforcement actions under state law (California CMIA, New York SHIELD Act).
The 73% Statistic: Risk Analysis in OCR Enforcement
The claim that inadequate risk analysis appears in more than 73% of HIPAA enforcement actions is not an estimate — it is derived from OCR's own published enforcement data.
Methodology. OCR publishes resolution agreements and civil monetary penalty determinations on the HHS website. Reviewing the 130+ enforcement actions published through December 2025, inadequate or missing risk analysis was cited in the factual findings of more than 95 enforcement actions. Several enforcement actions list risk analysis deficiency as the sole or primary violation.
Cases specifically won on risk analysis failure:
Banner Health — $1.25 million (2023). OCR's resolution agreement specifically identified Banner's failure to conduct an accurate and thorough risk analysis as the primary violation. The settlement is notable because Banner's breach response — notification, forensic investigation, and system remediation — was otherwise adequate. OCR pursued enforcement specifically because the underlying compliance failure (risk analysis) predated the breach and was documented in Banner's own records.
Lafourche Medical Group — $480,000 (2023). A small medical practice settled for $480,000 after OCR found it had failed to conduct a risk analysis, had no security policies, and had no training program. The investigation was triggered by a ransomware attack. The practice's response to the attack was adequate, but the absence of pre-incident controls — particularly the risk analysis — drove the enforcement action.
Oklahoma State University Center for Health Sciences — $875,000 (2023). OSU-CHS settled for $875,000 after a breach exposed the ePHI of 279,865 individuals. OCR found failures in risk analysis, risk management, and audit controls. Despite being a large academic medical center with sophisticated IT infrastructure, the risk analysis was found inadequate because it did not cover all ePHI systems.
Peachstate Health Management — $25,000 (2021). A small CLIA laboratory settled for $25,000 — one of the smallest HIPAA settlements — after OCR found no risk analysis, no risk management plan, and no security policies. The low penalty reflects the organization's limited financial resources; the corrective action plan was comprehensive. This case demonstrates that OCR enforces risk analysis requirements against small organizations.
CardioNet — $2.5 million (2017). A wireless cardiac monitoring company settled for $2.5 million after a breach affecting 1,391 individuals. The primary finding: CardioNet had not completed its risk analysis at the time of the breach, despite having identified the need to conduct one. Starting a risk analysis is not sufficient; it must be completed.
Why risk analysis failures drive most HIPAA enforcement. The structural reason risk analysis deficiencies appear in most enforcement actions is that OCR's investigation methodology follows the regulation's own structure. When OCR receives a breach notification or complaint, it investigates whether the organization met each of the Security Rule's administrative safeguards — and risk analysis is the first and most fundamental. An inadequate risk analysis also makes it impossible to demonstrate adequate risk management, because risk management requires identifying specific risks first. The cascade effect means that a single risk analysis failure generates additional findings in virtually every other Security Rule domain.
Step-by-Step HIPAA Risk Analysis Methodology
The following methodology satisfies OCR's nine-element requirement and produces documentation that is defensible in an investigation. It can be completed by internal staff without an external consultant, though external validation adds defensibility for large covered entities.
Phase 1: Preparation (Days 1–3)
1. Assemble the risk analysis team. Include: the Security Officer (required by §164.308(a)(2)), IT staff with system knowledge, the Privacy Officer, and representation from clinical operations (if a provider). For solo practices, the Security Officer may be the practice owner — OCR does not require a dedicated full-time role, but does require that someone be designated.
2. Define the scope. Create a preliminary ePHI inventory by asking: Where is ePHI created in our organization? Where is it stored? Where does it flow? Who has access? Systems to inventory: EHR/EMR, practice management system, billing software, scheduling system, email (if PHI transits), cloud storage (Dropbox, Google Drive, OneDrive), backup systems, portable devices, remote access systems (VPN), patient portal, medical devices with network connectivity.
3. Gather existing documentation. Collect: current policies and procedures, vendor contracts and BAAs, prior risk analyses (if any), previous audit results, known vulnerability scan output, recent security incidents.
Phase 2: Threat and Vulnerability Identification (Days 3–7)
4. Enumerate threat sources. For each ePHI location, identify applicable threats: human (malicious outsider, malicious insider, unintentional errors), natural (flood, fire, earthquake), and environmental (power failure, equipment failure).
5. Identify vulnerabilities. For each threat source, identify system weaknesses that could be exploited. Practical sources: NIST SP 800-30 vulnerability tables, results from vulnerability scans (if available), vendor security bulletins for installed software, CIS benchmark assessments, staff interviews about observed security gaps.
6. Pair threats with vulnerabilities. Create threat-vulnerability pairs. Each pair represents a scenario where a specific threat exploits a specific weakness to impact ePHI. Example: Threat = Ransomware / Vulnerability = Unpatched operating systems on workstations with ePHI access.
Phase 3: Risk Assessment (Days 7–14)
7. Assess likelihood. For each threat-vulnerability pair, assign a likelihood rating:
- High: The threat source is motivated and capable; controls are inadequate to prevent the vulnerability from being exploited
- Medium: The threat source is motivated and capable; controls are partially effective but gaps remain
- Low: The threat source lacks motivation or capability, or existing controls substantially reduce the likelihood
8. Assess impact. For each pair, assess potential impact on ePHI confidentiality, integrity, and availability:
- High: Significant harm — large-scale breach, loss of availability affecting patient care, regulatory investigation likely
- Medium: Moderate harm — limited breach, temporary system unavailability, regulatory reporting likely
- Low: Minor harm — limited ePHI exposure, no significant patient impact, regulatory reporting unlikely
9. Calculate risk level. Combine likelihood and impact using your risk matrix. Document the resulting risk level (High, Medium, Low) for each threat-vulnerability pair. This produces your risk register.
Phase 4: Documentation and Risk Management (Days 14–21)
10. Document findings. Compile the risk register, scope definition, methodology description, and findings summary into a formal Risk Analysis document. Include: date completed, participants, scope boundaries, identified threats and vulnerabilities, risk ratings, and current security measures.
11. Develop a Risk Management Plan. For each High and Medium risk item, document the planned remediation: what control will be implemented, who is responsible, and by when. The risk management plan must be implemented — it cannot exist only as a document. See /hipaa-risk-calculator for a structured risk management planning tool.
12. Executive review and approval. The risk analysis findings should be reviewed and approved by senior leadership or the HIPAA Compliance Committee. This creates organizational accountability and supports the Security Officer's ability to resource remediation.
Phase 5: Ongoing Maintenance
13. Set a review schedule. At minimum, schedule an annual review. Set calendar triggers for immediate review upon: new ePHI system deployment, new office location, significant workforce change, security incident, or new business associate relationship.
14. Document each review. Even if the review concludes that no material changes are needed, document the review date, reviewer, and conclusion. This creates the audit trail OCR expects to see.
Common Risk Analysis Mistakes That Draw OCR Scrutiny
OCR's enforcement record reveals a consistent set of risk analysis mistakes. Avoiding these is as important as completing the analysis correctly.
Mistake 1: Treating the vendor's assessment as the organization's risk analysis. Many covered entities rely on their EHR vendor's security audit or a business associate's risk report as their risk analysis. This does not satisfy §164.308(a)(1)(ii)(A). The obligation belongs to the covered entity for its own environment. A vendor's security assessment covers the vendor's systems — not the covered entity's endpoint devices, email systems, or physical controls. OCR's corrective action plans for this mistake consistently require the covered entity to conduct its own analysis independently.
Mistake 2: Performing a compliance checklist instead of a risk analysis. A checklist asks: Do we have a firewall? Do we have a backup policy? A risk analysis asks: What could go wrong with our ePHI, and how likely is it? These are different documents. A completed HIPAA checklist satisfies checklist requirements; it does not satisfy §164.308(a)(1)(ii)(A). OCR specifically rejected this conflation in the 2010 Guidance and in multiple enforcement agreements.
Mistake 3: Failing to update after significant changes. The most common update trigger: a new EHR system. Organizations that implement a new EHR — a process involving data migration, staff retraining, and new integration points — frequently do not update their risk analysis to reflect the changed environment. This means the risk analysis covers a system the organization no longer uses. OCR treats this as a failure to maintain a current risk analysis.
Mistake 4: Incomplete scope — missing cloud and portable devices. Cloud storage services (including unauthorized 'shadow IT' — personal Dropbox or Google Drive accounts used by staff to share patient files) and portable devices (staff smartphones that receive ePHI via text or email) are among the most frequently missed scope items. Including them in the risk analysis often reveals significant vulnerabilities that were not previously tracked.
Mistake 5: Documenting risk without rating severity. OCR's guidance requires that the risk analysis produce risk level ratings for identified threat-vulnerability pairs. A narrative description of threats without probability, impact, and risk level ratings is not a risk analysis — it is a threat description. Without risk ratings, the organization cannot demonstrate that it has prioritized remediation by risk level as the risk management requirement demands.
Mistake 6: No documentation at all. Smaller organizations — solo practices, small business associates — frequently rely on the Security Officer's familiarity with the systems as a substitute for documentation. This approach fails immediately when the Security Officer leaves, when OCR requests the risk analysis, or when the organization needs to brief legal counsel on its compliance posture before an enforcement response.
Risk Analysis Tools and Resources
Several resources are available to help organizations build and maintain HIPAA-compliant risk analyses.
ComplianceStack HIPAA Risk Calculator (/hipaa-risk-calculator). The HIPAA Risk Calculator guides organizations through the nine-element risk analysis in a structured format, producing a prioritized gap report with regulatory citations. No signup required. Particularly useful for small practices and business associates that need a structured methodology without external consultants.
HHS Security Risk Assessment Tool (SRA Tool). HHS published a free Security Risk Assessment Tool for small and medium-sized healthcare practices. Available at healthit.gov, the SRA Tool walks through threat identification, vulnerability assessment, and risk rating in a desktop application format. It produces a report that can be used as documentation. However, the SRA Tool has not been updated for the proposed 2026 Security Rule NPRM changes.
NIST SP 800-30: Guide for Conducting Risk Assessments. NIST's framework is more comprehensive than HIPAA requires for most small and mid-sized covered entities, but provides excellent methodology guidance for large health systems building enterprise-level risk programs. OCR's Guidance specifically references NIST standards as one acceptable methodology.
NIST SP 800-66 Revision 2: Implementing the HIPAA Security Rule. Updated in 2022, this NIST guide specifically maps Security Rule requirements to implementation guidance. The risk analysis section (Section 2.3) provides detailed implementation guidance aligned with OCR's nine-element framework.
ComplianceStack HIPAA checklist library. The checklist pages at /checklist/hipaa/dental-practice, /checklist/hipaa/mental-health, /checklist/hipaa/pharmacy, and /checklist/hipaa/behavioral-health provide industry-specific control frameworks that can inform the vulnerability identification phase of your risk analysis.
OIG 2025 Work Plan. Available at oig.hhs.gov, the OIG Work Plan describes OCR oversight priorities for 2025. Reading it signals where regulatory attention is focused — useful for organizations determining which risk areas to prioritize in their risk analysis update.
When to engage an external consultant. For large covered entities (500+ employees, 10+ ePHI systems, multi-site operations), an external Qualified Security Assessor or HIPAA-specialized consultant adds defensibility to the risk analysis. External validators can identify blind spots that internal teams miss and produce documentation formatted for regulatory review. For small practices, internal completion with HHS's SRA Tool or ComplianceStack's calculator is generally sufficient.
Connecting Risk Analysis to the 2026 Security Rule NPRM
The proposed 2026 HIPAA Security Rule NPRM — expected to be finalized in mid-2026 with a 240-day compliance window — would significantly strengthen risk analysis requirements and create explicit connections between risk analysis findings and specific technical control mandates.
Key NPRM changes affecting risk analysis:
Annual update requirement. The NPRM proposes codifying the annual review requirement that OCR's 2010 Guidance described as expected practice but did not make explicit in the regulation. Under the proposed rule, covered entities would be required to review and, as necessary, update their risk analysis at least annually.
Risk analysis must drive specific control decisions. The NPRM proposes connecting risk analysis findings to specific technical implementation decisions. Rather than allowing covered entities to treat addressable specifications as optional, the proposed rule would require that risk analysis findings justify all technical control choices. If your risk analysis identifies unencrypted devices as a High risk, the proposed rule would require implementing encryption — the 'addressable' escape valve would be significantly narrowed.
Encryption becomes Required. Under the proposed rule, encryption of ePHI at rest and in transit would become a Required specification — eliminating the current addressable pathway. Organizations that have historically documented why encryption is 'not reasonable and appropriate' as an alternative measure will need to implement encryption once the final rule takes effect.
MFA becomes Required. Multi-factor authentication for all ePHI system access would become Required under the proposed rule. The risk analysis must identify MFA gaps as vulnerabilities regardless of whether the organization has compensating controls.
Practical implication. Organizations that begin their risk analysis with an eye toward the proposed NPRM — specifically identifying encryption gaps and MFA gaps as high-priority vulnerabilities — are building the risk program required under current law and pre-positioning for the coming regulatory changes. Organizations that wait until the final rule is published face a compressed 240-day window to both complete a compliant risk analysis and implement the resulting remediation.
For the full analysis of NPRM changes, see /hipaa-security-rule-2026.
HIPAA Risk Analysis FAQ
How often must a HIPAA risk analysis be performed?
The regulation does not specify a mandatory frequency — only that the risk analysis must be updated in response to environmental or operational changes. OCR's 2010 Guidance describes annual review as expected practice, and the proposed 2026 NPRM would codify annual review as a formal requirement. Practical guidance: review annually as a baseline, and immediately upon any significant system change, new office location, security incident, or new vendor relationship involving ePHI.
Does a business associate need to perform its own risk analysis?
Yes. The 2013 Omnibus Rule extended the Security Rule — including §164.308(a)(1)(ii)(A) — directly to business associates. A business associate's risk analysis must cover all ePHI the business associate creates, receives, maintains, or transmits on behalf of its covered entity clients. The covered entity's risk analysis does not substitute for the business associate's.
Can we use a security audit as our risk analysis?
No. A security audit evaluates whether specific controls are in place. A risk analysis identifies and rates threats and vulnerabilities. These are different documents with different purposes. An external penetration test or SOC 2 audit may produce valuable information to inform your risk analysis — but it does not satisfy the §164.308(a)(1)(ii)(A) requirement on its own.
What if the risk analysis identifies risks we can't fix immediately?
A risk analysis that identifies risks is evidence of a functioning compliance program. OCR does not expect perfection — it expects a documented, good-faith effort to identify risks and implement controls to reduce them to a reasonable and appropriate level. Document all identified risks in your risk register, prioritize remediation by risk level, and document your remediation timeline. A risk analysis showing identified high-risk items with a remediation plan is fundamentally stronger than no risk analysis at all.
How long must the risk analysis be retained?
Under 45 CFR §164.530(j), HIPAA documentation — including the risk analysis — must be retained for a minimum of six years from the date of creation or the date it was last in effect, whichever is later. Retain all versions of your risk analysis, not just the current version.
Can a small solo practice really be expected to perform a risk analysis?
Yes. OCR has settled enforcement actions with solo physician practices and small medical groups. The Peachstate Health Management settlement ($25,000) involved a small CLIA laboratory. The risk analysis requirement scales with organizational complexity — a solo practice may have five ePHI systems, while a large hospital system may have 500 — but the requirement applies at every scale. The HHS SRA Tool and ComplianceStack's HIPAA Risk Calculator are specifically designed for small organizations to complete risk analyses without external consultants.
Start Your HIPAA Risk Analysis in 15 Minutes
The ComplianceStack HIPAA Risk Calculator guides you through the 9-element OCR methodology and produces a prioritized gap report with regulatory citations. No signup, no cost.
Take the Free HIPAA Risk Assessment →