Understanding the Compliance Questions
After the Office for Civil Rights (OCR) announced an $800,000 settlement with Lehigh Valley Health Network, compliance teams began questioning the implications. A ransomware group exfiltrated data, the health system didn't pay, the data was leaked, and the settlement followed. OCR noted it as its 22nd ransomware investigation ending in a financial penalty. The health network also settled related class action litigation for $65 million, indicating the OCR penalty wasn't the full cost.
Here are the most common questions we hear, with direct answers.
Q1: What was missing in the OCR's risk analysis?
OCR found that the organization failed to conduct a "comprehensive and accurate" risk analysis of risks and vulnerabilities to electronic protected health information (ePHI). This requirement is detailed in 45 CFR 164.308(a)(1)(ii)(A), emphasizing an enterprise-wide scope.
In this case, compromised systems belonged to a practice the health network had acquired. Acquired entities often remain outside the main risk analysis for extended periods. If your analysis doesn't inventory every system that creates, receives, maintains, or transmits ePHI, including inherited ones, it's not comprehensive.
A defensible analysis should cover asset inventory, data flows, threat and vulnerability identification, current controls, likelihood and impact ratings, and documented risk levels. Treat it as a living record. A stale spreadsheet won't suffice.
Q2: Is an annual risk analysis enough?
No, annual completion is just a schedule. OCR's corrective action plan requires two deliverables: a risk analysis and a risk management plan. Many organizations have the first but not the second.
The Security Rule's risk management standard (164.308(a)(1)(ii)(B)) requires implementing security measures to reduce identified risks to a reasonable level. If your analysis lists findings but your remediation tracker shows none assigned, owned, and dated, there's a gap OCR can cite.
Test this: pick any high-risk finding from your last analysis and trace it to a funded, assigned, time-bound action. If you can't, address that before the next audit. Mapping your analysis to the NIST Risk Management Framework or ISO 31000 can help structure the lifecycle, but HIPAA documentation requirements still govern.
Q3: What does "information system activity review" entail?
This is the second Security Rule violation OCR cited. The requirement at 164.308(a)(1)(ii)(D) calls for procedures to regularly review records of system activity, such as audit logs, access reports, and security incident tracking reports.
The key is "regularly." Collecting logs isn't enough. Someone must review them on a defined schedule with documented results and escalation paths. OCR's Director stated that failing to conduct an accurate risk analysis and regular activity review makes entities "attractive targets for cyberattacks."
Ask your team: Who reviews logs for systems containing ePHI? How often? Where's the evidence? If the answers are "the SIEM does it," "continuously," and "alerts," you still need documented human review and a procedure that specifies this.
Q4: What's the deadline for breach notification?
The Breach Notification Rule requires notice to affected individuals without unreasonable delay, and no later than 60 days after discovery. Notice to the HHS Secretary has the same 60-day limit for breaches affecting 500 or more individuals. This breach exposed 248,359 people, fitting that category.
OCR cited this timeline: intrusion detected February 4, OCR notified May 15, which is past 60 days. Individual notifications weren't timely either.
Two points often cause confusion. First, the clock starts at discovery, not when forensics are complete or the full scope is confirmed. Under 164.404(a)(2), a breach is discovered on the first day it's known or would have been known with reasonable diligence. Second, "no later than 60 days" is a ceiling, not a target. Unreasonable delay within that window can still be a violation.
Note that the 72-Hour Notification Requirement under the General Data Protection Regulation (GDPR) is a different clock with a different trigger. Don't conflate them if you handle both.
Q5: How do we notify on time if forensics take months?
Notify based on what you know, then supplement. The rule doesn't require a complete investigation before obligations start. Build your incident response plan so legal and compliance run parallel from day one.
A workable structure:
- Day of discovery: Log the discovery date formally. This is your clock-start evidence.
- Early in the response: Run a breach risk assessment under 164.402 to determine if notification is required.
- In parallel with forensics: Draft notification templates and identify the affected population as it emerges.
- Before the deadline: Send notices with available facts. Update later if the scope grows.
Your Computer Security Incident Response Team and privacy officer need a shared playbook that names who owns the notification decision. In many failures, forensics and compliance run sequentially instead of in parallel, and the calendar runs out.
Q6: Is OCR focused more on breach notification or risk analysis?
OCR hasn't announced a formal initiative on breach notification, but the enforcement record is clear. Recent reports show five of the 12 HIPAA settlements this year involved breach notification failures, with five more the previous year. Risk analysis failures remain common, but late notification is clearly attracting attention.
Don't wait for an announced initiative. Audit your notification procedures now. Ensure your policies reference the correct deadlines, that your templates exist, and that you've run a tabletop exercise on a breach affecting more than 500 people.
Next Steps
Begin with the HIPAA Security Rule text at 45 CFR Part 164, Subpart C, and the Breach Notification Rule at Subpart D. For risk analysis methodology, review OCR's guidance on the risk analysis requirement and the NIST Cybersecurity Framework (CSF) 2.0 for control mapping. If you want certification-backed structure, the HITRUST CSF and NIST SP 800-53 offer control sets aligning with Security Rule safeguards.
Then, focus on practical steps: review the corrective action plan elements from this settlement (risk analysis, risk management plan, policy revision, workforce training). These elements are OCR's checklist for what they expect you to have already.
