Common HIPAA SRA Mistakes That Put Your Organization at Risk

Seven mistakes that show up in OCR enforcement actions, actual deficiency patterns, and how to avoid them in your security risk analysis.

See How Medcurity Avoids These Mistakes Learn About Continuous Risk Management

The Office for Civil Rights (OCR) has been clear: inadequate risk analysis is the single most cited deficiency in HIPAA enforcement actions. In fact, inadequate risk analysis appeared in 13 out of 20 OCR enforcement matters since the start of 2024. This isn’t a minor compliance issue—it’s the leading reason OCR pursues covered entities and business associates for security violations.

But here’s the problem: most organizations don’t realize they have an inadequate SRA until OCR shows up. They did an SRA. They checked the box. They believe they’re compliant. But when regulators evaluate their risk analysis against OCR’s enforcement patterns, the gaps become obvious.

This guide outlines the seven most common SRA mistakes we see in OCR enforcement actions—and how to fix them before regulators find them.

Mistake #1: Treating the SRA as a One-Time Event, Not a Continuous Process

The Problem: Organizations conduct an SRA annually (or less), file it away, and don’t touch it until next year. If systems change, new threats emerge, or vulnerabilities are discovered mid-year, they’re not integrated into risk management. This is compliance theater, not genuine risk management.

What OCR Found: In a 2024 enforcement action against a regional health system, OCR cited the organization for having “no documented process for reviewing and updating the risk analysis following system changes, breach incidents, or new threat intelligence.” The settlement required quarterly risk reviews and documented updates whenever infrastructure changed. The cost: $300,000 settlement plus $500,000+ in remediation and process changes.

What This Means: OCR now expects risk analysis to be dynamic. Threats change. Systems get upgraded. Vulnerabilities are discovered. Your SRA must adapt. If you can’t point to documented reviews and updates throughout the year, you’re vulnerable to enforcement.

How to Fix It: Implement a quarterly risk review process. Document it. Use a platform that tracks changes: when vulnerabilities are discovered, when security patches are applied, when new systems are deployed. Your updated SRA throughout the year is the evidence that you’re managing risk continuously, not annually.

Mistake #2: Failing to Prioritize Risks by Likelihood and Impact

The Problem: Organizations identify risks (good start) but then treat all risks as equally important. A minor information disclosure risk gets the same priority as a critical ransomware vulnerability. This doesn’t guide remediation efforts—it creates random busywork that won’t measurably reduce risk.

What OCR Found: In enforcement actions, OCR regularly finds that organizations identified vulnerabilities but didn’t prioritize remediation. Patch management was haphazard. Important security updates languished while minor fixes were applied. OCR interprets this as evidence that the organization doesn’t understand which risks actually matter.

What This Means: You must use a risk scoring methodology (likelihood × impact is standard). Score every risk consistently. Document why each risk was scored a certain way. Show that you’re remedying high-risk issues first. If you can’t explain your prioritization methodology, OCR will assume you don’t have one.

How to Fix It: Create a documented risk matrix. Define “high likelihood” (realistic in your environment, given your existing controls), “medium,” and “low.” Do the same for impact. Then score every identified risk against this matrix. Document your reasoning for each score. Use that scoring to guide remediation spend. This becomes your audit trail.

Mistake #3: Identifying Threats and Vulnerabilities But Not Pairing Them

The Problem: Many SRAs list threats separately and vulnerabilities separately but don’t connect them. “We have ransomware threat” and “Our backups aren’t isolated” end up in different sections of the report. The risk analysis never pairs them: ransomware + non-isolated backups = critical risk.

What OCR Found: OCR investigators often discover that organizations identified relevant vulnerabilities but underestimated their risk because they didn’t pair them with realistic threat actors. A lack of encryption isn’t a risk if there’s no realistic threat of data interception in your environment—but it is if your EHR is cloud-based and accessed over the internet. Most SRAs fail at this analytical step.

What This Means: Your risk analysis must pair threats with vulnerabilities. For each pairing, document: What threat actor would exploit this vulnerability? What’s their motivation? How realistic is this attack in your environment? What’s the impact if it succeeds?

How to Fix It: Structure your risk analysis as threat-vulnerability pairs. For each pair, document the reasoning. Example: “Threat: Ransomware actor targeting healthcare. Vulnerability: Lack of EDR on clinical workstations. Pairing: Malware could spread via EHR access, affecting patient data availability. Likelihood: High. Impact: Critical (patient care disruption). Risk Score: 25/25.” This becomes the foundation of your remediation priority.

Mistake #4: No Documented Current Controls Assessment

The Problem: Organizations assume controls exist and work. They don’t actually test them. The SRA claims “we have encryption” without verifying that encryption is actually enabled. It claims “we have access controls” without testing whether those controls are actually enforced.

What OCR Found: This is a pattern in OCR enforcement actions: organizations claimed security controls were in place, but investigators found the controls were misconfigured, disabled, or never actually implemented. Example: An organization claimed database encryption was active but investigators found it was disabled. Settlement: $150,000 plus required third-party security assessment.

What This Means: Your SRA must include evidence of controls. Screenshots showing encryption settings. Audit logs showing access controls are functioning. Vendor confirmations of security features. If you can’t produce evidence, OCR assumes the control doesn’t exist.

How to Fix It: For each critical control, document that it actually works. Include evidence: screenshots from system settings, configuration exports, third-party audit reports, vendor letters. Don’t just claim controls exist—prove it. This single step prevents most OCR enforcement findings related to missing controls.

Mistake #5: Risk Acceptance Without Documented Business Justification

The Problem: Organizations identify high-risk vulnerabilities but don’t remediate them. When OCR asks why, they say things like “We know it’s there” or “We decided to accept the risk.” Without documented business justification (board approval, cost-benefit analysis, mitigation strategy), this looks like negligence.

What OCR Found: In enforcement actions, OCR finds that organizations accepted significant risks without documented board-level approval or business rationale. This creates liability: if a breach occurs and exploits an accepted but unmitigated vulnerability, OCR can argue negligence. Settlements often require that risk acceptance be formally documented and approved.

What This Means: If you accept a risk, document why. “Cost to remediate: $50,000. Likelihood: Medium. Impact: High. Business decision: Accept risk and implement compensating control (additional monitoring). Approved by: Board of Directors, Date: [date].” This documentation protects you if OCR questions the decision.

How to Fix It: For any risk you’re accepting (not remediating), document the business justification and get board or executive approval. This shows OCR that the decision was deliberate, not negligent. Include cost analysis, likelihood/impact rationale, and any compensating controls you’re implementing instead.

Mistake #6: Remediation Plans That Slip Without Documented Tracking

The Problem: The SRA proposes remediation actions (“Deploy EDR by Q1”, “Update servers to latest OS by Q2”). But there’s no tracking. When Q2 ends, the update hasn’t happened. Nothing happens. It just disappears into the backlog.

What OCR Found: OCR looks for evidence that remediation actually happens. Organizations that identify vulnerabilities but show no progress in remediating them get cited for ineffective risk management. The settlement often includes requirements for executive-level remediation tracking and board reporting.

What This Means: Remediation must be tracked and visible. Monthly status updates. Executive dashboards showing progress. Documented reasons for slippage. If remediation isn’t progressing, OCR sees an organization that isn’t serious about managing risk.

How to Fix It: Assign ownership to each remediation action. Set target dates. Track progress monthly. Report to leadership quarterly. When deadlines slip, document why and reset the target. This demonstrates OCR that you’re actively managing remediation, not just proposing it and hoping.

Mistake #7: Executive-Level Risk Reporting Is Missing or Vague

The Problem: The SRA is a technical document, buried in IT files. The board has no idea what risks the organization faces, what’s being remediated, or what the timeline is. Risk management is IT’s job, not a business-level concern.

What OCR Found: OCR increasingly expects leadership to be informed about information security risk. When investigating organizations, OCR asks board members and C-suite executives questions about security risk. If executives can’t articulate the organization’s risk profile, OCR takes that as evidence that leadership isn’t engaged in risk management—which creates liability.

What This Means: Your board should understand your security risk posture at a high level. What are the top 3-5 risks? What’s the remediation plan? What’s the timeline? Who’s accountable? Your annual SRA should include an executive summary that answers these questions in business terms, not technical jargon.

How to Fix It: Create an executive-level risk summary: “We identified 47 total risks. 8 are critical, 22 are high, 17 are medium. We are investing $X in remediation over the next 12 months. Current spending is on track. Accountability: CIO.” Have the board review and approve this summary annually. Reference it in board minutes. This demonstrates OCR that leadership is engaged and informed.

Summary: Seven Fixes to Avoid OCR Enforcement

The good news: most of these mistakes are fixable. Here’s the quick checklist:

Make risk analysis continuous, not annual. Quarterly reviews minimum. Documentation required.
Prioritize risks using a documented methodology. Likelihood × Impact is standard. Document your scoring.
Pair threats with vulnerabilities. Show which threats exploit which vulnerabilities in your environment.
Assess current controls with evidence. Don’t assume—prove controls work.
Document business justification for accepted risks. Get executive approval.
Track remediation progress actively. Monthly status, executive reporting quarterly.
Create executive-level risk reporting. Leadership should understand the organization’s top risks.

These seven steps don’t just reduce OCR enforcement risk—they improve your organization’s actual security posture. You’re managing risk, not just documenting it.

Platform-Driven SRA

Building and maintaining an SRA that avoids these seven mistakes takes discipline and ongoing effort. Most healthcare organizations find it’s easier with a platform designed for these workflows.

Medcurity’s platform is built specifically to avoid these common mistakes:

Continuous monitoring: Quarterly review templates keep your risk analysis current throughout the year
Risk prioritization: Built-in methodology ensures consistent threat-vulnerability pairing and scoring
Control assessment evidence: Integrated documentation for control testing and verification
Remediation tracking: Assigned tasks, deadline management, progress dashboards
Executive reporting: Automated risk summaries and board-ready reporting

See how Medcurity helps you build an OCR-ready SRA and avoid these enforcement patterns.

See a Demo | Talk to Our Compliance Team