Ask most IT teams what causes a HIPAA violation and they'll mention breaches, ransomware, unencrypted laptops. Access control rarely comes up first, but it's the thread running through a large share of the biggest OCR settlements: the wrong person had access, nobody caught it in time, and there was no clean record of who could see what.
Below are real, cited cases where access control (not encryption, not training, not paperwork) was the actual failure point, along with what would have prevented each one.
1. Employees Sharing Patient Information They Had Access To
HIPAA's Privacy Rule restricts who can view or disclose PHI, but the rule only works if access itself is limited to people who need it for their role. When access is broader than necessary, misuse becomes a matter of opportunity, not just intent.
Case: Five former employees of Methodist Hospital, along with a former employee of Memphis-based Roderick Harvey, pled guilty to unlawfully disclosing patient information. From 2017 to 2020, Harvey paid Methodist Hospital employees to provide patient names and phone numbers of individuals involved in car accidents, which he then sold to personal injury attorneys and chiropractors.
What access control would have changed: The employees involved had standing access to patient contact information well beyond what their day-to-day roles required. Role-based access scoped to actual job function, combined with monitoring for unusual data pulls, is what closes this gap.
2. Overprivileged Access Left Unreviewed
This is the purest access-review failure in the HIPAA case record: access wasn't misconfigured once, it was simply never checked.
Case: The HHS Office for Civil Rights settled with Yakima Valley Memorial Hospital after 23 security guards were found to have improperly accessed the medical records of 419 patients without any job-related reason, over an extended period. The breach exposed names, addresses, medical record numbers, and treatment notes, and violated both the Privacy and Security Rules. The hospital paid $240,000, updated its access policies, retrained staff, and strengthened safeguards against unauthorized access.
What access control would have changed: Security guards should not have had standing access to clinical records in the first place. Beyond the initial provisioning error, a periodic access review would have flagged 23 users with access outside their role well before it became a four-year pattern. This is the exact anomaly an automated review is built to catch: access that doesn't map to job function, sitting unreviewed.
3. No Visibility Into Where Access Risk Actually Sits
HIPAA's Security Rule requires ongoing risk analysis, and access is one of the biggest blind spots when that analysis doesn't happen. You can't secure access you haven't mapped.
Case: Medical Informatics Engineering, Inc. (MIE) agreed to pay $100,000 and implement a corrective action plan after HHS found the company had failed to perform a comprehensive risk analysis, a failure that potentially violated both the Privacy and Security Rules.
What access control would have changed: A risk analysis that includes an actual identity and access inventory, not just a network security checklist, surfaces exactly where PHI access is overprivileged, unreviewed, or untracked before it becomes a breach. Without that inventory, an organization is guessing at its own exposure.
4. Standing Access on Unsecured Devices
Device theft is usually framed as an encryption problem, but the deeper issue is standing access: if a device stays logged in or access isn't tied to strong authentication, a stolen laptop becomes a stolen set of PHI credentials.
Illustrative scenario: A healthcare employee's laptop is stolen. If the device isn't password-protected, encrypted, or backed by multi-factor authentication, whoever has it can access the same PHI the original user could, including diagnoses, treatment histories, and personal identifiers, without needing to breach anything else.
What access control would have changed: MFA and automatic logoff are HIPAA technical safeguards for exactly this reason. But the access control layer matters just as much: access should be scoped so that even a compromised device only exposes what that specific role needs, not a standing session into everything.
The Pattern Across All Four
Every case above traces back to the same two failures: access that was broader than the role required, and no review process to catch it before it became a settlement. Encryption, training, and incident response plans matter, but they're downstream of getting access right in the first place.
Preventing These With Zluri
Zluri's Access Management enforces role-based, least-privilege access automatically, so PHI access is scoped to actual job function from the moment it's granted, not configured once and left to drift. Access Reviews catches what provisioning misses: overprivileged accounts, former employees or contractors who still hold access, and users whose access no longer matches their role, with run logs and audit trails that document exactly what was reviewed and remediated. That combination is what would have interrupted every case above well before it reached OCR.
Frequently Asked Questions
Are most HIPAA violations really about access, not data breaches?
Not all of them, but a significant share of major OCR settlements involve access that was broader than necessary, whether through misconfiguration, lack of review, or standing access that should have been revoked. Encryption failures and external breaches get more attention, but internal access control gaps are just as costly and often easier to prevent.
What's the difference between a data breach and an access violation under HIPAA?
A data breach typically involves PHI being exposed to someone outside the organization, often through hacking or theft. An access violation can happen entirely inside the organization, when someone who technically has legitimate system access uses it beyond what their role justifies, as in the Yakima Valley case.
How do we know if our access reviews are frequent enough?
If your organization can't currently produce a list of everyone with access to a PHI system, along with when that access was last reviewed, the review cadence isn't the problem yet, visibility is. Once that visibility exists, quarterly or biannual reviews are the common baseline, with more frequent reviews for high-risk systems.
Can automated access reviews really catch cases like the Yakima Valley one?
Yes. That case is a textbook example of what automated review is designed to catch: a group of users with access that doesn't match their job function, sitting unflagged for an extended period. A recurring, automated review process surfaces exactly that kind of anomaly instead of relying on someone noticing it manually.
.webp)
.svg)
