When OSF Healthcare System agreed to pay $552,250 to settle potential HIPAA violations with the HHS Office for Civil Rights (OCR), the settlement amount wasn't the main story. The real lesson lies in the recurring pattern: healthcare entities repeatedly make the same compliance mistakes, and regulators keep documenting the same findings.
These aren't rare cases. Violations that trigger OCR investigations occur because compliance teams treat HIPAA as a checklist rather than a risk management discipline. You implement obvious controls, pass your internal audit, and assume you're covered. Then a ransomware attack exposes the gaps between what you documented and what you actually did.
Why These Mistakes Keep Happening
HIPAA compliance often fails at the intersection of three pressures. First, healthcare IT teams prioritize clinical system uptime over security hardening because downtime affects patient care immediately. Second, compliance officers inherit incomplete documentation from predecessors and lack the technical depth to validate what's actually deployed. Third, executive leadership views HIPAA as a cost center until OCR sends an investigation notice.
The result: your risk assessment exists as a Word document that nobody updates, your encryption policy doesn't match your actual encryption deployment, and your breach notification procedure has never been tested against a real incident timeline.
Mistake 1: Treating Risk Assessments as Annual Paperwork
You schedule your enterprise-wide risk assessment once per year, assign it to a junior analyst, and file the results without changing anything. When OCR investigates, they don't just check whether you completed an assessment. They verify whether you identified actual vulnerabilities, prioritized remediation based on risk, and implemented controls proportional to the threats you documented.
Why it happens: The HIPAA Security Rule requires risk assessments but doesn't mandate a specific methodology. Teams choose the path of least resistance, using generic templates that produce the same findings year after year without driving meaningful security improvements.
Real consequence: During breach investigations, OCR compares your risk assessment findings to the vulnerabilities the attacker exploited. If your assessment identified unpatched systems as a medium risk but you didn't remediate them before the ransomware hit, that gap becomes evidence of willful neglect rather than an unfortunate incident.
The fix: Integrate your HIPAA risk assessment into your broader enterprise risk management program. Use NIST SP 800-30 or ISO 31000 as your methodology framework. Document specific assets, specific threats, and specific vulnerabilities with CVE numbers where applicable. Most importantly, create a remediation timeline with assigned owners and track it monthly, not annually. Your risk assessment should be a living document that drives budget requests and project prioritization.
Mistake 2: Implementing Encryption Inconsistently
Your encryption policy states that all electronic protected health information (ePHI) must be encrypted at rest and in transit. Your EHR database is encrypted. Your backup tapes are encrypted. But your file shares, your archived emails, and your third-party data exchange processes aren't, because nobody mapped all the places ePHI actually lives.
Why it happens: HIPAA Security Rule § 164.312(a)(2)(iv) and § 164.312(e)(2)(ii) make encryption "addressable" rather than required, which teams misinterpret as optional. You implement encryption for the obvious systems and assume you've satisfied the requirement.
Real consequence: When a breach occurs and OCR investigates, they inventory every system that stored ePHI. If any unencrypted ePHI was exposed, you lose the HITECH Act safe harbor that exempts encrypted data from breach notification requirements. That means you're notifying patients, posting media notices, and reporting to OCR even if the attacker never accessed the data.
The fix: Conduct a data flow mapping exercise that traces ePHI from creation through disposal. Document every system, every integration point, and every temporary storage location. For each location, implement encryption or document a specific, risk-based rationale for why encryption isn't reasonable and appropriate (the actual HIPAA standard). That rationale must reference your risk assessment findings and describe the alternative controls you implemented. Review this mapping quarterly, not just when you add new systems.
Mistake 3: Skipping Breach Notification Drills
You've got a breach notification policy that cites the 60-day notification deadline for individuals. You've never tested whether your team can actually identify affected individuals, draft compliant notifications, and execute the process within that window while simultaneously containing an active incident.
Why it happens: Breach notification feels like a legal exercise, not an operational one. You assume your lawyers will handle it when the time comes. You don't realize that breach notification under HIPAA Breach Notification Rule § 164.404 requires technical investigation to determine what ePHI was accessed, by whom, and for how long, which your legal team can't do without your security team's forensic analysis.
Real consequence: During an actual breach, your incident response team focuses on containment while your legal team demands answers about notification scope. Nobody's practiced the handoffs. You miss the 60-day deadline because you spent three weeks arguing about whether the incident qualifies as a breach under the four-factor risk assessment in § 164.402. OCR adds "failure to provide timely notification" to their investigation findings.
The fix: Run tabletop exercises that combine technical incident response with breach notification requirements. Use realistic scenarios: ransomware that encrypted your database backups, a phishing attack that compromised an employee's email containing patient records, or a lost laptop with unencrypted ePHI. Document who makes the breach determination, who conducts the four-factor assessment, who drafts notifications, and who submits the OCR report. Time each step. Identify the bottlenecks. Then fix your procedures based on what you learned, not what you assumed would work.
Mistake 4: Ignoring Business Associate Due Diligence
You sign Business Associate Agreements (BAAs) with every vendor who might touch ePHI. You file those agreements and never think about them again. You don't verify that your business associates actually implement the security controls they contractually promised. You don't audit them. You don't review their SOC 2 reports or their own breach history.
Why it happens: HIPAA Security Rule § 164.308(b) requires you to obtain satisfactory assurances that business associates will safeguard ePHI, but it doesn't define "satisfactory." Teams treat the BAA signature as sufficient assurance and move on.
Real consequence: When your business associate suffers a breach that exposes your patients' ePHI, OCR investigates both entities. They examine whether you conducted due diligence before engaging the business associate and whether you monitored their performance afterward. If you can't demonstrate that you verified their security controls, you're liable for the breach even though you didn't directly cause it.
The fix: Build a business associate risk management program. Before signing a BAA, require vendors to complete a security questionnaire that maps to HIPAA Security Rule requirements. Request evidence: SOC 2 Type II reports, penetration test results, incident response plans, or ISO/IEC 27001 certificates. For high-risk vendors, conduct annual reviews. Document everything. Your due diligence file should demonstrate that you made a risk-based decision to trust this vendor, not that you rubber-stamped their contract.
Mistake 5: Treating Audit Logs as Storage, Not Intelligence
You enable audit logging on your EHR and your file servers because HIPAA Security Rule § 164.312(b) requires it. You store those logs for six years to match your documentation retention requirements. You've never actually reviewed them to detect unauthorized access, and you don't have alerts configured for suspicious activity.
Why it happens: Audit logging feels like a compliance checkbox. You implement it to satisfy the requirement, but you don't integrate it into your security operations because you don't have a dedicated security team to monitor logs.
Real consequence: When OCR investigates a breach, they request your audit logs to determine when the unauthorized access began and whether you could have detected it earlier. If your logs show that an attacker accessed ePHI for six months before you discovered the breach, and you never reviewed those logs, OCR concludes that you failed to implement reasonable monitoring controls. That pattern suggests systemic negligence rather than an isolated failure.
The fix: Implement log monitoring that matches your organization's size and risk. For smaller entities, this might mean weekly manual reviews of access logs for terminated employees or monthly reports of after-hours access to sensitive records. For larger entities, deploy a SIEM that correlates events across systems and alerts on anomalies. Focus on high-risk scenarios: privileged account usage, bulk record access, access from unusual locations, or failed login attempts. Document your review process and the actions you took when you identified suspicious activity. The goal isn't perfect detection; it's demonstrating that you actively used the audit logs for security purposes, not just storage.
Prevention Checklist
Before your next risk assessment cycle, verify you can answer "yes" to each question:
Risk Assessment: Does your current risk assessment identify specific vulnerabilities with assigned remediation owners and deadlines? Can you show OCR how findings from last year's assessment drove this year's security projects?
Encryption Coverage: Have you documented every system that stores, processes, or transmits ePHI? For each unencrypted system, can you produce a written, risk-based rationale and describe your compensating controls?
Breach Notification Readiness: Have you conducted a breach notification drill in the past 12 months? Can your team execute the four-factor risk assessment and meet the 60-day notification deadline without legal delays?
Business Associate Oversight: Do you have documented security assessments for every business associate executed in the past 24 months? Can you demonstrate annual reviews for your highest-risk vendors?
Audit Log Utilization: Do you have a documented process for reviewing audit logs? Can you show evidence of log reviews and the security actions you took based on findings?
Incident Response Integration: Does your incident response plan explicitly address HIPAA breach notification requirements? Have you tested the handoffs between your security team and your legal team?
Organizations that avoid OCR settlements don't have perfect security. They have documented, risk-based decision-making that demonstrates they took HIPAA obligations seriously before the breach occurred. That's the difference between an unfortunate incident and a compliance violation.
