What OCR Actually Looks For in a HIPAA Security Risk Analysis
The Office for Civil Rights (OCR) has a single priority when examining your organization’s HIPAA compliance: evidence of a legitimate, organization-specific security risk analysis.
It’s not a suggestion. It’s not a nice-to-have framework exercise. It’s the foundational requirement of the HIPAA Security Rule—and OCR is enforcing it with unprecedented intensity.
Since launching its Risk Analysis Initiative in October 2024, OCR has filed enforcement actions against eight healthcare organizations, resulting in nearly $900,000 in settlement payments within the first six months alone. In early 2026, OCR Director Paula M. Stannard confirmed the initiative would continue and expand to include risk management enforcement.
If OCR investigators arrive at your organization, they will evaluate your security risk analysis against a specific set of criteria—elements drawn directly from 45 CFR 164.308(a)(1)(ii)(A) and refined through years of enforcement decisions. This guide shows you exactly what those elements are, what OCR has found deficient in real organizations, and what defensible documentation actually looks like.
—
Why OCR Cares About Your SRA — The Enforcement Reality
A security risk analysis is not a compliance checkbox. It’s the blueprint for every security decision your organization makes.
According to the HIPAA Security Rule, covered entities and business associates must “conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information.” This isn’t prescriptive—OCR doesn’t mandate a specific tool or methodology—but it is absolute. Organizations must do it, document it, and demonstrate it when asked.
OCR’s enforcement data tells a clear story: organizations with weak or missing SRAs face settlements averaging $100,000–$300,000 per investigation. And that’s separate from remediation costs, legal fees, and reputational damage.
The stakes are real. And OCR is paying attention.
The Nine Required Elements of a HIPAA Security Risk Analysis
45 CFR 164.308(a)(1)(ii)(A) defines the Security Risk Analysis requirement, but OCR’s guidance documents and enforcement decisions have refined this into nine core elements that organizations must demonstrate. Here’s what OCR actually looks for:
1. Organization-Specific Asset Inventory
Your SRA must begin with an accurate, current inventory of systems, software, hardware, databases, and infrastructure that process, store, or transmit electronic protected health information (ePHI).
What OCR expects to see:
- Detailed IT asset inventory with version numbers, deployment dates, and ownership
- Documentation of all systems handling ePHI (EHR, billing systems, email, patient portals, third-party applications, databases)
- Network diagrams showing how systems interconnect and where ePHI flows
- Hardware inventory (servers, workstations, mobile devices, printers) with specifications
- Clear ownership and responsibility assignment for each asset
What OCR has found deficient:
- Organizations claiming “asset inventory complete” but unable to locate or describe 30–40% of systems during investigation
- Missing documentation of cloud-based systems or SaaS applications in use by departments
- Outdated hardware lists that don’t reflect current environment
- Unclear responsibility for assets managed by third parties or contractors
Example of defensible documentation: A practice maintains a Master Asset Register updated quarterly, with columns for: System Name, Owner, Type (hardware/software), Version, Deployment Date, Criticality (High/Medium/Low for ePHI), and Responsible Department. The register is reviewed annually and certified by IT leadership.
2. Threat Identification and Documentation
You must identify the actual threats your organization faces—not generic threats, but specific threats relevant to your environment, industry, and risk profile.
What OCR expects to see:
- Documented threats specific to your organization (not copy-pasted from HIPAA guidelines)
- Consideration of external threats (hackers, ransomware gangs, phishing campaigns targeting healthcare)
- Internal threat vectors (disgruntled employees, contractors with access, compromised credentials)
- Physical security threats (unauthorized access, equipment theft, natural disasters)
- Third-party and supply-chain threats (vendors with system access, business associates, SaaS providers)
- Evidence of how threats were selected (industry research, threat intelligence, prior incidents)
What OCR has found deficient:
- Generic threat lists that don’t reflect the organization’s specific environment
- Missing external threats (focusing only on internal risks)
- No documentation of threat selection methodology
- Outdated threat profiles that haven’t been updated despite emerging attack patterns
Example of defensible documentation: An organization documents its threat landscape by: (1) researching recent healthcare data breaches via HHS and OCR published breach databases; (2) interviewing IT staff and clinical leadership about internal risks; (3) reviewing prior security incidents; (4) incorporating threat intelligence from their security provider. For each threat, they document the source and reasoning.
3. Vulnerability Assessment and Remediation Status
Identify the vulnerabilities in your systems and document how they are being addressed. This must be organization-specific, not a generic checklist.
What OCR expects to see:
- Documented vulnerabilities in your specific systems (not general framework vulnerabilities)
- Prioritization methodology (severity, exploitability, impact)
- Remediation status for each identified vulnerability (Open/In Progress/Resolved)
- Timeline and responsibility for addressing vulnerabilities
- Evidence of vulnerability scanning or penetration testing
- Vulnerability management process (how new vulnerabilities are discovered and tracked)
What OCR has found deficient:
- Long lists of unaddressed vulnerabilities with no remediation timeline
- Missing evidence of how vulnerabilities were identified
- Vulnerabilities identified but abandoned mid-remediation
- No distinction between critical vulnerabilities and minor issues
Example of defensible documentation: An organization performs quarterly vulnerability scans, documents findings by severity (Critical/High/Medium/Low), assigns each to an owner, and tracks remediation progress in a dashboard. Remediation plans include timeline, responsible party, and evidence upon completion. Unresolved issues are reviewed monthly by security leadership.
4. Likelihood Assessment (Probability of Occurrence)
You must assess the likelihood that identified threats will actually occur in your environment. This is not generic probability—it’s specific to your organization, given your existing controls and risk profile.
What OCR expects to see:
- Documented reasoning for likelihood assessment (why this threat is likely/unlikely in your environment)
- Consideration of existing controls and how they affect likelihood
- Alignment with industry data (healthcare breach frequency, ransomware targeting your region, etc.)
- Documentation that likelihood estimates are updated as controls change
What OCR has found deficient:
- Likelihood assessed as “High” for all threats with no differentiation
- No explanation for why threats are assessed as likely or unlikely
- Likelihood that doesn’t change even when new controls are implemented
Example of defensible documentation: An organization assesses threat likelihood on a scale (1-5) with documented reasoning: “Ransomware probability: 4/5. Reasoning: (1) Healthcare is a primary ransomware target; (2) We lack endpoint detection and response (EDR); (3) Our backup recovery is offline but recovery time is 24–48 hours. Existing controls (email security, network segmentation) mitigate to some degree.” As EDR is deployed, likelihood is reassessed and documented.
5. Impact Assessment (Consequences of a Threat Materializing)
If a threat actually occurred, what would be the impact on your organization? This must include financial, operational, reputational, and regulatory impact.
What OCR expects to see:
- Financial impact estimate (breach notification costs, fines, remediation, lost revenue)
- Operational impact (system downtime, staff inefficiency, clinical care disruption)
- Reputational impact (patient trust, market position)
- Regulatory impact (OCR enforcement, state attorney general action)
- Documentation of how impact was estimated
- Consideration of worst-case scenarios (not just average scenarios)
What OCR has found deficient:
- Impact assessed generically without organization-specific reasoning
- Underestimating impact (e.g., “ransomware would cost $50,000” when industry average for healthcare is $5M+)
- No documentation of assumptions or how estimates were derived
Example of defensible documentation: An organization assesses breach impact: “Data breach of 10,000 patient records. Financial impact: (1) Breach notification: $2/person = $20,000; (2) Credit monitoring: $3/person = $30,000; (3) Legal/investigation: $100,000; (4) OCR potential fine: up to $1.5M; (5) Reputational: estimated 5–10% patient loss = $200K–$400K. Total impact: $1.75M–$2.05M. This assessment is based on HHS breach notification data and OCR settlement patterns.”
6. Risk Prioritization (Quantified Risk Scores)
Risks must be prioritized using a documented methodology. The HIPAA Security Rule doesn’t mandate a specific formula, but you must have one that is applied consistently.
What OCR expects to see:
- A defined risk scoring methodology (e.g., Likelihood × Impact, qualitative rankings, or more sophisticated modeling)
- Documentation that the methodology was applied to all identified risks
- Clear prioritization that guides remediation efforts
- Executive summary ranking risks by priority level
What OCR has found deficient:
- No clear prioritization of risks
- Random remediations that don’t follow any documented priority methodology
- Risk scores that don’t correlate with actual remediation effort
Example of defensible documentation: An organization uses a matrix: Risk Score = Likelihood (1-5) × Impact (1-5), producing scores of 1-25. Scores 20–25 = Critical (remediate within 30 days); 15–19 = High (60 days); 10–14 = Medium (90 days); 1–9 = Low (track annually). All identified risks are plotted and prioritized accordingly.
7. Remediation Plan (Treatment Plan for Identified Risks)
You must document your approach to addressing identified risks. For each risk, you need to decide: will you mitigate, accept, avoid, or transfer the risk?
What OCR expects to see:
- For each significant risk, a documented remediation decision (Mitigate/Accept/Avoid/Transfer)
- If accepting risk, documented business justification for acceptance
- If mitigating, detailed remediation plan with timeline and responsible party
- Evidence of progress toward remediation
- Documentation that remediation plans are monitored and updated
What OCR has found deficient:
- Long lists of risks identified but no corresponding remediation plans
- Risk acceptance without documented business justification
- Remediation plans that don’t progress (stuck in “In Progress” status for years)
- No executive accountability for remediation
Example of defensible documentation: For each risk, a remediation record includes: Risk ID, Description, Priority, Treatment (Mitigate/Accept/Avoid/Transfer), Owner, Timeline, Status, and Evidence. E.g., “Risk-042: Outdated server OS. Likelihood: 4, Impact: 4, Score: 16 (High). Treatment: Mitigate. Owner: IT Director. Timeline: Complete by Q2 2026. Status: In Progress. Evidence: [Patch notes, testing results].”
8. Continuous Monitoring and Update Process
A security risk analysis cannot be a one-time event. OCR expects to see evidence of continuous monitoring, periodic reviews, and updates when the environment changes.
What OCR expects to see:
- Documented process for ongoing risk assessment (quarterly reviews minimum)
- Updates to risk profiles when systems change or new threats emerge
- Documentation of significant incidents or vulnerability findings throughout the year
- Evidence that leadership reviews risk status regularly
- Formal full SRA cycle at least annually
What OCR has found deficient:
- SRA that is never updated after initial completion
- Major system changes or security incidents not reflected in risk assessment
- No evidence of ongoing monitoring between annual SRA cycles
Example of defensible documentation: An organization documents continuous monitoring: “Monthly: Security team reviews new vulnerabilities and breach notifications, updates risk register. Quarterly: Full risk review meeting with IT leadership and compliance officer; risk scores updated; new risks added if needed. Annually: Comprehensive SRA conducted; full reassessment of all elements; comparison to prior year; documented changes; signed by leadership.”
9. Documentation and Audit Trail
Every element must be documented. OCR is not interested in informal understandings or unwritten processes. Your SRA documentation is your defense.
What OCR expects to see:
- Complete written SRA documentation (not scattered across multiple documents or emails)
- Evidence of who prepared the SRA and when
- Evidence of review and approval by leadership
- Version control on SRA documents
- Evidence of stakeholder involvement (IT, clinical, administrative leadership)
- Clear dating and sign-off
What OCR has found deficient:
- SRA documentation that is incomplete, unclear, or hard to locate
- No evidence of management review or approval
- Documentation that contradicts actual practices
- SRA that was prepared by one person with no oversight
Example of defensible documentation: The SRA is a complete written document (50–100 pages typical) prepared by a compliance team with IT involvement. It includes: Executive Summary, Asset Inventory, Threat Analysis, Vulnerability Assessment, Risk Prioritization, Remediation Plans, Continuous Monitoring Process, and Sign-Off Page. It is reviewed and approved by the Compliance Officer and CIO, dated, versioned, and archived. Updates are tracked via version control.
What Happens When OCR Arrives
OCR investigators will request your SRA and evaluate it against these nine elements. If your documentation is weak or incomplete, OCR will find violations. The current settlement average is $100,000–$300,000 per investigation—and that’s just the OCR penalty. Add breach notification costs, business impact, legal fees, and reputational damage, and you’re looking at potential losses in the millions.
But here’s the good news: if you conduct a thorough SRA with clear documentation and good risk management practices, OCR has very little to object to. Organizations that invest in legitimate, documented security risk analysis rarely face OCR enforcement.
Building an OCR-Ready SRA
To build an SRA that will withstand OCR scrutiny:
- Use a methodology recognized by OCR. NIST SP 800-30 or similar frameworks are widely accepted. Avoid one-off methodologies that OCR can’t validate.
- Be organization-specific. Every element must reflect your unique environment, not generic frameworks.
- Document everything. If you didn’t write it down, OCR assumes it doesn’t exist.
- Prioritize risks and document remediation. OCR wants to see that you’re fixing the biggest problems first.
- Demonstrate leadership buy-in. The SRA must be reviewed and approved by executives, not just IT staff.
- Update continuously. Your SRA should evolve with your organization.
- Engage professionals if needed. If you lack internal expertise, hire an experienced compliance consultant to guide the process. OCR respects professionally-prepared SRAs.
The Bottom Line
OCR is not negotiable on the security risk analysis. It’s the foundation of HIPAA compliance, and OCR is enforcing it vigorously. Organizations with thorough, well-documented SRAs sleep better at night—and have significantly better outcomes if they ever face investigation.
Build your SRA right the first time. Document it thoroughly. Update it continuously. And you’ll have a powerful defense against OCR enforcement.